Design principles and design patterns (design principles and design patterns)-Robert C. Martin

What is software architecture? The answer is multitiered. At the highest level, there are the architecture patterns that define the overall shape and structure of software applications. down a level is the architecture that is specifically related to the purpose
The software application. yet another level down resides the architecture of the modules and their interconnections. this is the domain of design patterns, packakges, components, and classes. it is this level that we will concern ourselves with in this chapter.

What is software architecture? The software architecture is divided into multiple layers. The highest-level architecture model defines the global shape and structure of the software. The next layer is the architecture related to the purpose of specific software. The next layer is the architecture related to the interaction between modules in the software and various modules, which belongs to the design pattern, package, component and class fields. This section focuses on this level.

Our scope in this chapter is quite limitted. There is much more to be said about the principles and patterns that are exposed here. Interested readers are referred.

This section covers a limited scope. The design principles and patterns mentioned in this article also have a lot of content. Interested readers can query related articles.

Architecture and dependencies (Architecture and dependency) what goes wrong with software? The Design of program software applications begins as a vital image in the minds of its designers. at this stage it is clean, elegant, and compelling. it has a simple beauty that makes the designers and implementers itch
See it working. Some of these applications manage to maintain this purity of design through the initial development and into the first release. What problems does the software have? Software initially comes from an important idea in the designer's mind. At this time, it is clear, elegant, and compelling. At this time, the software has a simple aesthetic, so that designers and implementers are eager to see how it works after it is completed. However, only a portion of the software has been designed to be clear and elegant in the process from initial development to final release.
But then something begins to happen. the software starts to rot. at first it isn' t so bad. an uugly Login here, a clumsy hack there, but the beauty of the design still shows through. yet, over time as the rotting continues, the uugly festering sores and boils
Accumulate until they dominate the design of the application. the program becomes a festering mass of code that the developers find increasingly hard to maintain. eventually the sheer effort required to make even the simplest of changes to the application
Becomes so high that the engineers and front line managers cry for a redesign project.
But some bad things happen. The software began to rot ". It wasn't too bad at first. Some ugly "tumors" and clumsy "tricks" appeared in the code, but we can also see the elegance of the original design. However, as time went on, the ugly Code began to spread until the code dominated the entire software. Developers find it increasingly difficult to maintain these large numbers of rotten code. In the end, it became very difficult to make the simplest modifications to the software. Engineers and front-line managers began to pray to redesign the entire project. Such redesigns rarely succeed. Though the designers start out with good intentions, they find that they are shooting at a moving target. The old system continues
Evolve and change, and the new design must keep up. The warts and ulcers accumulate in the new design before it ever makes it to its first release. On that fateful day,
Usually much later than planned, the morass of problems in the new design may be so bad that the designers are already crying for another redesign. The effort to redesign the project is rarely successful. Although the designers initially had good motives, they soon discovered that they were "attempting to shoot mobile targets ". Old systems are constantly evolving and changing, and new designs must follow these changes. Just like the first version of the software, "tumor" and "Ulcer" are accumulated in the new design version. Soon, the new design fell into the "mud", and the designer began to pray for another redesign.
Symptoms of row.design (symptoms of rotten design) there are four primary symptoms that tell us that our designs are rotting. they are not orthogonal, but are related to each other in ways that will become obvious. they are: rigidity, fragility, immobility, and viscosity.

There are four major symptoms that tell us that the design of the software is "rotten ".Rigidity, weakness, fixation, and viscosity.

Rigidity. Rigidity is the tendency for software to be difficult to change, even in simple ways. every change causes a cascade of subsequent changes in dependent modules. what begins as a simple two day change to one module grows into a multiweek marathon
Of change in module after module as the engineers chase the thread of the change through the application.

Rigidity: Rigidity means that software is hard to change, even simple changes. Every small change to the software will lead to a series of Domino changes in the associated modules. In the end, the change of one module takes only two days and eventually becomes a marathle change of the module connection module that takes the developer several weeks.

When software behaves this way, managers fear to allow engineers to fix non-critical problems. this reluctance derives from the fact that they don't know, with any reliability, when the engineers will be finished. if the managers turn the engineers loose on
Such problems, they may disappear for long periods of time. The software design begins to take on some characteristics of a roach motel -- engineers check in, but they don't check out.

