{"id":43674,"date":"2015-09-18T21:44:50","date_gmt":"2015-09-18T18:44:50","guid":{"rendered":"http:\/\/www.javacodegeeks.com\/?p=43674"},"modified":"2023-12-06T12:05:52","modified_gmt":"2023-12-06T10:05:52","slug":"how-to-design-classes-and-interfaces","status":"publish","type":"post","link":"https:\/\/www.javacodegeeks.com\/2015\/09\/how-to-design-classes-and-interfaces.html","title":{"rendered":"How to design Classes and Interfaces"},"content":{"rendered":"

This article is part of our Academy Course titled Advanced Java<\/a>.<\/p>\n

This course is designed to help you make the most effective use of Java. It discusses advanced topics, including object creation, concurrency, serialization, reflection and many more. It will guide you through your journey to Java mastery! Check it out here<\/a>!<\/em><\/p>\n

\n

Table Of Contents<\/h4>\n
\n
1. Introduction<\/a><\/dt>\n
2. Interfaces<\/a><\/dt>\n
3. Marker Interfaces<\/a><\/dt>\n
4. Functional interfaces, default and static methods<\/a><\/dt>\n
5. Abstract classes<\/a><\/dt>\n
6. Immutable classes<\/a><\/dt>\n
7. Anonymous classes<\/a><\/dt>\n
8. Visibility<\/a><\/dt>\n
9. Inheritance<\/a><\/dt>\n
10. Multiple inheritance<\/a><\/dt>\n
11. Inheritance and composition<\/a><\/dt>\n
12. Encapsulation<\/a><\/dt>\n
13. Final classes and methods<\/a><\/dt>\n
14. What’s next<\/a><\/dt>\n
15. Download the Source Code<\/a><\/dt>\n<\/dl>\n<\/div>\n

<\/a>1. Introduction<\/h2>\n

Whatever programming language you are using (and Java is not an exception here), following good design principles is a key factor to write clean, understandable, testable code and deliver long-living, easy to maintain solutions. In this part of the tutorial we are going to discuss the foundational building blocks which the Java language provides and introduce a couple of design principles, aiming to help you to make better design decisions.<\/p>\n

More precisely, we are going to discuss interfaces<\/strong> and interfaces with default methods<\/strong> (new feature of Java 8), abstract<\/strong> and final<\/strong> classes, immutable classes, inheritance, composition<\/strong> and revisit a bit the visibility<\/strong> (or accessibility) rules we have briefly touched in part 1<\/strong> of the tutorial, How to create and destroy objects<\/a><\/strong>.<\/p>\n

<\/a>2. Interfaces<\/h2>\n

In object-oriented programming, the concept of interfaces forms the basics of contract-driven (or contract-based) development. In a nutshell, interfaces define the set of methods (contract) and every class which claims to support this particular interface must provide the implementation of those methods: a pretty simple, but powerful idea.<\/p>\n

Many programming languages do have interfaces in one form or another, but Java particularly provides language support for that. Let take a look on a simple interface definition in Java.<\/p>\n

\npackage com.javacodegeeks.advanced.design;\n\npublic interface SimpleInterface {\n    void performAction();\n} <\/pre>\n
In the code snippet above, the interface which we named SimpleInterface<\/code> declares just one method with name performAction<\/code>. The principal differences of interfaces in respect to classes is that interfaces outline what the contact is (declare methods), but do not provide their implementations.<\/p>\n
However, interfaces in Java can be more complicated than that: they can include nested interfaces, classes, enumerations, annotations (enumerations and annotations will be covered in details in part 5<\/strong> of the tutorial, How and when to use Enums and Annotations<\/strong>) and constants. For example:<\/p>\n
\npackage com.javacodegeeks.advanced.design;\n\npublic interface InterfaceWithDefinitions {\n    String CONSTANT = \"CONSTANT\";\n\n    enum InnerEnum {\n        E1, E2;\n    }\n\n    class InnerClass {\n    }\n\n    interface InnerInterface {\n        void performInnerAction();\n    }\n\n    void performAction();\n} <\/pre>\n
With this more complicated example, there are a couple of constraints which interfaces implicitly impose with respect to the nested constructs and method declarations, and Java compiler enforces that. First and foremost, even if it is not being said explicitly, every declaration in the interface is public<\/strong> (and can be only public<\/strong>, for more details about visibility and accessibility rules, please refer to section Visibility<\/a>). As such, the following method declarations are equivalent:<\/p>\n
\npublic void performAction();\nvoid performAction(); <\/pre>\n
Worth to mention that every single method in the interface is implicitly declared as abstract<\/strong> and even these method declarations are equivalent:<\/p>\n
\npublic abstract void performAction();\npublic void performAction();\nvoid performAction(); <\/pre>\n
As for the constant field declarations, additionally to being public<\/code>, they are implicitly static<\/code> and final<\/code> so the following declarations are also equivalent:<\/p>\n
\nString CONSTANT = \"CONSTANT\";\npublic static final String CONSTANT = \"CONSTANT\"; <\/pre>\n
And finally, the nested classes, interfaces or enumerations, additionally to being public<\/code>, are implicitly declared as  static<\/code>. For example, those class declarations are equivalent as well:<\/p>\n
\nclass InnerClass {\n}\n\nstatic class InnerClass {\n} <\/pre>\n
Which style you are going to choose is a personal preference, however knowledge of those simple qualities of interfaces could save you from unnecessary typing.<\/p>\n
<\/a>3. Marker Interfaces<\/h2>\n
Marker interfaces are a special kind of interfaces which have no methods or other nested constructs defined. We have already seen one example of the marker interface in part 2<\/strong> of the tutorial Using methods common to all objects<\/a><\/strong>, the interface Cloneable<\/code>. Here is how it is defined in the Java library:<\/p>\n
\npublic interface Cloneable {\n} <\/pre>\n
Marker interfaces are not contracts per se but somewhat useful technique to \u201cattach\u201d or \u201ctie\u201d some particular trait to the class. For example, with respect to Cloneable<\/code>, the class is marked as being available for cloning however the way it should or could be done is not a part of the interface. Another very well-known and widely used example of marker interface is Serializable<\/code>:<\/p>\n
\npublic interface Serializable {\n} <\/pre>\n
This interface marks the class as being available for serialization and deserialization, and again, it does not specify the way it could or should be done.<\/p>\n
The marker interfaces have their place in object-oriented design, although they do not satisfy the main purpose of interface to be a contract.<\/p>\n
<\/a>4. Functional interfaces, default and static methods<\/h2>\n
With the release of Java 8<\/a>, interfaces have obtained new very interesting capabilities: static methods, default methods and automatic conversion from lambdas (functional interfaces).<\/p>\n
In section Interfaces<\/a> we have emphasized on the fact that interfaces in Java can only declare methods but are not allowed to provide their implementations. With default methods it is not true anymore: an interface can mark a method with the default<\/code> keyword and provide the implementation for it. For example:<\/p>\n
\npackage com.javacodegeeks.advanced.design;\n\npublic interface InterfaceWithDefaultMethods {\n    void performAction();\n\n    default void performDefaulAction() {\n        \/\/ Implementation here\n    }\n} <\/pre>\n
Being an instance level, defaults methods could be overridden by each interface implementer, but from now, interfaces may also include static<\/code> methods, for example:<\/p>\n
\npackage com.javacodegeeks.advanced.design;\n\npublic interface InterfaceWithDefaultMethods {\n    static void createAction() {\n        \/\/ Implementation here\n    }\n} <\/pre>\n
One may say that providing an implementation in the interface defeats the whole purpose of contract-based development, but there are many reasons why these features were introduced into the Java language and no matter how useful or confusing they are, they are there for you to use.<\/p>\n
The functional interfaces are a different story and they are proven to be very helpful add-on to the language. Basically, the functional interface is the interface with just a single abstract method declared in it. The Runnable<\/code> interface from Java standard library is a good example of this concept:<\/p>\n
\n@FunctionalInterface\npublic interface Runnable {\n    void run();\n} <\/pre>\n
The Java compiler treats functional interfaces differently and is able to convert the lambda function into the functional interface implementation where it makes sense. Let us take a look on following function definition:<\/p>\n
\npublic void runMe( final Runnable r ) {\n    r.run();\n} <\/pre>\n
To invoke this function in Java 7 and below, the implementation of the Runnable<\/code> interface should be provided (for example using Anonymous classes<\/a>), but in Java 8 it is enough to pass run()<\/code> method implementation using lambda syntax:
 
<\/div> <\/div><\/p>\n
\nrunMe( () -> System.out.println( \"Run!\" ) ); <\/pre>\n
Additionally, the @FunctionalInterface<\/code> annotation (annotations will be covered in details in part 5<\/strong> of the tutorial, How and when to use Enums and Annotations<\/strong>) hints the compiler to verify that the interface contains only one abstract method so any changes introduced to the interface in the future will not break this assumption.<\/p>\n
<\/a>5. Abstract classes<\/h2>\n
Another interesting concept supported by Java language is the notion of abstract classes. Abstract classes are somewhat similar to the interfaces in Java 7 and very close to interfaces with default methods in Java 8. By contrast to regular classes, abstract classes cannot be instantiated but could be subclassed (please refer to the section Inheritance<\/a> for more details). More importantly, abstract classes may contain abstract methods: the special kind of methods without implementations, much like interfaces do. For example:<\/p>\n
\npackage com.javacodegeeks.advanced.design;\n\npublic abstract class SimpleAbstractClass {\n    public void performAction() {\n        \/\/ Implementation here\n    }\n\n    public abstract void performAnotherAction();\n} <\/pre>\n
In this example, the class SimpleAbstractClass<\/code> is declared as abstract<\/code> and has one abstract<\/code> method declaration as well. Abstract classes are very useful when most or even some part of implementation details could be shared by many subclasses. However, they still leave the door open and allow customizing the intrinsic behavior of each subclass by means of abstract methods.<\/p>\n
One thing to mention, in contrast to interfaces which can contain only public<\/code> declarations, abstract classes may use the full power of accessibility rules to control abstract methods visibility (please refer to the sections Visibility<\/a> and Inheritance<\/a> for more details).<\/p>\n
<\/a>6. Immutable classes<\/h2>\n
Immutability is becoming more and more important in the software development nowadays. The rise of multi-core systems has raised a lot of concerns related to data sharing and concurrency (in the part 9<\/strong>, Concurrency best practices<\/strong>, we are going to discuss in details those topics). But the one thing definitely emerged: less (or even absence of) mutable state leads to better scalability and simpler reasoning about the systems.<\/p>\n
Unfortunately, the Java language does not provide strong support for class immutability. However using a combination of techniques it is possible to design classes which are immutable. First and foremost, all fields of the class should be final<\/code>. It is a good start but does not guarantee immutability alone.<\/p>\n
\npackage com.javacodegeeks.advanced.design;\n\nimport java.util.Collection;\n\npublic class ImmutableClass {\n    private final long id;\n    private final String[] arrayOfStrings;\n    private final Collection< String > collectionOfString;\n} <\/pre>\n
Secondly, follow the proper initialization: if the field is the reference to a collection or an array, do not assign those fields directly from constructor arguments, make the copies instead. It will guarantee that state of the collection or array will not be changed from outside.<\/p>\n
\npublic ImmutableClass( final long id, final String[] arrayOfStrings,\n        final Collection< String > collectionOfString) {\n    this.id = id;\n    this.arrayOfStrings = Arrays.copyOf( arrayOfStrings, arrayOfStrings.length );\n    this.collectionOfString = new ArrayList<>( collectionOfString );\n} <\/pre>\n
And lastly, provide the proper accessors (getters). For the collection, the immutable view should be exposed using Collections.unmodifiableXxx<\/code> wrappers.<\/p>\n
\npublic Collection<String> getCollectionOfString() {\n    return Collections.unmodifiableCollection( collectionOfString );\n} <\/pre>\n
With arrays, the only way to ensure true immutability is to provide a copy instead of returning reference to the array. That might not be acceptable from a practical standpoint as it hugely depends on array size and may put a lot of pressure on garbage collector.<\/p>\n
\npublic String[] getArrayOfStrings() {\n    return Arrays.copyOf( arrayOfStrings, arrayOfStrings.length );\n} <\/pre>\n
Even this small example gives a good idea that immutability is not a first class citizen in Java yet. Things can get really complicated if an immutable class has fields referencing another class instances. Those classes should also be immutable however there is no simple way to enforce that.<\/p>\n
There are a couple of great Java source code analyzers like FindBugs<\/a><\/strong>) and PMD<\/a><\/strong>) which may help a lot by inspecting your code and pointing to the common Java programming flaws. Those tools are great friends of any Java developer.
\n[ulp id=’w6F4W4SAMiyTapBF’]
\n <\/p>\n
<\/a>7. Anonymous classes<\/h2>\n
In the pre-Java 8 era, anonymous classes were the only way to provide in-place class definitions and immediate instantiations. The purpose of the anonymous classes was to reduce boilerplate and provide a concise and easy way to represent classes as expressions. Let us take a look on the typical old-fashioned way to spawn new thread in Java:<\/p>\n
\npackage com.javacodegeeks.advanced.design;\n\npublic class AnonymousClass {\n    public static void main( String[] args ) {\n        new Thread(\n            \/\/ Example of creating anonymous class which implements\n            \/\/ Runnable interface\n            new Runnable() {\n                @Override\n                public void run() {\n                    \/\/ Implementation here\n                }\n            }\n        ).start();\n    }\n} <\/pre>\n
In this example, the implementation of the Runnable<\/code> interface is provided in place as anonymous class. Although there are some limitations associated with anonymous classes, the fundamental disadvantages of their usage are a quite verbose syntax constructs which Java imposes as a language. Even the simplest anonymous class which does nothing requires at least 5 lines of code to be written every time.<\/p>\n
\n   new Runnable() {\n      @Override\n      public void run() {\n      }\n   } <\/pre>\n
Luckily, with Java 8, lambdas and functional interfaces all this boilerplate is about to gone away, finally making the Java code to look truly concise.<\/p>\n
\npackage com.javacodegeeks.advanced.design;\n\npublic class AnonymousClass {\n    public static void main( String[] args ) {\n        new Thread( () -> { \/* Implementation here *\/ } ).start();\n    }\n} <\/pre>\n
<\/a>8. Visibility<\/h2>\n
We have already talked a bit about Java visibility and accessibility rules in part 1<\/strong> of the tutorial, How to design Classes and Interfaces<\/a><\/strong>. In this part we are going to get back to this subject again but in the context of subclassing.<\/p>\n
\n\n\n\n\n\n\n\n
Modifier<\/strong><\/td>\nPackage<\/strong><\/td>\nSubclass<\/strong><\/td>\nEveryone Else<\/strong><\/td>\n<\/tr>\n
public<\/strong><\/td>\naccessible<\/td>\naccessible<\/td>\nAccessible<\/td>\n<\/tr>\n
protected<\/strong><\/td>\naccessible<\/td>\naccessible<\/td>\nnot accessible<\/strong><\/td>\n<\/tr>\n
<no modifier><\/strong><\/td>\naccessible<\/td>\nnot accessible<\/strong><\/td>\nnot accessible<\/strong><\/td>\n<\/tr>\n
private<\/strong><\/td>\nnot accessible<\/strong><\/td>\nnot accessible<\/strong><\/td>\nnot accessible<\/strong><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
Table 1<\/p>\n<\/div>\n
Different visibility levels allow or disallow the classes to see other classes or interfaces (for example, if they are in different packages or nested in one another) or subclasses to see and access methods, constructors and fields of their parents.<\/p>\n
In next section, Inheritance<\/a>, we are going to see that in action.<\/p>\n
<\/a>9. Inheritance<\/h2>\n
Inheritance is one of the key concepts of object-oriented programming, serving as a basis of building class relationships. Combined together with visibility and accessibility rules, inheritance allows designing extensible and maintainable class hierarchies.<\/p>\n
Conceptually, inheritance in Java is implemented using subclassing and the extends<\/code> keyword, followed by the parent class. The subclass inherits all of the public and protected members of its parent class. Additionally, a subclass inherits the package-private members of the parent class if both reside in the same package. Having said that, it is very important no matter what you are trying to design, to keep the minimal set of the methods which class exposes publicly or to its subclasses. For example, let us take a look on a class Parent<\/code> and its subclass Child<\/code> to demonstrate different visibility levels and their effect:<\/p>\n
\npackage com.javacodegeeks.advanced.design;\n\npublic class Parent {\n    \/\/ Everyone can see it\n    public static final String CONSTANT = \"Constant\";\n\n    \/\/ No one can access it\n    private String privateField;\n    \/\/ Only subclasses can access it\n    protected String protectedField;\n\n    \/\/ No one can see it\n    private class PrivateClass {\n    }\n\n    \/\/ Only visible to subclasses\n    protected interface ProtectedInterface {\n    }\n\n    \/\/ Everyone can call it\n    public void publicAction() {\n    }\n\n    \/\/ Only subclass can call it\n    protected void protectedAction() {\n    }\n\n    \/\/ No one can call it\n    private void privateAction() {\n    }\n\n    \/\/ Only subclasses in the same package can call it\n    void packageAction() {\n    }\n}\n<\/pre>\n
\npackage com.javacodegeeks.advanced.design;\n\n\/\/ Resides in the same package as parent class\npublic class Child extends Parent implements Parent.ProtectedInterface {\n    @Override\n    protected void protectedAction() {\n        \/\/ Calls parent's method implementation\n        super.protectedAction();\n    }\n\n    @Override\n    void packageAction() {\n        \/\/ Do nothing, no call to parent's method implementation\n    }\n\n    public void childAction() {\n        this.protectedField = \"value\";\n    }\n}\n<\/pre>\n
Inheritance is a very large topic by itself, with a lot of subtle details specific to Java. However, there are a couple of easy to follow rules which could help a lot to keep your class hierarchies concise. In Java, every subclass may override any inherited method of its parent unless it was declared as final<\/code> (please refer to the section Final classes and methods<\/a>).<\/p>\n
However, there is no special syntax or keyword to mark the method as being overridden which may cause a lot of confusion. That is why the @Override<\/code> annotation has been introduced: whenever your intention is to override the inherited method, please always use the @Override<\/code> annotation to indicate that.<\/p>\n
Another dilemma Java developers are often facing in design is building class hierarchies (with concrete or abstract classes) versus interface implementations. It is strongly advised to prefer interfaces to classes or abstract classes whenever possible. Interfaces are much more lightweight, easier to test (using mocks) and maintain, plus they minimize the side effects of implementation changes. Many advanced programming techniques like creating class proxies in standard Java library heavily rely on interfaces.<\/p>\n
<\/a>10. Multiple inheritance<\/h2>\n
In contrast to C++ and some other languages, Java does not support multiple inheritance: in Java every class has exactly one direct parent (with Object<\/code> class being on top of the hierarchy as we have already known from part 2<\/strong> of the tutorial, Using methods common to all objects<\/a><\/strong>). However, the class may implement multiple interfaces and as such, stacking interfaces is the only way to achieve (or mimic) multiple inheritance in Java.<\/p>\n
\npackage com.javacodegeeks.advanced.design;\n\npublic class MultipleInterfaces implements Runnable, AutoCloseable {\n    @Override\n    public void run() {\n        \/\/ Some implementation here\n    }\n\n    @Override\n    public void close() throws Exception {\n       \/\/ Some implementation here\n    }\n} <\/pre>\n
Implementation of multiple interfaces is in fact quite powerful, but often the need to reuse an implementation leads to deep class hierarchies as a way to overcome the absence of multiple inheritance support in Java.<\/p>\n
\npublic class A implements Runnable {\n    @Override\n    public void run() {\n        \/\/ Some implementation here\n    }\n}\n<\/pre>\n
\n\/\/ Class B wants to inherit the implementation of run() method from class A.\npublic class B extends A implements AutoCloseable {\n    @Override\n    public void close() throws Exception {\n       \/\/ Some implementation here\n    }\n}\n<\/pre>\n
\n\/\/ Class C wants to inherit the implementation of run() method from class A\n\/\/ and the implementation of close() method from class B.\npublic class C extends B implements Readable {\n    @Override\n    public int read(java.nio.CharBuffer cb) throws IOException {\n       \/\/ Some implementation here\n    }\n}\n<\/pre>\n
And so on… The recent Java 8 release somewhat addressed the problem with the introduction of default methods. Because of default methods, interfaces actually have started to provide not only contract but also implementation. Consequently, the classes which implement those interfaces are automatically inheriting these implemented methods as well. For example:<\/p>\n
\npackage com.javacodegeeks.advanced.design;\n\npublic interface DefaultMethods extends Runnable, AutoCloseable {\n    @Override\n    default void run() {\n        \/\/ Some implementation here\n    }\n\n    @Override\n    default void close() throws Exception {\n       \/\/ Some implementation here\n    }\n}\n\n\/\/ Class C inherits the implementation of run() and close() methods from the\n\/\/ DefaultMethods interface.\npublic class C implements DefaultMethods, Readable {\n    @Override\n    public int read(java.nio.CharBuffer cb) throws IOException {\n       \/\/ Some implementation here\n    }\n} <\/pre>\n
Be aware that multiple inheritance is a powerful, but at the same time a dangerous tool to use. The well known \u201cDiamond of Death\u201d problem is often cited as the fundamental flaw of multiple inheritance implementations, so developers are urged to design class hierarchies very carefully. Unfortunately, the Java 8 interfaces with default methods are becoming the victims of those flaws as well.<\/p>\n
\ninterface A {\n    default void performAction() {\n    }\n}\n\ninterface B extends A {\n    @Override\n    default void performAction() {\n    }\n}\n\ninterface C extends A {\n    @Override\n    default void performAction() {\n    }\n} <\/pre>\n
For example, the following code snippet fails to compile:<\/p>\n
\n\/\/ E is not compilable unless it overrides performAction() as well\ninterface E extends B, C {\n} <\/pre>\n
At this point it is fair to say that Java as a language always tried to escape the corner cases of object-oriented programming, but as the language evolves, some of those cases are started to pop up.<\/p>\n
<\/a>11. Inheritance and composition<\/h2>\n
Fortunately, inheritance is not the only way to design your classes. Another alternative, which many developers consider being better than inheritance, is composition. The idea is very simple: instead of building class hierarchies, the classes should be composed from other classes.<\/p>\n
Let us take a look on this example:<\/p>\n
\npublic class Vehicle {\n    private Engine engine;\n    private Wheels[] wheels;\n    \/\/ ...\n} <\/pre>\n
The Vehicle<\/code> class is composed out of engine<\/code> and wheels<\/code> (plus many other parts which are left aside for simplicity). However, one may say that Vehicle<\/code> class is also an engine and so could be designed using the inheritance.<\/p>\n
\npublic class Vehicle extends Engine {\n    private Wheels[] wheels;\n    \/\/ ...\n} <\/pre>\n
Which design decision is right? The general guidelines are known as IS-A<\/strong> and HAS-A<\/strong> principles. IS-A<\/strong> is the inheritance relationship: the subclass also satisfies the parent class specification and a such IS-A<\/strong> variation of parent class. Consequently, HAS-A <\/strong>is the composition relationship: the class owns (or HAS-A<\/strong>) the objects which belong to it. In most cases, the HAS-A <\/strong>principle works better then IS-A <\/strong>for couple of reasons:<\/p>\n