Shulou(Shulou.com)06/02 Report--

This article mainly introduces the relevant knowledge of the measures to improve the reusability of Java code, the content is detailed and easy to understand, the operation is simple and fast, and has a certain reference value. I believe you will gain something after reading this article to improve the reusability of Java code. Let's take a look at it.

Measure 1: rewrite the instance method of the class

Code reuse through class inheritance is not an accurate code reuse technology, so it is not the most ideal code reuse mechanism. In other words, we cannot reuse a single method in the class without inheriting all the methods and data members of the entire class. Inheritance always brings extra methods and data members, which always complicate the code to reuse a method in 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 the subclass; when modifying any class of the parent class or any subclass, it is difficult to remember which method is overridden by the subclass and which method is not overridden by the subclass; finally, it is sometimes not obvious whether the overriding method in the subclass calls the corresponding method in the parent class.

Any method, as long as it performs a single concept task, should be the preferred reusable code in itself. In order to reuse this code, we must return to the process-oriented programming model and move the instance methods of the class out of the global process. In order to improve the reusability of this process, procedure code should be written like a static tool method: it can only use its own input parameters, can only call other global procedures, and cannot use any non-local variables. This restriction on external dependencies simplifies the application of the process, so that the process can be easily used anywhere. Of course, because this organization always makes the code clearer, even code that does not consider reusability can also benefit.

In Java, a method cannot exist separately from a class. To do this, we can organize related processes into separate classes and define these processes as common 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) {...}

}

From the name of the class pPolygon, we can see that the process encapsulated by this class is mainly related to objects of type Polygon. The p before the name indicates that the sole purpose of the class is to organize common static processes. In Java, it is non-standard for a class to start with a lowercase letter, but a class like pPloygon does not actually provide the functionality of a normal Java class. In other words, it does not represent a class of objects, it is just a mechanism by which the Java language organizes code.

In the above example, the end effect of changing the code is that the client code that applies the Polygon functionality no longer has to inherit from Polygon. The functionality of the Polygon class is now provided by the pPolygon class on a process-by-process basis. The client code only uses the code it needs, and it doesn't care about the functionality in the Polygon class that it doesn't need. But it does not mean that the role of classes has been weakened in this new type of procedural programming. On the contrary, classes play an indispensable role in organizing and encapsulating object data members, and as described next in this article, the ability of classes to achieve polymorphism through multiple interfaces itself brings excellent code reuse support. However, because encapsulating code functions with an example method is not the preferred means of code reuse, it is not ideal to achieve code reuse and polymorphism support through class inheritance.

Measure 2: change the parameter type to the interface

As Allen Holub pointed out in "Build User Interfaces for object-Oriented Systems", the real point of code reuse in object-oriented programming is to take advantage of polymorphism through interface parameter types, rather than through class inheritance:

". We achieve code reuse by programming interfaces rather than classes. if all the parameters of a method are references to known interfaces, then the method can manipulate objects whose classes don't even exist when we write code for the method. technically, it is the method that is reusable, not the object passed to the method."

According to Holub's view on the results of measure 1, when a piece of code can be written as an independent global process, we can further improve its reusability as long as the parameters of all its class forms are changed to interface forms. After this change, the parameters of the procedure can be the objects of all classes that implement the interface, not just the objects created by the original class. As a result, the process will be able to manipulate a large number of object types that may exist.

For example, suppose you have a global static method:

Static public boolean contains (Rectangle rect, int x, int y) {...}

This method is used to check whether the specified point is contained in the rectangle. In this example, the type of the rect parameter can be changed from the Rectangle class to the interface type, as follows:

Static public boolean contains (Rectangular rect, int x, int y) {...}

The definition of Rectangular interface is:

Public interface Rectangular {Rectangle getBounds ();}

Objects created by all classes that can be described as rectangles (that is, classes that implement the Rectangular interface) can now be used as rect parameters provided to pRectangular.contains (). By relaxing the restrictions on parameter types, we make the method more reusable.

However, for the above example, the getBounds method of the Rectangular interface returns Rectangle, and you may wonder if it's really worth it. In other words, if we know that the object passing in the procedure will return a Rectangle when called, why not just pass in Rectangle instead of the interface type? The most important reason for not doing so has to do with collections. Let's assume that there is such a way:

Static public boolean areAnyOverlapping (Collection rects) {...}

This method is used to check whether any rectangular objects in a given collection overlap. Inside this method, when we use a loop to access each object in the collection in turn, how can we access the rectangular area of the object if we can't make the object cast an interface type such as Rectangular? The only option is to make the object cast its unique class form (we know that it has a method that returns a rectangle), which means that the method must know in advance the type of object it operates on, thus limiting the reuse of the method to those object types. And this is the problem that the previous measure tries to avoid first!

Measure 3: select the simplest parameter interface type

When implementing the second measure, which interface type should be chosen to replace the given class form? The answer is which interface fully meets the requirements of the process for parameters, while having the least amount of redundant code and data. The simpler the interface required to describe a parameter object, the greater the chance that other classes will implement that interface-- and thus more classes whose objects can be used as parameters. You can easily see this from the following example:

Static public boolean areOverlapping (Window window1, Window window2) {...}

This method is used to check whether two windows (assumed to be rectangular windows) overlap. If this method requires only the rectangular coordinates of the two windows from the parameters, it is a better choice to simplify the two parameters accordingly:

Static public boolean areOverlapping (Rectangular rect1, Rectangular rect2) {...}

The above code assumes that the Window type implements the Rectangular interface. After the modification, we can reuse the function of this method for any rectangular object.

Sometimes there may be situations where the interface that describes the parameter requirements has too many methods. At this point, we should define a new public interface in the global namespace for reuse by other code facing the same problem.

When we need to use parameters like function pointers in C, creating a unique interface to describe parameter requirements is the best choice. For example, suppose you have the following process:

Static public void sort (List list, SortComparison comp) {...}

This method uses the comparison object comp provided in the parameter to sort the list list by comparing the objects in the given list list. The only requirement of sort for a comp object is to call a method to compare. Therefore, SortComparison should be an interface with only one method:

Public interface SortComparison {

Boolean comesBefore (Object a, Object b)

}

The sole purpose of the SortComparison interface is to provide sort with a hook for the functionality it needs, so the SortComparison interface cannot be reused elsewhere.

This is the end of the article on "what are the measures to improve the reusability of Java code?" Thank you for reading! I believe you all have a certain understanding of the knowledge of "what are the measures to improve the reusability of Java code". If you want to learn more, you are welcome to follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.