OO design patterns and principles

Author: cherami

1.1 symptoms of row.design)

There are four major signs that the software design is "rotten. They are not independent, but interrelated. They are too stiff, too fragile, reusable, and too slow to stick. Download dl.bitscn.com

1. too rigid rigidity makes the software difficult to change. Every change will result in a series of mutually dependent module changes, and the Project Manager will not dare to change it, because he will never know when a change will be completed.

 

2. Too fragile fragility the fragility may cause system errors in many places when software changes. And Errors often occur in modules that are conceptually unrelated to the changes. Such software cannot be maintained, and every maintenance makes the software more difficult to maintain. (Vicious circle) www.bitscn.com

3. inreusable immobility makes it impossible for us to reuse software in other projects or other places in this project. The engineer found that the workload and risks of separating the part he wanted to reuse were too large to offset his enthusiasm for reuse. Therefore, the software was rewritten instead of reused.

4. Too high viscosity has two forms: the designed viscosity and the environment's viscosity. when changes are required, engineers usually find that there are more than one method to achieve the goal. However, some of these methods will retain the original design, while others will not (that is, these are hacks ). If a design compares engineer errors to a correct one, the design's viscosity will be high.

 

High Viscosity of the environment means that the development environment is slow and inefficient.

 

2. Object-oriented class design principles

 

2.1 Principle of opening/disabling the open closed principle (OCP)

A module shoshould be open for extension but closed for modification. A module should be opened only during expansion (inside the exposed module) and closed during modification (the module is in a black box ).

This is the most important of all object-oriented design principles. The principle is: we should be able to avoid modifying the module.Source codeTo change the behavior of the module.

 

2.1.1 dynamic polymorphism (Dynamic polymorphism) Network Management bitscn_com

2.1.2 static polymorphism Network Management Alliance bitscn_com

Another technology that uses OCP is to use a template or model. For example, the listing 2-3.logon function does not need to be modified.CodeYou can expand the Architecture Objectives of multiple types of modem. 2.1.3 OCP (elastic tural goals of the OCP)

 

By following the OCP applications, we can create modules that can be extended without modifying internal code. That is to say, in the future, we will add new features to the module, as long as new code is added, without changing the original code. It may be difficult to make the software fully comply with the OCP on pages 7 and 17 in total, but even if it only partially complies with the OCP, the structural performance of the entire software will be greatly improved. We should remember that it is always good to make changes not to affect the code that is already working normally.

2.2 liskov replacement principle the liskov substitution principle (LSP)

Subclasses shoshould be substitutable for their base classes. Subclass should be able to replace its base class.

 

See figure 2-14. The derived class should be able to replace its base class. That is to say, a user of the base class can work normally if it is passed to a devrived class rather than the base class as a parameter. Network Management Alliance bitscn_com

2.3 Dependency inversion principle the Dependency inversion principle (DIP) 1 Network Management bitscn_com

Depend upon dependencies actions. Do not depend upon concretions. Dependency abstraction. Do not depend on specifics.

 

If OCP declares the purpose of the OO architecture, dip describes its main mechanism. The dependency inversion policy depends on interfaces, abstract functions, or abstract classes, rather than specific functions and classes. This principle is to support the power behind component design, COM, CORBA, EJB, and so on.

 

2.3.1 dependency abstraction depending upon registractions. Network Management u.bitscn.com

This principle is very simple. Every dependency in the design should be an interface or abstract class. Do not depend on any specific class.

Obviously, such restrictions are severe, but we should try our best to abide by this principle. The reason is very simple. The specific module changes too much, while the abstraction changes much less. Moreover, the abstraction is a "hinge" point where the design can be bent or expanded without any changes (OCP ). Download dl.bitscn.com

2.4 interface isolation principle the interface segregation principle (ISP) Network Management ujia u.bitscn.com

'Your client specific interfaces are better than one general purpose interface. Multiple customer-related interfaces are better than one common interface.

 

ISP is another principle that supports components such as COM technology at the underlying layer. Without it, the ease-of-use and reusability of components and classes will be greatly reduced. The essence of this principle is very simple: if a class has several users, it is better to create a specific interface for each user than to load all the methods required by the user, and let the class implement these interfaces respectively.

 

3. Principles of package Architecture

Class is indispensable, but it is not enough for a design of the organization. A package with a larger granularity will help this. But how should we coordinate the subordination between classes and packages? The following three principles all belong to the package aggregation principle, which can be helpful to us.

 

3.1 package aggregation principles

 

3.1.1 equivalent principles of release reuse the release reuse equivalency principle (REP) 1