When the software is rigid, the manager is afraid to ask engineers to repair non-fatal faults. Because they cannot know when the engineer will be able to end the software modifications at the beginning. It may take a long time for managers to let engineers handle these faults. Software design began to look like a cockroach trap-a cockroach (Engineer) went in, but never again.

When the manager's fears become so acute that they refuse to allow changes to software, official rigidity sets in. Thus, what starts as a design deficiency, winds up being adverse management policy.

When the manager's fear becomes very serious, they reject any changes to the software. This introduces "official rigidity" in the software ". Defects in the initial design lead to the final management policy problem.

Fragility. Closely related to rigidity is fragility. fragility is the tendency of the software to break in your places every time it is changed. often the breakage occurs in areas that have no conceptual relationship with the area that was
Changed. Such errors fill the hearts of managers with foreboding. Every time they authorize a fix, they fear that the software will break in some unexpected way.

Fragile: "Fragile" is closely related to "rigid. Vulnerability means that every change in the software will cause the software to be broken into multiple fragments. The broken module code is often not conceptually associated with the modified module code. This kind of error gives managers a strong hunch that every time they allow code modifications, they are afraid that some unknown code of the software will be broken ".

As the fragility becomes worse, the probability of breakage increases with time, please approaching 1. Such software is impossible to maintain. Every fix makes it worse, introducing more problems than are solved.

When the software becomes more and more vulnerable, the higher the possibility of the software being broken, And the chance approaching 100%. Such software is difficult to maintain, because every time a fault is fixed, the software becomes more vulnerable and introduces more problems.

Such software causes managers and MERs to suspect that the developers have lost control of their software. distrust reigns, and credibility is lost.

Such software has led managers and customers to doubt that developers have lost control of the software. Untrusted sentiment begins to spread, and software credit begins to be lost.

Immobility. Immobility is the inability to reuse software from other projects or from parts of the same project. it often happens that one engineer will discover that he needs a module that is similar to one that another engineer wrote.
However, it also often happens that the module in question has too much baggage that it depends. after much work, the engineers discover that the work and risk required to separate the desirable parts of the software from the undesirable parts are too
Great to tolerate. And so the software is simply rewritten instead of reused.

Fixed: "Fixed" means that the software code cannot be reused by other projects or other parts of the same project. This occurs when a software engineer finds that the function of a required module is very similar to that of a software module written by another engineer, or finds that a software module depends on too many external modules, this module must be restructured. After a lot of work, engineers found that the risk of trying to separate the required software code from the rest of the software was too high to be tolerated. Therefore, they eventually overwrite the Code, rather than reusing the existing code.

Viscosity. Viscosity comes in two forms: viscosity of the design, and viscosity of the environment. when faced with a change, engineers usually find more than one way to make the change. some of the ways preserve the design, others do not
(I. e. they are hacks .) when the design preserving methods are harder to employ than the hacks, then the viscosity of the design is high. it is easy to do the wrong thing, but hard to do the right thing.
Viscosity: "viscosity" comes from two aspects: Design and environment. When the software is changing, software engineers will find multiple ways to modify the software. Some methods can retain the design-time architecture, while others cannot. When these methods that preserve the good structure at design time are more difficult to implement than other methods, we call it "a high design viscosity ". That is, when the software engineer is faced with software changes, it is easy to do the wrong thing, and it is difficult to do the right thing (retain the software architecture at design time ).
Viscosity of environment comes about when the development environment is slow and inefficient. for example, if compile times are very long, engineers will be tempted to make changes that don't force large recompiles, even though those changes are not optimal
From a design point of view. if the source code control system requires hours to check in just a few files, then engineers will be tempted to make changes that require as few check-ins as possible, regardless of whether the design is preserved.
The viscosity of the environment comes from the slowness and inefficiency of the development environment. For example, if the Compilation Time is very long, engineers will execute the changes that can avoid large-scale compilation, even if these solutions are not optimal from the design perspective. If it takes several hours to submit a few files to the source code control system, the engineers will try to execute the modifications that can reduce the number of submitted files, whether or not these solutions retain the software architecture at design time.