Three measures to improve Java code reusability

Action One: the instance method of the rewrite class

Implementing code reuse through class inheritance is not an accurate code reuse technique, so it is not the ideal code reuse mechanism. In other words, if you do not inherit all the methods and data members of the entire class, we cannot reuse a single method within that class. Inheritance always brings some redundant methods and data members, and they always complicate the code for reusing a method within a class. In addition, the dependency of the derived class on the parent class further complicates the code: changes to the parent class may affect subclasses, or any one of the classes in the parent class or subclass, it is difficult to remember which method covers the quilt and which method is not covered by the quilt; It is sometimes not obvious whether the override method in a subclass will invoke a corresponding method in the parent class.

Any method, as long as it performs a task of a single concept, should, in itself, be the preferred reusable code. In order to reuse this code, we must revert to the process-oriented programming model and move the instance method of the class into a global process. To improve the reusability of this process, the process code should be written like a static tool method: it can only use its own input parameters, only other global processes can be invoked, and no nonlocal variables can be used. This restriction on external dependencies simplifies the application of the process and makes it easy to use anywhere. Of course, because this kind of organization always makes code have a clearer structure, even code that does not consider reuse can benefit from it.

In Java, methods cannot exist separately from classes. To do this, we can organize the related processes into separate classes and define these processes as public static methods.

For example, for the following class:

class Polygon {
.
.
public int getPerimeter() {...}
public boolean isConvex() {...}
public boolean containsPoint(Point p) {...}
.
.
}

We can rewrite it as:

class Polygon {
.
.
public int getPerimeter() {return pPolygon.computePerimeter(this);}
public boolean isConvex() {return pPolygon.isConvex(this);}
public boolean containsPoint(Point p) {return pPolygon.containsPoint(this, p);}
.
}

Among them, Ppolygon is:

class pPolygon {
static public int computePerimeter(Polygon polygon) {...}
static public boolean isConvex(Polygon polygon) {...}
static public boolean
containsPoint(Polygon polygon, Point p) {...}
}

As you can see from the name Ppolygon of the class, the process encapsulated by the class is primarily related to objects of type polygon. The P in front of the first name indicates that the only purpose of the class is to organize public static processes. In Java, a class whose first name starts with a lowercase letter is a non-standard practice, but classes like Pploygon do not in fact provide the functionality of ordinary Java classes. In other words, it does not represent a class of objects, it is just a mechanism of the Java Language organization code.

In the example above, the final effect of the change code is that the client code that applies the polygon feature does not have to inherit from polygon. The functionality of the Polygon class is now provided by the Ppolygon class in process units. The client code uses only the code that it needs and does not need to care about features that are not needed in the polygon class. But it does not mean that the role of the class is weakened in this new process of programming. On the contrary, classes play an integral role in organizing and encapsulating object data members, and as the following article describes, the ability of classes to implement polymorphism through multiple interfaces also brings superior code reuse support. However, because using instance methods to encapsulate code functionality is not the preferred method of code reuse, it is not ideal to achieve code reuse and polymorphism support through class inheritance.