The granularity of reuse is the publishing granularity. The granule of reuse is the granule of release. A reusable component (component, a class, a group of classes, etc.) can be reused only after they are managed by a release system. Users do not want to use components that are forced to be upgraded after each change. Therefore, even if a developer releases a new version of reusable components, the developer must support and maintain the old version so that users can be updated with the new version.

Therefore, one of the criteria for determining which classes are placed in a package is reuse. Because packages are the smallest units for release, they are also the smallest units for reuse. The architect should put reusable classes in the package.

 

3.1.2 principle of joint closure the common closure principle (CCP) 2

Put the changed classes together. Classes that change together, belong together. A large development project is usually divided into many mesh packages. Managing, testing, and releasing these packages is not trivial. In any released version, the larger the number of changed packages, the more reconstruction, testing, and deployment. Therefore, we should minimize the number of packages modified during the product release cycle, which requires us to put the changed classes together (the same package ). Network Management ujia u.bitscn.com

3.1.3 principle of joint reuse the common Reuse Principle (CRP) 3

 

Different types of heavy lifting should not be put together. Classes that aren't reused together shoshould not be grouped together. dependencies on a package are dependencies on everything in the package. When a package changes, all users of the package must verify that the package is still running, even if the package is used without any changes.

 

For example, we often encounter the need to upgrade the operating system. When a developer releases a new version, our upgrade is a matter of time, because the developer will not support the old version, even if we are not interested in the new version, we have to upgrade.

 

If we put different classes together, we will also encounter the same thing. A change to a class unrelated to us also produces a new version of the package. We are forced to upgrade and verify whether the package affects normal operation. Download dl.bitscn.com

3.1.4 tension between package aggregation principles tension between the package cohesion principles

 

These three principles are actually mutually exclusive. They cannot be met at the same time, because each principle is only applicable to one aspect and only benefits some people. Both rep and CRP are good for people who want to reuse components, and CCP is good for maintenance personnel. CCP makes the package as big as possible (after all, if all classes belong to one package, there will be only one package change); CRP tries to make the package smaller.

 

Fortunately, the package is not static. In fact, during the development process, the conversion, addition, and deletion of packages are normal. In the early stages of project development, software architects established a package structure system. At this time, CCP was dominant and maintenance was only an aid. After the architecture is stable, the software architect will reconstruct the package structure. At this time, the rep and CRP should be used as much as possible to facilitate the reuse of components. Network Management Alliance bitscn_com

3.2 package coupling principle the package coupling principles.

The following three principles focus on the relationship between packages. China Network Management Alliance bitscn.com

3.2.1 no-dependent loop principle the Acyclic Dependencies Principle (ADP) 1

The dependency between packages cannot form a loop. The dependencies between packages must not form cycles. Because the package is the granularity of release. People tend to save human resources, so engineers usually write only one package instead of a dozen packages. This kind of tendency is magnified due to the package aggregation principle, and then people will combine the related classes into a group.

As a result, engineers discovered that they would only change a few packages. Once these changes were completed, they could release their changed packages. But they must be tested before release. To test, they must compile and concatenate all the packages on which their packages depend. Network Management ujia u.bitscn.com

3.2.2 dependency stability principle (Stable Dependencies Principle, SDP)

Depending on depend in the direction of stability. Although this principle seems obvious, there are still many things to explain in this regard, and stability is not necessarily understood by everyone. Download dl.bitscn.com

What is stability? Standing on a coin, is it stable? You may say no. However, unless disturbed, the coin will remain in that position for a long time. The coin remains unchanged, but it is hard to think that it is stable. Stability depends on the workload to be changed. The coin is unstable because it only requires a small amount of work. From another angle, the table is much more stable.

 

What does software mean? A software package is hard to be changed due to many factors: code size, complexity, transparency, and so on. If many other packages depend on one software package, the software package cannot be changed. If a package is dependent on many other packages, the package is stable, because any change to this package may require many other packages. Network Management Alliance bitscn @ com

3.2.3 stable abstraction principle (SAP)

 

A stable package should be an abstract package. Stable packages shocould be abstract packages. We can imagine the applicationProgramThe package structure should be a set of interconnected packages, where the unstable package is at the top, the stable package is at the bottom, and all dependencies are directed down. The top packages are unstable and flexible, but the bottom packages are difficult to change. This leads to a dilemma: do we want to design the package as hard to change? Network Management Forum bbs_bitscn_com

Obviously, the more packages that are difficult to change, the less flexibility we have for the entire software design. But there seems to be a hope to solve this problem. It is indeed difficult to change the High-stability package located at the bottom of the dependent network, but such package is not difficult to expand if it complies with OCP.