We usually write most of our code using only a few features of the Java language, and each Stream we instantiate and each @AutoWired annotation that prefixes the instance is sufficient to accomplish most of our goals. Sometimes, however, we must turn to a part of the language that is rarely used: a hidden part of the language that is often used for a specific purpose.
In this article, we’ll explore four techniques to help improve development simplicity and readability. Not all of these techniques are appropriate for every situation, or for most of them. For example, there may be only a few centralized methods suitable for covariant return types or only a few generic classes suitable for using the pattern of cross-generic types, while other methods may improve the readability and clarity of most code base intents. In any case, it is important not only to know these techniques, but also to know when to apply them.
1. Covariant return types
Even the most fascinating Java manuals contain descriptions of inheritance, interfaces, abstract classes, and method coverage, but rarely explore the more complex possibilities of covering methods. For example, the following code snippet will come as no surprise to even new Java developers:
public interface Animal {
public String makeNoise();
}
public class Dog implements Animal {
@Override
public String makeNoise() {
return “Woof”;
}
}
public class Cat implements Animal {
@Override
public String makeNoise() {
return “Meow”;
}
}
This is the basic concept of polymorphism: an object’s methods can be called according to its interface (Animal::makeNoise) but the actual behavior of that method call depends on the implementation type (Dog::makeNoise). For example, the output of the following method will change depending on whether a Dog or Cat object is passed to the method:
public class Talker {
public static void talk(Animal animal) {
System.out.println(animal.makeNoise());
}
}
Talker.talk(new Dog()); // Output: Woof
Talker.talk(new Cat()); // Output: Meow
While this is a common technique in many Java applications, there is another action you might take when overriding a method: change the return type. Although this may be an unlimited way to override methods, there are strict restrictions on the return types of override methods. According to the Java 8 SE language specification (page 248) :
If one method declaration d 1 (containing return type R 1) overwrites or hides the declaration of another method D 2 (containing return type R 2), then D 1 must be a return type substitute, or a compile-time error will occur.
Where return-type-substitutable (ibid., p. 240) was defined as:
-
If R1 is invalid, R2 is invalid
-
If R1 is primitive, R2 is the same as R1
-
If R1 is a reference type, one of the following conditions is met:
A. R1 applies to parameters of type D2, which is a subtype of R2
B. R1 can be converted to a subtype of R2 by an unchecked conversion
C. do not have the same signature as the d2, d1 and R1 = | | R2
Arguably, the most interesting examples are Rules 3.a. And 3.b. : When overriding a method, subtypes of return types can be declared as override return types, for example:
-
public interface CustomCloneable {
-
public Object customClone();
-
}
-
public class Vehicle implements CustomCloneable {
-
private final String model;
-
public Vehicle(String model) {
-
this.model = model;
-
}
-
@Override
-
public Vehicle customClone() {
-
return new Vehicle(this.model);
-
}
-
public String getModel() {
-
return this.model;
-
}
-
}
-
Vehicle originalVehicle = new Vehicle(“Corvette”);
-
Vehicle clonedVehicle = originalVehicle.customClone();
-
System.out.println(clonedVehicle.getModel());
Although the original return type of Clone () is Object, we can call getModel() in clonedVehicle (without explicit conversion) because we have rewritten the return type of Vehicle :: Clone to Vehicle. This eliminates the need for garble, and we know that the return type we are looking for is Vehicle, even though it is declared Object (equivalent to secure delivery based on prior information, but not strictly safe) :
- Vehicle clonedVehicle = (Vehicle) originalVehicle.customClone();
Note that we can still declare the Vehicle type as Object, and the return type will revert to the original type of Object:
-
Object clonedVehicle = originalVehicle.customClone();
-
System.out.println(clonedVehicle.getModel()); // ERROR: getModel not a method of Object
Note that return types cannot be overloaded for generic parameters, but they can be overloaded for generic classes. For example, if a base class or interface method returns a List, the return type of a subclass may override ArrayList, but may not override List.
2. Cross generic types
Creating generic classes is a good way to create a set of classes that interact with composite objects. For example, a List only stores and retrieves objects of type T without knowing the nature of the elements it contains, and in some cases we want to restrict our generic type parameter (T) to having specific characteristics. For example, the following interface:
-
public interface Writer {
-
public void write();
-
}
We might want to create specific Writers groups, as shown in the Composite Patterns below:
-
public class WriterComposite implements Writer {
-
private final List writers;
-
public WriterComposite(List writers) {
-
this.writers = writer;
-
}
-
@Override
-
public void write() {
-
for (Writer writer: this.writers) {
-
writer.write();
-
}
-
}
-
}
We can now traverse the Writers tree and do not know whether the specific Writer we encounter is a standalongWriter or a combination of Writers. What if we also want our composition to be a combination of reader and writer? For example, if we have the following interface:
-
public interface Reader {
-
public void read();
-
}
How do we change our WriterComposite to ReaderWriterComposite? There is a technique for creating a new interface, ReaderWriter, to fuse the Reader and Writer interfaces:
- public interface ReaderWriter implements Reader, Writer {}
We can then modify the existing WriterComposite to the following:
-
public class ReaderWriterComposite implements ReaderWriter {
-
private final List readerWriters;
-
public WriterComposite(List readerWriters) {
-
this.readerWriters = readerWriters;
-
}
-
@Override
-
public void write() {
-
for (Writer writer: this.readerWriters) {
-
writer.write();
-
}
-
}
-
@Override
-
public void read() {
-
for (Reader reader: this.readerWriters) {
-
reader.read();
-
}
-
}
-
}
While this accomplishes our goal, we create bloat in our code: we create an interface whose sole purpose is to merge two existing interfaces together. As more and more interfaces emerge, we will see an explosion of bloated combinations. For example, if we created a new Modifier interface, we would now need the createReaderModifier, WriterModifier, and ReaderWriter interfaces. Note that these interfaces do not add any functionality: they simply merge existing interfaces.
To eliminate this bloat, we need to be able to specify that our ReaderWriterComposite accepts generic type parameters only if they are both readers and writers. Crossing generic types allows us to do this. To specify generic type parameters, both reader and Writer interfaces must be deployed. We use the & operator between generic type constraints:
-
public class ReaderWriterComposite implements Reader, Writer {
-
private final List readerWriters;
-
public WriterComposite(List readerWriters) {
-
this.readerWriters = readerWriters;
-
}
-
@Override
-
public void write() {
-
for (Writer writer: this.readerWriters) {
-
writer.write();
-
}
-
}
-
@Override
-
public void read() {
-
for (Reader reader: this.readerWriters) {
-
reader.read();
-
}
-
}
-
}
Without the expanded inheritance tree, we can now constrain common type parameters to deploy multiple interfaces. Note that the same restriction can specify whether one of the interfaces is an abstract class or a concrete class. For example, if we change the Writer interface to an abstract class, something like this:
-
public abstract class Writer {
-
public abstract void write();
-
}
We can still restrict our generic type arguments to Reader and Writer, but Writer (since it is an abstract class rather than an interface) must be specified first. (Also note that our ReaderWriterComposite now extends the Writer abstract class and deployable the Reader interface. Rather than implementing both.)
-
public class ReaderWriterComposite extends Writer implements Reader {
-
// Same class body as before
-
}
Equally important, this cross generic type can be used with more than two interfaces (or one abstract class and multiple interfaces). For example, if we want our composition to also include Modifierinterface, we can write our class definition as follows:
-
public class ReaderWriterComposite implements Reader, Writer, Modifier {
-
private final List things;
-
public ReaderWriterComposite(List things) {
-
this.things = things;
-
}
-
@Override
-
public void write() {
-
for (Writer writer: this.things) {
-
writer.write();
-
}
-
}
-
@Override
-
public void read() {
-
for (Reader reader: this.things) {
-
reader.read();
-
}
-
}
-
@Override
-
public void modify() {
-
for (Modifier modifier: this.things) {
-
modifier.modify();
-
}
-
}
-
}
While the above can be done, this may be a sign of code smell (The Reader, Writer, and Modifier objects may be more specific, such as File)
For more information about crossed generic types, see the Java 8 language specification.
3. Automatically close classes
Creating a resource class is a common practice, but maintaining the integrity of that resource can be challenging, especially when exception handling is involved. For example, suppose we create a Resource class, Resource, and want to perform operations on that Resource, which might raise an exception (instantiation might also raise an exception) :
-
public class Resource {
-
public Resource() throws Exception {
-
System.out.println(“Created resource”);
-
}
-
public void someAction() throws Exception {
-
System.out.println(“Performed some action”);
-
}
-
public void close() {
-
System.out.println(“Closed resource”);
-
}
-
}
In either case (raising an exception or not), we want to close our resources to ensure that no resources leak. The normal procedure is to close our close() method ina finally block, ensuring that no matter what happens, our resource is closed before the enclosing execution scope completes:
-
Resource resource = null;
-
try {
-
resource = new Resource();
-
resource.someAction();
-
}
-
catch (Exception e) {
-
System.out.println(“Exception caught”);
-
}
-
finally {
-
resource.close();
-
}
Through a simple inspection, we found that a lot of boilerplate code was detracting from the readability of the execution of the Resource object someAction(). To remedy this, Java 7 introduced the try-with-Resources declaration, where resources can be created in the try declaration and closed automatically before leaving the scope of the try execution. In order for a class to use try-with-resources, the auto-close interface must be deployed:
-
public class Resource implements AutoCloseable {
-
public Resource() throws Exception {
-
System.out.println(“Created resource”);
-
}
-
public void someAction() throws Exception {
-
System.out.println(“Performed some action”);
-
}
-
@Override
-
public void close() {
-
System.out.println(“Closed resource”);
-
}
-
}
Our Resource class now has an autoclose interface, and we can clean up the code to ensure that the Resource is closed before it leaves the scope of the try execution.
-
try (Resource resource = new Resource()) {
-
resource.someAction();
-
}
-
catch (Exception e) {
-
System.out.println(“Exception caught”);
-
}
Compared to non-try-with-Resource techniques, this process is less messy and retains the same security (the resource remains closed until the try execution scope is complete). If we execute the try-with-resource above, we get the following output:
-
Created resource
-
Performed some action
-
Closed resource
To demonstrate the security of this try-with-resource technique, we can change someAction() to throw an Exception:
-
public class Resource implements AutoCloseable {
-
public Resource() throws Exception {
-
System.out.println(“Created resource”);
-
}
-
public void someAction() throws Exception {
-
System.out.println(“Performed some action”);
-
throw new Exception();
-
}
-
@Override
-
public void close() {
-
System.out.println(“Closed resource”);
-
}
-
}
If we re-run the try-with-resources declaration, we get the following output:
-
Created resource
-
Performed some action
-
Closed resource
-
Exception caught
Notice that even if an Exception is thrown when executing the someAction() method, our resource is still closed and Exception is caught. This ensures that our resources are guaranteed to be closed before leaving the try execution scope. It is also important to note that the Resource deployable interface Closeable can still use the try-with-resources declaration. The difference between deploying an automatically closed interface and a closeable interface is the type of Exception thrown from the close() method signature: Exceptionand IOException. In our example, we simply change the signature of the close() method without raising an exception.
4. Final classes and methods
In almost all cases, the classes we create can be extended by another developer and customized to their needs (we can extend our own classes), even if we don’t want to extend ours. While this is sufficient in most cases, sometimes we don’t want methods to be overridden, or our classes to be extended. For example, if we create the File class to encapsulate the reads and writes of files in the File system, we might not want any subclasses to override our read(Int Bytes) and Write (String Data) methods (which could corrupt the File system if the bare bodies of those methods were changed). In this case, we mark the non-extensible method as final:
-
public class File {
-
public final String read(int bytes) {
-
// Execute the read on the file system
-
return “Some read data”;
-
}
-
public final void write(String data) {
-
// Execute the write to the file system
-
}
-
}
Now, if another class wishes to override a read or write method, a compilation error is raised: the final method cannot be overwritten from File. Not only do we record that our methods should not be overridden, but the compiler also ensures that this intent is not executed at compile time.
When extending this idea to an entire class, there may be times when we don’t want our class to be extended. This not only makes every method of the class unexecutable, but also makes it impossible to create subtypes of the class. For example, if we were creating a security framework to use a key generator, we probably wouldn’t want any external developers to extend our key generator and override the generation algorithm (custom features might affect the system) :
-
public final class KeyGenerator {
-
private final String seed;
-
public KeyGenerator(String seed) {
-
this.seed = seed;
-
}
-
public CryptographicKey generate() {
-
/ /… Do some cryptographic work to generate the key…
-
}
-
}
By making our KeyGenerator class the final class, the compiler ensures that no class extends our class and passes it to our framework as a valid cryptographic KeyGenerator. While simply marking the thegenerate() method as final may seem sufficient, this does not prevent developers from creating custom key generators and using them as valid generators. Because our system is security-oriented, we should trust the outside world as little as possible (a smart developer can change the generation algorithm by changing the functionality of other methods in the KeyGenerator class).
While this may seem like a public repudiation of the open/closed principle, there are good reasons for doing so. As you can see from our security example above, many times we can’t get external developers to do what they want with our application, and we have to make very careful decisions about integration. This concept is ubiquitous, for example C# defaults a class as final (it cannot be extended), and it must be specified as open by the developer. In addition, we should be very careful about which classes can be extended and which methods can be overridden.
conclusion
Although we wrote most of the code using only a small portion of Java’s capabilities, it was enough to solve most of the problems we encountered. Sometimes we need to dig deep into forgotten or unknown parts of the language to solve specific problems. Techniques such as covariant return types and cross-generic types can be used for one-off situations, while methods that automatically close resources and final methods and classes can be used to produce more readable and accurate code. You can combine these skills with everyday programming practices to help you write Better Java code. 1, want to learn JAVA this technology, interested in JAVA zero foundation, want to be engaged in JAVA work. 2. Those who have worked for 1-5 years and feel their skills are not good and want to improve their skills. 3. There is also want to exchange and study together. 5. No small plus group, thank you. Please forward this article with the original link, otherwise will be investigated legal responsibility