(fine) Subcontracting principles/Package design principles/components (package) design principles

http://blog.csdn.net/it_man/article/details/38292925

A component, or assembly, refers to a binary unit that can be deployed independently, typically in the form of a DLL . For large software systems, good component design can break down the system into smaller components, so that each development team can focus on a single component without caring for the entire system.

Component design requires adherence to the following principles:

1. Reuse - release Equivalence principle (REP)

That is, the granularity of reuse is the release granularity. Classes in a component are either reusable or cannot be reused.

1. Common reuse principle (CRP)

All classes in a component should be reused, and all classes in the component should be reused if one of the classes in the component is reused. That is, the classes that are put into a component are inseparable, and the case that relies on only a subset of the classes does not exist.

1. Common closure principle (CCP)

That is, a component should not include multiple causes that cause change. All classes in a component are collectively closed for changes of the same nature, and a change that affects a closed component affects all classes in that component. However, the other components will not have an impact. This principle is similar to the open closure principle, that is, the modification should be closed, but the extension should be open.

1. The principle of no-ring dependence

A loop cannot appear in a dependency graph on a component. By dividing the system into different redistributable components, each component is responsible for one or a group of developers as a single unit of work. It is published to other developers and is tracked by assigning a version number to the component. The impact on the component's changes should not have to be extended to other components.

1. Stability Abstraction principle (SAP)

The degree of abstraction of a component should be consistent with its degree of stability. That is, a stable component should also be abstract, so that his stability will not be extended. On the other hand, an unstable component should be specific, because his instability makes its internal code easier to modify. So if a component is stable, then he should include some abstract classes so that he can be extended.

Reuse Publishing Equivalence Principle

Objective

Robert C. Martin has summarized the principles that should be followed in object-oriented design (OOD), which are known as "Principles of OOD", and related articles on "Principles of OOD" can be obtained from Object Menter.

This article describes the release reuse equivalency Principle (REP): The Reuse publishing equivalence principle.

Profile

The granule of reuse is the granule of release.

The granularity of reuse is equivalent to the release granularity.

The concept of reuse

Reuse is primarily viewed from the user's point of view.

For the user, using a publishing unit (component, class, class, etc.), if the author has modified it for some reason to publish a new version, users will expect that after upgrading to a new version, the original system will not affect the normal operation.

In other words, for an element (component, class, class, etc.) that can be reused (for use by other users or systems), the author should promise that the new version will be compatible with the old version. Otherwise, the user will refuse to use the element.

Robert C. Martin's definition of reuse:

I prefer to define reuse as follows. I reuse code if, and only if, I never need to look at the source code (other than the public portions of header files). I need only link with static libraries or include dynamic libraries. Whenever these libraries is fixed or enhanced, I receive a new version which I can then integrate to my system when OPP Ortunity allows.

Code can be thought of as reusable code, when and only if:

-its users (hereinafter referred to as the user) need not look at its source code

-the user simply joins the static library or contains the dynamic library

-When the library changes (error correction, enhancements), users only need to get a new version can be integrated into the original system

How do you reuse it?

To be reusable, a component must have a well-designed structure that contains all the elements that must also be reusable.

Because if a publishing unit designed for reuse contains elements that are not reusable, the user has to change the original system to accommodate the new version when the non-reusable elements change. This clearly violates the definition rules for reuse.

In other words, a publishing unit designed for reuse purposes cannot contain elements that are not reusable, and it becomes non-reusable if it contains elements that are not reusable.

Publishing units

When a user uses a reusable component that has been modified by the author, the user wants to be notified and then decides whether to upgrade or upgrade the time. In order to enable the upgraded system to function properly, the user also wants the author to have a specification release, including the version number, the description of the class library and so on.

Once the user decides to upgrade the new version, the user will have to include all the class libraries included in the new version, regardless of whether the changes affect the user.

The rep rules that reuse granularity cannot be less than the release granularity, and all reusable elements must also be published together.

The release granularity can be a package (component), or an entity such as a class, but an application often contains many classes, so a package (component) with a larger scale is more appropriate as a release granularity.

The reuse publication equivalence principle shows us the design guidelines for the package:

The elements (classes) in a package are either reusable or non-reusable.

Summary

The Reuse publishing Equivalence principle (REP) regulates the principle of package design from a user point of view: When designing a package, the elements that should be included in the package are either reusable or not reusable.

