Inner Classes vs. Subclasses in Java

1. Introduction

In this tutorial, we’ll take a closer look at two important constructs in Java, Inner Classes and Subclasses. There are two different ways of writing the classes in Java, and they differ in usage. 

2. Subclasses in Java

One of the core principles of Object Oriented Programming is inheritance. It introduces the idea of a class inheriting the properties and behaviors of another class, the parent class. Inheritance and the usage of subclasses promote code reusability and the organization of classes in a hierarchy. 

Subclasses define an “is-a” relationship with its parent, i.e. an object of the subclass is an object of its parent class. This supports the concept of polymorphism and promotes more generic coding by allowing us to work with instances of different subclasses through the common parent class. 

Defining and using subclasses also allows us to create highly specialized classes that can extend and override specific functionalities of their parent classes. This supports the Open Closed principle of the SOLID principles. 

3. Inner Classes in Java

Inner classes are a form of Nested Classes in Java and are defined within the boundaries of another host class. 

There are many types of inner classes in Java, such as Nested Inner classes, Static Inner classes, Method Local Inner classes, and Anonymous Inner classes. While each of these inner classes differs slightly from each other, the central idea of the inner class remains the same. This arrangement fosters tighter encapsulation and enhances readability, given that this inner class finds no usage beyond the outer class. Consequently, this approach offers an improved method of grouping classes.

Inner classes consistently remain in the same file as the outer class. We cannot instantiate inner classes without using an instance of the outer class unless we have defined a static inner class. 

4. The Need for Subclasses

In this section, we’ll demonstrate the properties of subclasses by taking the example of a Notifications system. The primary component in a Notification module is a Notifier class, whose purpose is to send a notification:

public class Notifier {
    void notify(Message e) {
        // Implementation details of sending the message via email
    }
}

The Message class encapsulates the relevant contents of the message to be delivered. 

This Notifier class is too generic and does not define ways to send different types of notifications. If our system can only send out an email, this class works fine. However, if we want to expand the system’s capabilities to other communication channels, such as text messages or calls, we reach its limit. 

One of the ways to do that would be to define multiple methods inside this class and assign each of them the responsibility of notifying via a specific channel:

public class Notifier {
    void notifyViaEmail(Message e) {
        // Implementation details of sending the message via email
    }

    void notifyViaText(Message e) {
        // Implementation details of sending the message via text message
    }

    void notifyViaCall(Message e) {
        // Implementation details of making an outgoing call
    }
}

This approach has too many downsides associated with it:

• the Notifier class has too many responsibilities and knows too much about the different channels
• the size of the class will increase multifold with every new channel brought it
• this design does not account for different implementation requirements of certain communication channels themselves, such as RCS, SMS/MMS

In order to solve these problems, we take the help of the paradigm of Inheritance in Object Oriented Programming and come up with a refactor. 

We assign Notifier as the base or the parent class in the system and make it abstract:

public abstract class Notifier {
    abstract void notify(Message e);
}

With this change, the Notifier class has no idea of the notification logic or the channels. It relies on its subclasses to define the behavior. All our communication channels exhibit an is-a relationship with Notifier, such as EmailNotifier is a Notifier:

public class EmailNotifier extends Notifier {
    @Override
    void notify(Message e) {
        // Provide email specific implementation here
    }
}

public class TextMessageNotifier extends Notifier {
    @Override
    void notify(Message e) {
        // Provide text message specific implementation here
    }
}

public class CallNotifier extends Notifier {
    @Override
    void notify(Message e) {
        // Provide phone call specific implementation here
    }
}

With this approach, we can extend our system to as many channel-specific implementations as required. We can define instances of the specific subclass implementation as required and use it: 

void notifyMessages() {
    // Sending a Text Message
    Message textMessage = new Message();
    Notifier textNotifier = new TextMessageNotifier();

    textNotifier.notify(textMessage);

    // Sending an Email Message
    Message emailMessage = new Message();
    Notifier emailNotifier = new EmailNotifier();

    emailNotifier.notify(emailMessage);
}

We find inheritance and the usage of subclasses abundant in the Java JDK. Let’s take the Collection API of Java as an example. We have an AbstractList class in the Collections API, which is extended by concrete implementations such as LinkedList, ArrayList, and Vector, which are subclasses of it. 

5. The Need for Inner Classes

Inner classes help in localizing important code constructs while still encapsulating them in the form of a class. In our previous example, the notifiers use different underlying notification logic, which could be very different from one another.

For example, an email notifier might need information about SMTP servers and other logic to send out the email. On the other hand, a text message notifier would need a phone number that sends the text message. Among all these notifiers, there is minimal shared code. They are also useful only in the context of their own notifiers.

Our EmailNotifier implementation would need information and access to an SMTP server to send the email. We can write the boilerplate code related to connecting and sending the email as an inner class: 

class EmailNotifier extends Notifier {
    @Override
    void notify(Message e) {
        // notify method implementation
    }

    // Inner class for email connection
    static class EmailConnector {
        private String emailHost;
        private int emailPort;
        // Getter Setters

        private void connect() {
            // connect to the smtp server
        }
    }
}

We can consequently use the inner class in the outer class’s notify() method to send the email:

@Override
void notify(Message e) {
    // connect to the email connector and send email
    EmailConnector emailConnector = new EmailConnector();
    emailConnector.connect();
    // send email
}

The usage of inner classes in the Java JDK can be found in the LinkedList implementation of the List interface. The Node class is created as a static inner class, as its usage outside of a LinkedList is meaningless and unnecessary. A similar approach is taken in the design of the HashMap class, which uses Entry as an inner class. 

6. Differences Between Subclasses and Inner Classes

We can summarize the differences between subclasses and inner classes in Java as follows: 

• Inner classes always stay inside the same file as the outer class, whereas subclasses can be separate
• Inner classes (except for static ones) cannot access member variables or methods of its outer class, whereas subclasses can access from their parent classes
• We cannot instantiate inner classes directly(unless they are static inner classes), whereas subclasses can be
• We create inner classes mostly to use them as small helper classes; however, subclasses help in overriding parent class’ functionalities

7. Conclusion

In this article, we discussed subclasses, inner classes, and their role in writing modular object-oriented code. We also looked at the differences between them and when to choose one over the other.