Rules for code reuse

Code reuse is one of the goals of OO that most programmers expect. Summing up my years of coding experience, in order to maximize the reuse of the code, should pay special attention to the following aspects.

Programming to Interfaces

"Interface Programming" is the first basic principle of object-oriented design (OOD). It means using interfaces and communicating with components of the same type, that is, for all components that perform the same function, you should abstract an interface that implements the interface. In Java, either an interface (interface), or an abstract class (abstract class), all components that do the same function implement the interface, or inherit from the abstract class. Our client code should only communicate with this interface, so that when we need to complete the task with other components, we just need to replace the implementation of the interface, and the rest of our code does not need to change!

When the existing components do not meet the requirements, we can create new components, implement the interface, or, directly to the existing components to expand, subclasses to complete the extension of the functionality.

Prioritize the use of object combinations rather than class inheritance

The second principle of object-oriented design is to prioritize the use of object combinations, rather than class inheritance. It is not that inheritance is unimportant, but that everyone who learns OOP knows that one of the basic attributes of OO is inheritance, that inheritance has been abused, and that object-mix techniques are often overlooked. The following analyses the advantages and disadvantages of inheritance and composition:

Class inheritance allows you to define the implementation of a class based on the implementation of other classes. This multiplexing by generating subclasses is often referred to as white box multiplexing (White-box reuse). The term "white box" is relative visibility: in inheritance, the inner details of the parent class are visible to the subclass.

An object combination is another type of reuse alternative to class inheritance. New and more complex features can be obtained by combining objects. Object combinations require objects to have well-defined interfaces. This reuse style is called black box multiplexing (Black-box reuse) because the internal details of the objects being grouped are not visible. Objects appear only in the form of "black box".

Inheritance and composition have their advantages and disadvantages. Class inheritance is statically defined at compile time and can be used directly, and class inheritance makes it easier to change the implementation of the parent class. But class inheritance has some drawbacks. First, because inheritance is defined at compile time, the implementation that inherits from the parent class cannot be changed at run time. Worse, the parent class usually defines at least part of the behavior of the subclass, and any changes to the parent class can affect the behavior of the subclass. If the inherited implementation is not appropriate to solve the new problem, the parent class must be overridden or replaced by a more appropriate class. This dependency limits flexibility and ultimately limits reusability.

Object combinations are dynamically defined at run time by obtaining references to other objects. Because the combination requires that the object has well-defined interfaces, also, objects can only be accessed through the interface, so we don't break the encapsulation; As long as the type is consistent, the runtime can substitute one object for the other, further, because the object's implementation is based on the interface, so there are fewer dependencies on the implementation.

Prioritizing the use of objects helps you keep each class encapsulated and focus on a single task. Such class and class inheritance hierarchies remain small and unlikely to grow into uncontrollable behemoths (which is the consequence of abusive inheritance). On the other hand, object-based design will have more objects (but fewer classes), and the system's behavior will depend on the relationships between objects rather than being defined in a class.

Note: Ideally, we don't have to create new components for reuse, we just need to use the object combination technology to get the functionality we need by assembling the existing components. This is rarely the case, however, because the available set of components is not rich. Using inherited reuse makes it easier to create new components than to assemble existing components. In this way, inheritance and object combinations are often used together. However, as mentioned earlier, you should never abuse inheritance without ignoring the object mix technology.

Related design Patterns are: Bridge, composite, decorator, Observer, strategy and so on.

The following example illustrates this rule, which is based on the premise that we need to output the same data structure in any format.

For the first example, we use an inheritance based framework to see that it is difficult to maintain and extend.

abstract class AbstractExampleDocument
{
　　 // skip some code ...
　　 public void output(Example structure)
　　　　 {
　　　　　　 if( null != structure )
　　　　　　　　 {
　　　　　　　　 this.format( structure );
　　　　　　　　 }
　　　　 }
　　 protected void format(Example structure);
}