Software Engineering: Designing Class base Components | Basic Design Principles applicable to component level design | The Open-Closed Principle (OCP) | The Liskov Substitution Principle (LSP) | Dependency Inversion Principle (DIP) | The Interface Segregation Principle (ISP) | The Release Reuse Equivalency Principle (REP) | The Common Closure Principle (CCP)

Designing Class base Components

When an object-oriented software engineering approach is chosen, component-level design focuses on the elaboration of problem domain specific classes
The definition and refinement of infrastructure classes contained in the requirements model. The detailed description of the attributes, operations, and interfaces used by these classes is the design detail.

Introduction : Four basic design principles are applicable to component-level design and have been widely adopted when object-oriented software engineering is applied.
The Open-Closed Principle (OCP). “A module [component] should be open for extension but closed for modification.
The Liskov Substitution Principle (LSP). “Subclasses should be substitutable for their base classes.
Dependency Inversion Principle (DIP). “Depend on abstractions. Do not depend on concretions.”
The Interface Segregation (Separation) Principle (ISP). “Many client-specific interfaces are better than one general purpose interface.
The Release Reuse Equivalency Principle (REP). “The granule of reuse is the granule of release.”
The Common Closure Principle (CCP). “Classes that change together belong together.”
The Common Reuse Principle (CRP). “Classes that aren’t reused together should not be grouped together.”

Design should specify the component in a way that allows it to be extended (within the functional domain that it addresses) without the need to make internal (code or logic-level) modifications to the component itself.
To accomplish this, you create abstractions that serve as a buffer between the functionality that is likely to be extended and the design class itself.
For example : assume that the SafeHome security function makes use of a Detector class that must check the status of each type of security sensor. It is likely that as time passes, the number and types of security sensors will grow.
If internal processing logic is implemented as a sequence of if-then-else constructs, each addressing a different sensor type, the addition of a new sensor type will require additional internal processing logic (still another if-then-else). This is a violation of OCP.
One way to accomplish OCP for the Detector class is illustrated in Figure 1. The sensor interface presents a consistent view of sensors to the detector component. If a new type of sensor is added no change is required for the Detector class (component). The OCP is preserved

Subclasses should be substitutable for their base classes”.
It suggests that, a component that uses a base class should continue to function properly if a class derived from the base class is passed to the component instead.
LSP demands that any class derived from a base class must honor any implied contract between the base class and the components that use it
In the context of this discussion, a “contract” is a precondition that must be true before the component uses a base class and a postcondition that should be true after the component uses a base class.
When you create derived classes, be sure they conform to the pre and postconditions.

Depend on abstractions. Do not depend on concretions”.
Here abstractions are the place where a design can be extended without great complication.
The more a component depends on other concrete components (rather than on abstractions such as an interface), the more difficult it will be to extend.

Many client-specific interfaces are better than one general purpose interface”.
There are many instances in which multiple client components use the operations provided by a server class.
ISP suggests that, you should create a specialized interface to serve each major category of clients. Only those operations that are relevant to a particular category of clients should be specified in the interface for that client.
If multiple clients require the same operations, it should be specified in each of the specialized interfaces.

“The granule of reuse is the granule of release”.
When classes or components are designed for reuse, there is an implicit contract that is established between the developer of the reusable entity and the people who will use it.
The developer commits to establish a release control system that supports and maintains older versions of the entity while the users slowly upgrade to the most current version.
Rather than addressing each class individually, it is often advisable to group reusable classes into packages that can be managed and controlled as newer versions evolve

“Classes that change together belong together.”
Classes should be packaged cohesively.
That is, when classes are packaged as part of a design, they should address the same functional or behavioral area.
When some characteristic of that area must change, it is likely that only those classes within the package will require modification.