origin
Recently, due to the confluence of several factors, I was fortunate enough to be in charge of a refactoring project that was very time/space free. Moreover, due to the complexity of the system, I need to connect with multiple business development departments, resulting in a large number of large and small demands. Therefore, if MY code design is bad, I will have to work overtime to wipe my ass. As a result, I’m afraid to write bad code and try to avoid the “broken window effect”. Therefore, if you want to record some of your feelings, you will not pay attention to the structure of the article.
Object orientation is still the dominant design style
Here to understand what is object oriented, not to recite the textbook “encapsulation, inheritance, polymorphism”. Software development is a matter of practice, reciting textbooks is the most useless. “Encapsulation, inheritance, polymorphism” is probably the least important, but here’s what matters:
- What is “inversion of control” and what is “dependency injection” have practical implications for how we actually design code, beyond what we see in frameworks like Spring/Angular.
- What are the “SOLID” principles, what are the practical implications, what is easy to do, and what seems easy is hard to do.
The world is stateful, and as a result our code is full of states
This is actually the reason for the first point, and probably the reason for the popularity of object-oriented style, right? Various, dirty states can be hidden behind one class after another, limiting its reach.
What is “Composition” and what is “Composition is Better than Inheritance”
“Combination is better than inheritance”, so far I do not know what it means, and I have not seen a convincing answer. I feel like this sentence is a lot like “high cohesion low coupling” which is true but doesn’t really work. For example, “decorator pattern” is a classic example of composition. OK, after talking about “decorator pattern”, I kind of understand this pattern, but I still don’t understand the meaning of “composition is better than inheritance”. Guess it’s just gonna have to be a hunch, huh?
“Inheritance” is not so nasty, and “multiple inheritance” may be avoided
Take up the last paragraph. It seems that there are always people who contrast “combination” with “inheritance” and then selectively cite examples of what is bad about “inheritance” and what is good about “combination” and come to the conclusion of the above statement. Such articles are often guilty of “survivor bias” and often contain a lot of personal goods without much nutrition.
In fact, I don’t think one is better than the other, because they are just two different means. For example, you can eat with a knife and fork, or you can use chopsticks. Inheritance is not big V blowing so disgusting, after all, is also according to the actual problem and the invention of the means, can not be useless? It’s actually great to use simply, and you can reuse a lot of code.
But Java has a particularly bad culture of creating too many classes and then designing very complex inheritance (interface) relationships that are wrapped up in layers of code with the real intent hidden behind them. What is more, almost every class has an interface, which is supposed to extend design, but is actually “over-engineering”. This kind of atmosphere down, let people write Java lack of happy feeling, I guess the big V criticism of Java mainly refers to this bar.
Anyway, I am very happy to write Java, where I want to write, and do not deliberately create a lot of interface, the worst to later interface extraction line, anyway, now IDE tools are so powerful.
“Design patterns” are useful
This thing is really hard to force, if you force “design mode”, basically die miserably, it is better not to do. In the process of project reconstruction, I mainly used the “factory method, template method” these several modes, come out of the code is really pleasing to the eye. In particular, the “template approach” pattern fits so many scenarios in our business processes that I use almost all of them to fix bugs.
OOP and FP
OOP understand a bit, FP basic do not understand, do not understand the field, will not comment at will. One of the things I find about FP is that there are always people who compare IT to OOP, list a few disadvantages of OOP and a few advantages of FP, and then criticize OOP and conclude that FP is better. In fact, there are many concepts and objects in the computer world that do not fit the analogy, just like the index and middle fingers, which perform different functions and perform different functions in real life, allowing us to perform a variety of actions. If you just put them against each other, you can’t have one and you can’t have the other. Isn’t that bullshit? OOP, like FP, is two different approaches in different contexts, and it makes little sense to draw conclusions about which is better than the other. Each performs its own duties, is being used integrally, just is the way that solves.
Hierarchical thinking
Any software is layered, and layering makes it significantly easier for the brain to think, leading to the design of larger software. In this context, concepts like “modularity” and “layering” are basically different emphases of a concept that basically means the same thing.
But stratification can not be too fine too broken too much, so the basic to the opposite, brought cumbersome. “The golden mean” is the absolute principle, which depends on accumulated practical experience.
Refactoring, Clean Code
Two good books, very influential. I read it several times, and every time I read it, I learned something new. The more I read it, the more I gradually absorbed what the author said.