CRP (the common Reuse Principle, principle of full reuse)
All classes in a package should be reused together.
The classes in a package are 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 the classes, you can reuse all of them.
Another easy-to-understand statement:
Classes that aren't reused together shoshould not be grouped together
Classes that are not reused together should not be combined.
The CRP principle helps us decide which classes should be put in the same package.
Dependency on a package depends on everything contained in the package. When a package changes and a new version is released concurrently, all users using this package must verify their work in the new package environment, even if the portion used by them has not changed.
Because if the package contains unused classes, even if the user does not care whether the class is changed, the user still has to upgrade the package and re-test the original functions.
In the document/sysdesign/doc/20071205214949530.html of interface segregation principle (ISP)-OO design, we introduce a class-oriented design principle:
Clients shocould not be forced to depend upon interfaces that they do not use. users cannot be forced to rely on interfaces they do not use.
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 the package.
Like rep, CRP designs packages from the perspective of facilitating user reuse. retainers are their beneficiaries, while CCP benefits system maintainers. CCP makes the package as big as possible (CCP principles include function-related classes), CRP makes the package as small as possible (CRP principles Remove unused classes ). Their starting points are different, but they do not conflict with each other.
CRP ensures high cohesion within the package.