N Mars written long ago

N Mars written long ago

Originally published on: 2004-3-26

After reading so many books, it seems that it is time to summarize what we have learned.

1. Object-oriented core: Polymorphism
Everyone knows the three elements of object-oriented: "encapsulation, inheritance, polymorphism ". However, in my opinion, the most important thing is "polymorphism. Why? Encapsulation is mainly considered as a security factor, and inheritance appears to achieve polymorphism. Polymorphism, which is the core of the standard object-oriented design (OOD.

Masters warned us that good design is "interface-oriented", so as to ensure minimum coupling between modules. Once the high-level business logic depends on the underlying details, the entire system will have a rigid smell. (At the same time, it violates the dependency-caused principle.) once the underlying details change, the business logic unrelated to the upper layer also has to change. This is true for traditional process-oriented engineering.

Then, how do we call "interface-oriented? This depends on polymorphism. ClientCodeYou only need to use interfaces, and the classes with the underlying details implement these interfaces. No matter how the underlying layer changes, the high-level logic can always remain unchanged as long as the polymorphism feature is used.

Oh, that is to say, the interface does not belong to the underlying class in the traditional understanding, but to the client (high-level ).

2. Control inversion (callback function)
Before I started to look at the design model, I was confused when I saw the "Hollywood model": Don't call us, we will call you.

But now I have finally gotten into the door. (Thanks 《ProgramXiong Jie series in memberArticle). Control inversion, that is, the control of the program process is moved from the customer to the framework.

In. net, C # uses delegate to process events. This is the callback function. If you want to respond to an event, you only need to encapsulate your event processing function with delegate and link it with the event. As long as an event occurs and the delegate multicast feature is used, you can call each registered eventhandler (this is "we will call you)

However, I don't know how to implement event processing in Java. I will study it later.

3. Control reversal (continued)
During my graduation project, I used interfaces to replace idatabase for the unit test of transaction. In unittest, I used a mockdb that implements idatabase to simulate the database. When the code is actually running, I only need to replace mockdb with the class that implements the idatabase interface in the real dataaccess layer.

However, after reading the latest flower article on programmer, I found that this is a type of control reversal. I was so proud of myself: It seems that I and the master also wanted to go to Asia together.

However, let me think about it. I just used it unconsciously, and the master put forward this viewpoint theoretically. This is the gap... 555 ....

4. Design Mode
I didn't buy the design pattern book because I felt that the diagram in it was not a standard UML diagram. -_-B. Maybe gof's 2nd design model is better.

I learned most about the design patterns from Uncle Bob's agile development: Principles, models, and practices.

As a matter of fact, I have realized that if I use the design pattern randomly in the project, it is entirely possible to fall into the trap of "over-design", which is also the most feared thing. Kent also said that this is also a bad smell: "unnecessary complexity ".

Some predecessors have said that there are several major stages in learning the design model: In the early stage, writing anything is a model; in the later stage, it is no longer a model for the model. (Roughly so, I forgot my words ......)

Therefore, the principle of OOD: single function principle SRP, open/closed principle OCP, dependency inversion principle dip, liskov replacement principle LSP, interface separation principle ISP, these are the essence of Ood. Thank you, Uncle Bob, for summarizing this!

However, for a beginner, there are only a few models that I can understand now. What are the other models? Come on.

5. Unit Test
Kent's masterpiece: TDD, the e-version I bought, seems a headache. (this should blame me for my non-course e text, but when I read refactoring, I felt like Kent needed to understand the flower text.) In TDD, kent has brought the unittest first principle to the extreme.

I can understand that TDD is really helpful for removing the coupling between modules (in order to be unittest, you have to write high cohesion and low coupling classes). In my graduation project, TDD is also used.

However, I seem to feel that TDD's strength lies in solving the underlying details. If we need to consider the overall framework of the entire project, it is definitely not feasible to rely on TDD alone...

PS: The xunit Member: nunit under. NET is really useful, and their developers are enthusiastic ~~ (I am blushing again for the exception problem ). We hope to make contributions to this open-source project in the future.

6. Unit Testing and restructuring
The relationship between the two is that reconstruction is impossible without unit testing. (In addition, the purpose of refactoring is to design the model... Hu, all of which are intertwined)

Refactoring does clarify the readability of the entire code, while unit testing also ensures the security of refactoring. It can prevent you from accidentally damaging any function during refactoring.

Well, write so much first. I admire the Masters of agile consortium. Their ideas always make me feel overwhelmed. I hope that I can continue to use agile development methods in my practical work,

However, it is really difficult for me to find people who are equally interested in Agile development... many people have never heard of unittest...

Is my interest different from the actual situation? I don't know