Implementing the Skeletal Implementation design pattern

Let's explore the java standart library a little bit?

The java Collections framework is used by java developers in a daily baisis, mostly the List interface, which is preferable to use instead of Array.

But, the main point here is that e use List and Maps often.

We have a good number of good implementations already in Java Standart Library (mostly in java.util package), and we can consume other implementations from third party libraries, like Apache Commons and Google Guava.

If needed, we can create our own implementation of these interfaces.

But, it can appear difficult to create our own implementation suitable to our needs, because these interfaces have a good number of methods to implement. Just a small portion of the methods have default implementation. That way, we have many methods that requires the user to implement them.

On List interface, I see 25 methods to implement, just on sight:

But, to the rescue, these interfaces have some pre-implementations that make the user life easier, and you struggle less to implement.

These pre-implementations are variants of Skeleton Implementation Design Pattern. How it works?

Suppose I created an interface that suggests some complexity. The DataProcessor interface below have 9 methods, which is a considerable number to implement, and the main purpose of it is to apply transformation into data through many ways, using a fixed class.

Interfaces are public, and generally we gonna use this interface as parameters in methods or fields in another classes. If someone needs to implement this interface for a data pipeline, will be somewhat difficult to implement all these methods.

Let's make it easier for our users to use this interface by including a skeleton which implementations for some methods.

To make it, we gonna:

• Make an abstract class
• Name it AbstractThing
• Implement some methods with a default implementation

In the process, we need to think which methods should be required, and which methods the user can achieve his task without ever think about to modify the implementation.

That way, the user have a starting point to make the implementation easier. At the end, now the user have to implement only 4 methods if he uses the AbstractDataProcessor for the task:

The Collection Frameworks interfaces follows the same logic. We have AbstractList and AbstractMap as starting points for implementing my own implementations of these collections.

For AbstractList, is required to implement only two methods:

Fr AbstractMap, is more simple, requiring you to implement only one method:

We should note that, the user isn't required to implement all methods, but it doesn't means that he can't implement it. If needed, he can override the other methods that exists in the type hierarchy.