Resources

Granularity by Robert C. Martin.

Principles and Patterns by Robert c. Martin.

The principle of no-ring dependence

Objective

Robert C. Martin has summarized the principles that should be followed in object-oriented design (OOD), which are known as "Principles of OOD", and related articles on "Principles of OOD" can be obtained from Object Mentorr.

This article describes the acyclic Dependencies Principle (ADP): The principle of no-loop reliance, or non-cyclic reliance.

Profile

The dependency structure between packages must be a directed acyclic graph (DAG). That's, there must be no cycles in the dependency structure.

The dependency structure between packages must be a direct acyclic graph (DAG). In other words, loops are not allowed in the dependency structure (circular dependencies).

To another argument is:

The dependencies between packages must not form cycles.

The dependency between packages cannot be a ring form.

Dependency of the package

If a class in package a refers to a class in package B, we call package a dependent on package B.

"Dependent" in the specific programming language, if a depends on the b,c/c++ language in a package of files/classes with the # include File/class in the B package, the Java language is a class in a package through the import statement into the class in package B.

Figure 1 (Package a dependency package B)

The dashed line represents a dependency, the arrow indicates the direction of the dependency, and the side of the arrow is the dependent package.

The loop dependency of the package

We discussed above and graphically represent the dependencies between packages. If there are 2 or more 2 packages, the dependency graph between them is looped, and we say that there is a circular dependency between the packages.
That is, their dependency structure creates a circular, closed shape based on the direction of the arrow.

Figure 2: Loop dependency of a package

A dependent b,b relies on c,c dependency A, which forms a cyclic dependency.

The non-cyclic dependency principle of packages

The package is a more appropriate release granularity, and when the code in the package (class, module, etc.) is modified and a new version is released, we need to publish the package along with the other packages it relies on. After publishing, it is also necessary to verify that the system works correctly under the newly released version.

If there is a cyclic dependency between multiple packages, such as 2,a dependent b,b dependency C,c A, we have modified B and need to publish a new version of B, because B relies on C, so it should be published with C, but C also depends on a, so it should be included in the release version.

That is, in a dependency structure, all the packages that appear within the ring have to be published together. They form a high-coupling, when the size of the project is large to a certain extent, the number of packages becomes a long time, the relationship between the package and the package become complex, the various tests will become very difficult, often due to an unrelated package errors in the test can not continue. The release also becomes complex, requiring all packages to be released together, undoubtedly increasing the difficulty of verification after release.

The breaking method of cyclic dependence

If the dependency of a package forms a ring structure, how do you break this cycle dependency?

There are 2 ways to break this circular dependency: the first is to create a new package, and the second is to use the dip (dependency inversion principle) and the ISP (interface separation principle) design principles.

Method One: Create a new package

For example, the dependency structure of Figure 2:

Figure 2: Loop dependency of a package

Package C to rely on package A, must have a a,c common use of the class, the common classes are extracted to put in a new package d. In this way, C dependency a becomes C dependent D and a relies on D, thus breaking the cyclic dependency.

In this way, the dependency of the package is changed from A->b->c->a to:

A->b->c->d

A->d

Method Two: Dip and ISP design principles

The ISP (interface separation principle) can eliminate the interface used by the United States. DIP (Dependency inversion principle) introduces an abstraction layer between calls to a class.

, package a relies on package B (because Class U in package a uses class X in package B), and in turn, Package B relies on package a (because Class Y in package B uses Class V in package a)

A cyclic dependency is formed between package A and package B.

We use the dip design principle to abstract an interface ivfory to V and place the interface in the B package.

This translates the call of Y to V into:

V Inherit ivfory

Y call Ivfory

In this way, the classes in package B do not depend on any class in package a.

Summary

The non-cyclic dependency principle (ADP) solves the problem of coupling between packages. You cannot have circular dependencies when designing package structures.

Resources

Granularity by Robert C. Martin.

Principles and Patterns by Robert c. Martin.

The principle of stable abstract equivalence

Objective

Robert C. Martin has summarized the principles that should be followed in object-oriented design (OOD), which are known as "Principles of OOD", and related articles on "Principles of OOD" can be obtained from Object mentor.

This paper introduces the Stable abstractions Principle (SAP): Stable abstract equivalence principle.

Profile

