Fine reading - package design principle
Rayleahaan@hotmail.com
In view of the importance of the package design, the classic Agile Software Developent: Principles, Patterns, and Practices recently rereaded the design of the design of the package, and the following contents are mainly extracted here, and there are some own understanding.
1 morning syndrome and package release
Have you ever had such an experience? After working all day, I finally finished a feature, I couldn't find that the function was no longer working next morning. what is the reason? Because someone is getting better than you, and changed something you rely on! This is the so-called "morning syndrome". The team suffered from "Morning Syndrome" often could not build a stable version for a few weeks. Everyone is busy changing their code over and over again, trying to make it compatible with the recent changes made by others, thus It caused a team of morale and low efficiency, caught in terrible integrated hell. To this end, some teams prohibit Check IN during integration, which is obviously not a good way. On the one hand, if there is no technical means to avoid intentional or unintentional Check IN, on the other hand, the developer does not affect the current development. The integrated version may have to handle version management, and then it makes it difficult to collaborate between team members.
Publishing package can effectively avoid the occurrence of syndrome in the morning. The reason for causing the syndrome after the morning lies that the bags dependent on the relying on changes, which makes the dependehere to work on a unstable basis, and the dependence changes, dependent must make compatible changes. With packet distribution mechanism, dependents must choose a specific version of the redeeted package, and the package after the package is not allowed, so the dependency relies on things will not change; at the same time, Any changes must be released as a new version, and the dependeherens have the right to decide whether to adopt this new version, in other words, whether to accept the redeemer's change is determined by the dependent, but before, dependent is not Do not passively accept changes by the dependent.
2 pack design principles
To publish the package, first design better, a larger application, a lot of combinations of the package, only put it looks like a class that is suitable, the same package, it is often A bad bag structure: It is difficult to publish, it is not easy to reuse, it is difficult to change, etc., this package structure may be more troubles. Obviously we need some principles to guide the division of the package, the following list, the top three principles are used to guide the class into the package, the latterness of the package, the last three principles used to handle each other Relationship, payment of the coupling of the package.
2.1 REP reuse release equivalence principles
The granularity of the reuse is the particle size released.
If the software in a package is used to reuse, then it can no longer contain software not designed to reuse purposes. In other words, the software in a package is either reusable, or it is not reusable. Simply declaring a class is a reusable practice is unrealistic, and anything we reuse must be published and tracked. If a package contains reusable classes and non-reusable classes, then when the category is changed, the publishing of a package is required, and the original unaffected reuse needs to decide whether to adopt a new version. And use new versions possible compile, connection, and test work. These internal consumption operations should be avoided.
2.2 CRP common reuse principle
All classes in a package should be commonly reused. If you reuse a class in the package, you have to reusable all classes in the package.
In most cases, a reusable abstraction requires multiple classes to express, the principle specifies that these classes should be in a packet, and the class belonging to different abstractions should not be in a packet. At first glance, this principle is a bit similar, but it is actually different, for example, abstract A includes classes A1, A2, A3, abstract B contain classes B1, B2, B3, from the REP principle, this package is not What is wrong, because the software of the package is reusable, but it violates the CRP principle, because the reuse can only use A abstract classes or only b abstract classes, such as an abstract change will result in The package is re-released, although the release is meaningless to a abstract user, but they still need to re-verify and re-release, which will have a lot of effort. 2.3 CCP commonly closed principles
The categories used in the package should be closed together for changes in the same type of nature. A change will have an impact on a packet, and all classes in the package will affect any impact on other packets.
REP and CRP pay attention to reuse, CCP focuses on maintainability. For most applications, the importance of maintainability is more reusable. A variation (including demand, design, etc.) may cause multiple class changes, CCP requires us to put these classes in a package while putting those unaffected classes in other packages, So a package only has a cause of change, a change is only an impact on a package, which greatly reduces the number of re-released times and re-issuing the impact of other packets, thereby improving software maintainability.
2.4 ADP ringless dependence principle
There is no loop in the redeemed diagram of the package.
If there is a ring in the relationship of the package, all the packages on the ring must be published simultaneously, as shown below, since P3 uses a class in P1, the dependency loop is formed, to release P1, must first release P2 And P3, and the P3 must be released first, P1 and P2, P1, P2, P3 have actually become the same big package, which is unavoidable to work on these packages to be subject to morning syndrome. There are two ways to remove the dependent ring:
Use DIP. As shown in the figure, separate the interface and achieve the new package. As shown in the figure, move the type of P1 and P3 depending on a new package.
2.5 SDP stable dependence principle
During the steady direction.
If a package is dependent on a lot of packages, then it is stable, because it is often necessary to make all the changes that it can be compatible with its changes to it. All packets in a system should not be stable, because if such words, the system will be difficult to change. SDP guides us to deal with the relationship between stabilizers and unstable bags: unstable packages should depend on stable bags, and a package should depend on bags than him. You have designed a unstable package, expect it to change with changes, but it will never be changed after it is dependent by a stable package, which makes the software difficult to modify and change.
2.6 SAP Stable Abstract Principle
The stability of the package should be consistent with its stability.
A system's high-level architecture and design decisions should be placed in a stable package, because these architecture decisions should not change frequently, but the characteristics of the stable package will make these architectural decisions, clearly only use stability to measure one The package is not enough, SAP tells us that the stable package should also be abstract. It should include abstract classes, and the system is expanded by implementing abstraction classes in this stabilizing package, and the stabilizing package does not need to be modified, which is not far flexible while maintaining stability.
3 pack design process
A few years ago, when I didn't know the design principles of these packages, I believe that the package is the functional decomposition of the system's high-level function. It should be designed at the beginning of the project, and the results have failed. In fact, there is almost no relationship between the rely of the package and the functions of the depiction system, which is a system-constructive mapping map. At the beginning of the project, we still don't know which classes are in the system. Don't say the relationship between them. In this case, it is not only difficult to create a package dependencies, even if it is created, it is likely to be unreasonable. The dependency structure of the package should be to grow and evolve with the logic design of the system. You don't have to consider the package at the beginning of the project. The system still organizes the class of granularity. With the development of the development, more and more Avoiding the need for the presence of the presence in the morning, and the principle of using the CCP principle will be released to the inclusion of the class organizations that may change. As the system grows, we have begun to pay attention to the creation of reusable elements. So starting to use CRP and REP to guide the combination of the package. Finally, use the ADP, SDP, SAP to measure the package diagram, remove bad dependence. 4 Do you really use the package release mechanism?
If a team does not use a product, it may be called: We are obviously released, you see, this is not the 1.0, 1.2 version we released? In fact, any product is inseparable from the release of the package, but for such a team, there is only one package in their system, that is, the entire system, and the release of the package is often in the morning. After the baptism of post-syndrome, it was conducted after the development of basic, in fact, we should use this mechanism in the development of the product, so that the development process of the product will carry out reasonable, orderly, The product can be delivered as soon as possible.
Last Modified: Thursday, April 14th, 2005
HTML Conversion by
TEX2PAGE 2005-02-27
