Have you ever thought about the definition of "bad design"?

DDD serialized article

Introduction

I think that there are various discussions about the good and bad of design every day, but is there a clear definition of "good design" and "bad design"? Although it is vague or fragmentary in each head, it seems that the team does not often define good or bad.

I think it's worth discussing in each project, but I think it's easier to discuss if there is one standard. So let's take a look at one of the definitions of "bad design" proposed by Robert Cecil Martin, aka Uncle Bob, who advocated the principle of object orientation.

About Uncle Bob

Before that, I would like to introduce Uncle Bob.

Robert Cecil Martin(wikipedia)

The author of the famous "clean code" is easy to understand. In addition, he is an advocate of the SOLID principle, which is an object-oriented design principle, and a co-author of the Agile Software Development Declaration. , The impact on the software industry is immeasurable.

(As an aside, I introduced it in What is the easiest architecture to get started with Domain Driven Design This is also the proponent of the application architecture "Clean Architecture". The site that is operated is also called Clean Coder, and we are particular about the name clean. It seems that there is. It seems that it was from here when I wondered where the "clean" of the clean architecture came from.)

Original

The original text referenced this time is further in the page of The Principles of OOD of Old UncleBob Site. , Article of The Dependency Inversion Principle. This is a quote and summary of the contents.

What is "bad design"?

A design that has the following three properties that all engineers can agree on is called a "bad design".

  1. Rigidity :
    It is hard to change because every change affects too many other parts of the system.
  1. Fragility:
    When you make a change, unexpected parts of the system break.
  2. Immobility:
    It is hard to reuse in another application because it cannot be disentangled from the current application.

Translate it into Japanese, and then write a partial translation and summary of the details described after that.

1. Rigidity:

Difficult to change, as each change affects many other parts of the system.

The cause is that you have to make a chain of modifications to the dependent modules for one change.
If the designer cannot predict the extent to which modifications need to be made, the impact and cost will be unpredictable. Authorities then dislike approving changes, which puts rigid pressure on them.

Countermeasures You may have said "reduce the number of dependent modules" and "make the dependent modules logically inferrable".

A contrasting property is Flexibility.

2. Fragility:

Making changes breaks unexpected parts of the system.

Often, changes can create new problems in areas that are not conceptually relevant. This causes the maintenance team to become less reliable. The more development you continue, the more troubles that appear to be irrelevant occur, and each time you make a correction, another trouble occurs ... and the man-hours required for maintenance continue to increase.

As a countermeasure, you can think of saying "make it depend only on modules that are conceptually related" and "make it within the range where the dependent modules can be logically guessed" as in 1.

A contrasting property is Robustness.

3. Immobility:

Strongly coupled with the current application, making it difficult to reuse in another application.

If part of an implementation relies heavily on something that is business-specific, then the reusability of that implementation is low. When designers investigate the reuse of implementations, they find that there is a lot of work required to separate and reuse modules, and in many cases they give up on reuse.

Is the countermeasure "increasing the cohesion of the module"?

A contrasting property is Reusability.

Summary

What do you think. It may be easier to imagine by thinking "the definition of bad design, inside out" rather than "definition of good design".

Also, based on this, it may be used as a basis for reconsidering your own thoughts and team policies.

Recommended Posts

Have you ever thought about the definition of "bad design"?
Have you ever considered the life of a params flash session?
About the handling of Null
Gemfile.lock doesn't say the version of gem you have installed
About the description of Docker-compose.yml
[Java] I thought about the merits and uses of "interface"
I thought about the strategy of introducing Combine in iOS development
About the behavior of ruby Hash # ==
About the basics of Android development
About the role of the initialize method
Think about the 7 rules of Optional
Summary about the introduction of Device
About the log level of java.util.logging.Logger
Have you stopped thinking about using getters / setters in DTO design patterns?
About the version of Docker's Node.js image
What is testing? ・ About the importance of testing
Have you stopped thinking about using BeanUtils.copyProperties?
About the operation of next () and nextLine ()
About the initial display of Spring Framework
About the error message Invalid redeclaration of'***'
About the treatment of BigDecimal (with reflection)
About the number of threads of Completable Future
About the mechanism of the Web and HTTP
Defense Techniques When You Have to Fight the Performance of Unfamiliar Applications (Part 2)
Be careful about upgrade if you use | etc. in the URL of Tomcat