Packages that is maximally stable should be maximally abstract. Instable packages should be concrete. The abstraction of a package should is in proportion to its stability.

The most stable package should be the most abstract package. The unstable package should be a specific package. The degree of abstraction of a package is proportional to its stability.

To another argument is:

Stable packages should be abstract packages.

A stable package should be an abstract package.

The stable abstract equivalence principle of package

We talked about package stability in the Stable Dependencies Principle (SDP)-oo Design stability dependency principle: packages that are not easily changed should have better stability.

The higher the abstraction of a package, the greater its stability. Conversely, it is less stable. A stable package must be abstract, and conversely, an unstable package must be specific.

The composition of the stable package

Abstract classes or interfaces inherit extended behavior through subclasses, which means that abstract classes or interfaces are more stable than their subclasses. In short, in order to form a stable package, the ratio of abstract classes or interfaces in the package should be increased, and their subclasses can be placed in another unstable package, which relies on the stable dependency principle (SDP).

The ideal architecture should be:

An unstable (easily changing) package in the upper layer

-they are specific to the package implementation

A stable (not easily changed) package is on the lower level

-Not easy to change, but easy to expand

-Interface is more stable in intrinsic characteristics than implementation (specific running code)

Figure 1: An ideal architecture that follows the stable dependency principle (SDP)

Summary

The stable abstract Equivalence principle (SAP) solves the problem of coupling between packages. When designing a package structure, a stable package should be abstract (composed of abstract classes or interfaces), and unstable packages should be concrete (consisting of specific implementation classes).

Resources

Principles and Patterns by Robert c. Martin.

Principles and Patterns

The principle of stable dependence

The dependencies between packages in a design should is in the direction of the stability. A package should only depend upon packages that's more stable the It is.

The dependencies between packages in a design should be in a stable direction. A package should only depend on those packages that are more stable than themselves.

Objective

Robert C. Martin has summarized the principles that should be followed in object-oriented design (OOD), which are known as "Principles of OOD", and related articles on "Principles of OOD" can be obtained from Object mentor.

This article describes the Stable Dependencies Principle (SDP): The principle of stable reliance, or the principle of stability dependence.

Profile

The dependencies between packages in a design should is in the direction of the stability. A package should only depend upon packages that's more stable the It is.

The dependencies between packages in a design should be in a stable direction. A package should only depend on those packages that are more stable than themselves.

To another argument is:

Depend in the direction of stability.

To rely on in a stable direction.

Dependency of the package

If a class in package a refers to a class in package B, we call package a dependent on package B.

"Dependent" in the specific programming language, if a depends on the b,c/c++ language in a package of files/classes with the # include File/class in the B package, the Java language is a class in a package through the import statement into the class in package B.

Figure 1 (Package a dependency package B)

The dashed line represents a dependency, the arrow indicates the direction of the dependency, and the side of the arrow is the dependent package.

The principle of stable dependency of packages

Packages should rely on more stable packages than themselves. Because if you rely on an unstable package, then when this unstable package changes, its own stable package will have to change and become unstable.

The so-called stability, in real life refers to an object with a solid property that makes it difficult to change. Applied to software concepts, we believe that a software is stable because it is difficult to change, or more precisely, that it does not need to change. A well-designed software that can handle changes without modification is certainly stable, but in fact, often a software needs to respond to a pre-predicted user needs and have to change, when this change occurs, you can control the changes in the smallest range, and stable work (including the software itself and other software entities that depend on it), we would also consider the software to be relatively stable.

How to make a software stable enough? An exact method is to let a lot of other software packages depend on it. A package that is dependent on many other packages is very stable, because the packages that are being relied on in order to coordinate other packages must do a lot of work to correspond to various changes (burden of responsibility).

Figure 1: Stable package X

We believe that X is stable because:

-X is dependent on many other packages. Equivalent to the responsibility of the bear.

-X does not depend on other packages, it is independent.

Instead, a very unstable package y is listed below,

Figure 2: Unstable package y

We think that Y is unstable because:

-Y is not dependent on the other packages. is not the responsibility of the bear.

-Y relies on a lot of other packages.

The principle of judging the stability of package

The stability factor of a package can be judged by the following method:

Ca:afferent coupling. Centripetal coupling. The number of external packages (classes) that depend on the package (the contained classes) (i.e. incoming dependencies).

Ce:efferent coupling. Centrifugal coupling. The number of external packages that are dependent on the package (i.e. outgoing dependencies).

