[Excerpt] Some Software Design Principles

From coolshell

 

However, these principles seem not difficult, but they are not easy to use. My experience is as follows: (I think this is a process from theory to Application)

1. You can understand these principles first or on the surface.
2. But do not use it immediately.
3. Observe and summarize others' or their own designs in work and study.
4. Looking back at these principles, I believe you will have some of your own experiences.
5. Practice it appropriately.
6. Step 3 of Goto.

 

 

You ain't gonna need it (yagni)

In short, this principle is to consider and design only the necessary functions to avoid over-design. Only implement the functions currently required. You can add more functions later.

• Do not increase complexity if necessary.
• Software development is a communication game.

In the past, there was an article about over-reconstruction on this site. This example is a counterexample of this principle. The WebSphere designer said that he had over-designed the product. When designing a system, our programmers or architects will consider a lot of scalability, which leads to a lot of compromise between the architecture and design, and finally lead to project failure. This is an ironic lesson, because the project life cycle was originally expected to be extended as much as possible, but the result shortened the life cycle.

Reference: Http://en.wikipedia.org/wiki/You_Ain%27t_Gonna_Need_It

Law of Demeter-meter Law

Law of Demeter, also known as principle of least knowledge, came from a project called Demeter at Dutch University in 1987. Craig larman calls law of Demeter "not to talk to strangers ". In the "programmer's cultivation path", the chapter of the level of detail is called the "coupling solution and the dimit law ". There are some very vivid metaphors about the dimit law:

• If you want your dog to run, do you say "yes" to the dog or "4" to the dog legs?
• If you go to the store to buy things, will you give the money to the clerk, or will you give the wallet to the clerk for him to take?

Talking to the dog's limbs? Ask the clerk to take the money from his wallet? This sounds crazy, but it's almost strange in our code.

The following is a formal description of the dashboard:

For a method 'M' in the object 'O', m should be able to access only the methods in the following object:

1. Object O;
2. Component Object directly related to O;
3. Objects Created or instantiated by method m;
4. The object used as the parameter of method M.

In the book "clean code", there is a section of Apache framework that violates the details of the Code:

Final string outputdir = ctxt. getoptions (). getscratchdir (). getabsolutepath ();

Such a long string of details about other objects, detailed details, detailed details ...... Added coupling, making the code structure complex and rigid and difficult to expand and maintain.

In refactoring, there is a kind of "feature envy" (Attachment complex) in the context of the Code. The image describes a situation that violates loc. Feature envy means that an object is more interested in the content of other objects. That is to say, it always envy the members, structures, or functions of other objects and call others' things. This structure is obviously unreasonable. Our program should be "Shy ". The customer's wallet cannot be taken out just like the clerk who did not treat himself as an outsider in the previous example. The "Shy" program only talks with your recent friends. In this case, you should adjust the structure of the program so that the object has its own envy feature, or use reasonable design patterns (such as facade and mediator ).

Reference: Http://en.wikipedia.org/wiki/Principle_of_Least_Knowledge