I:instability. Instability. i=ce/(CE+CA). Its value is between [0,1].

1,x ce=0, so instability i=0, it is stable. Instead, 2,y's ce=3,ca=0, so it's unstable i=1, it's unstable.

SDP requires that a package's instability I be greater than the instability of the package it relies on. "Depend upon packages whose I metric is lower than yours."

In other words, in the direction of dependence, the instability of the package should gradually decrease and the stability should be gradually increased.

Summary

The stable dependency principle (SDP) solves the problem of coupling between packages. When designing package structures, packages should only rely on packages that are more stable than themselves.

Resources

Granularity by Robert C. Martin.

Principles and Patterns by Robert c. Martin.

The principle of common closure

Objective

Robert C. Martin has summarized the principles that should be followed in object-oriented design (OOD), which are known as "Principles of OOD", and related articles on "Principles of OOD" can be obtained from Object mentor.

This paper introduces the Common Closure Principle (CCP): The principle of common closure.

Profile

The classes in a package should is closed together against the same kinds of changes. A change to that affects a package affects all the classes in the so package.

All classes in a package should be closed for changes of the same type. A change affects a package, which affects all classes in the package.

A more brief statement is:

Classes that change together, belong together.

Classes that are modified together should be grouped together (in the same package).

If you have to modify the code in the application, we want all of the changes to occur in one package (modify close) instead of being spread over many packages.

The CCP principle is to combine all classes that need to be modified for the same reason in a package. If 2 classes are physically or conceptually interconnected, they usually change together, and they should belong to the same package.

CCP and open-closed principle (Ocp:open Closed Principle) has a deep relationship, CCP's "Close" (closure) is the OCP advocated: classes should be Closed for modification but O Pen for extension. Class should be closed for modification and open to extensions. But we know that 100% of the "off" is unrealistic, and we can only try to keep the most predictable changes off when we design the system.

The CCP extends the "off" concept of the OCP, limiting the scope of the changes needed to a minimum range of packages for any reason that needs to be modified.

The CCP principle helps us decide which classes should be placed in the same package.

Summary

The common closure principle (CCP) provides us with a principle of package design from the perspective of software functions: When designing packages, the classes that are tightly related to each other should be in the same package.

Resources

Granularity by Robert C. Martin.

Principles and Patterns by Robert c. Martin.

All Reuse principle

Objective

Robert C. Martin has summarized the principles that should be followed in object-oriented design (OOD), which are known as "Principles of OOD", and related articles on "Principles of OOD" can be obtained from Object mentor.

This article describes the Common reuse Principle (CRP): The All-reuse principle.

Profile

The classes in a package is reused together. If you reuse one of the classes in a package, you reuse them all.

All classes of the package are reused together. If you reuse one of these classes, reuse all.

To another easy-to-understand statement:

Classes that aren ' t reused together should not being grouped together

Classes that are not reused together should not be grouped together.

The CRP principle helps us decide which classes should be placed in the same package.

Relying on a package is dependent on everything that the package contains. When a package has changed and a new version is released, all users who use the package must verify their work in the new package environment, even if the part they are using has not changed.

Because if the package contains classes that are not used, the user will have to upgrade the package and re-test the original functionality even if the user does not care if the class has changed.

We introduce a design principle for classes in the interface segregation Principle (ISP)-Oo Design Interface separation principle/sysdesign/doc/20071205214949530.html article:

Clients should not being forced to depend upon interfaces the they do not use. You can't force users to rely on interfaces that they don't have.

Applying this concept to a wider range of packages is the basic concept of CRP: Do not combine classes that are not used by users into packages.

CRP, like Rep, is designed from a user-friendly point of view to design packages that are reused by their beneficiaries, while CCP benefits the system's maintainers. CCP makes the package as large as possible (CCP principle joins function-related classes), and CRP makes the packet as small as possible (the CRP principle rejects unused classes). They have different starting points, but they do not conflict with each other.

CRP guarantees a high level of polymerization within the package.

Summary

The All-reuse principle (CRP) regulates the principle of package design from the user's point of view: When designing packages, classes that are not closely related to each other should not be placed in the same package.

Resources

Granularity by Robert C. Martin.

Principles and Patterns by Robert c. Martin.

(fine) Subcontracting principles/Package design principles/components (package) design principles