7

I have a question similar to this other question

Why aren't design patterns added to the languages constructs?

Why isn't there java.util.Singleton and then we inherit it? The boilerplate code seems to be always the same.

class Singleton {
    private static final Singleton s = new Singleton();

    public static Singleton getInstance() {
        return s;
    }

    protected Singleton() {
    }
}

class XSingleton extends Singleton {

}

Now if there was a Singleton built-in to Java then we wouldn't have to include the same boiler-plate over and over in projects. We could just inherit the code that makes the Singleton and just code our specific in our XSingleton that extends Singleton.

I suppose the same goes for other design patterns e.g. MVC and similar. Why aren't more design pattern built into the standard libraries?

15
  • 6
    Ignoring that people don't really like singletons; most of that seems to achieve nothing. If you are going to use singletons (usually not a good idea) why not just access it as Singleton.s Commented Jan 11, 2017 at 11:50
  • 12
    OK, let's run with the premise of your question. I have a Frobulator. There's only one of them. How do I make a singleton Frobulator using your base class? If it is so easy then you should be able to write the code in a comment. Bonus: once you've done that: did I mention that Frobulator extends Blobulator, and Blobulator is not a singleton? Now how would you write the code to make a singleton Frobulator? Commented Jan 11, 2017 at 12:44
  • 16
    For a more complex example, see stackoverflow.com/questions/35951818/…, where I describe why the "monad" design pattern cannot have a type in Java or C#. What you should be taking away from the monad and singleton examples is: design patterns need to be invented because type systems are insufficiently powerful to describe the pattern. Commented Jan 11, 2017 at 12:46
  • 3
    @DacSaunders: The purpose of an interface is to capture the notion of common functionality independent of implementation. What common functionality independent of implementation would you like to capture for the notion of "singleton"? Can you describe a method that takes only instances of singletons? Here, I have a singleton task scheduler, a singleton string pool, and a singleton vampire-attack-resolution-rulebook. What useful method takes those, and only those things? Commented Jan 11, 2017 at 17:10
  • 5
    If there is no method in the world that can reasonably have the signature void DoSomethingUseful(Singleton s) then there is no incentive to developers to make their singleton types implement that interface. Contrast that with a pattern that is embedded in the language, such as "non-local goto for error handling". There is an incentive for developers to participate in the exception pattern by inheriting from its base class because doing so buys them a useful feature. And there are useful methods that take exceptions. Commented Jan 11, 2017 at 17:15

4 Answers 4

35

I want to challenge your basic premise, namely that Design Patterns aren't added to the standard library. For example, java.util.Iterator<E> is in the standard library and is an implementation of the Iterator Design Pattern. java.util.Observable/java.util.Observer is an implementation of the Publish/Subscribe Design Pattern. java.lang.reflect.Proxy is an implementation of the Proxy Design Pattern.

Looking at other languages, e.g. Ruby has the delegate and forwardable libraries, both implementations of the Proxy Design Pattern, the observer library, an implementation of the Publish/Subscribe Pattern, and the singleton library, an implementation of the Singleton Design Pattern.

24

Design patterns are recurring designs which cannot be captured in a class or library. Usually they have to do with how multiple classes interact. The standard library of a language can use patterns just like other code can - eg. the Java IO library uses the decorator pattern. But the decorator pattern itself cannot be captured in a single class or library.

A typical definition of design patter (taken from Wikipedia):

In software engineering, a software design pattern is a general reusable solution to a commonly occurring problem within a given context in software design. It is not a finished design that can be transformed directly into source or machine code. It is a description or template for how to solve a problem that can be used in many different situations.

(My emphasis) So by definition a standard library cannot provide design patterns as reusable components the same way it provides regular classes as reusable component. Or to put it another way: If some design pattern can be captured in reusable code, we stop calling it a pattern. List<T> is a broadly useful design, but since this can be captured in a reusable class, we don't usually call it a "pattern" - it is just a class.

But a framework can encourage and to some extent enforce the use of certain design patterns. Eg. a MVC framework more or less forces you to write code following the MVC pattern.

There are different reasons why patterns cannot be captured as a reusable class, depending on the pattern:

  1. The pattern is is too abstract. E.g. an "Adapter" is a pattern where a class transforms one interface to another. The concept is pretty simple, but the actual implementation will be fully dependent on the semantics of the two interfaces in actuation. There is simply no shared boilerplate code between different application of the Adapter pattern, so it cannot be included as a reusable component in a library.

  2. The pattern is not possible to implement in a reusable form. Some patterns are really workaround for language limitations. E.g. the "Visitor" pattern is really a hack to allow a single-dispatch language to support multiple dispatch. There is some boilerplate code, but the boilerplate code cannot be generalized in a reusable way. A language with built-in support for multiple dispatch would not need the visitor pattern in the first place.

    (And as pointed out in several comments, the Singleton implementation you provide cannot be generalized to a reusable class, since statics are not inherited.)

7
  • 1
    and we can't inherits static aniway it will be one instance for all that inherits ;D
    – Walfrat
    Commented Jan 11, 2017 at 12:16
  • 1
    might be worth pointing out the interplay between different languages i.e. what is a pattern in one language could be a language/library feature in another
    – jk.
    Commented Jan 11, 2017 at 14:05
  • 2
    Ok, I think now I understand your point, and your answer looks much better now. Changed my downvote into an upvote. I see it is debatable if the cases mentioned by JörgWMittag are really "pattern implementations", or if they are just help to implement them for a user of the Java standard lib.
    – Doc Brown
    Commented Jan 12, 2017 at 10:46
  • "Or to put it another way: If some design pattern can be captured in reusable code, we stop calling it a pattern." -- I'm not sure this is really true. Consider Iterator; it is clear that the pattern can be captured using reusable OO code, as this is done in the standard libraries of many languages. Nobody has stopped calling it a pattern, though. I think we call it a pattern because we need to be able to talk about it at a higher level than implementation details in order to discuss how it relates to other code, and whether it's implemented by the developer or the language is irrelevant. Commented Jan 12, 2017 at 11:38
  • 3
    @PeriataBreatta: we only call the iterator a design pattern now in an academic sense, because its in the GoF book. In the days of all assembly, functions could be considered a pattern, frequently implemented in a particular way. We don't generally call functions a design pattern now because it's so commonplace and integral to programming today. Iterators are similar now, they weren't so much in 1994 Commented Jan 12, 2017 at 20:22
5

I fear a subtlety of the word "pattern" is being lost here. Think of a suit. A pattern defines the features - e.g. there are pockets, arms, legs etc. However, it doesn't define every single detail (buttons, fabric, lining etc) - this is left to the implementer.

Yes, for a lot of design patterns there is boilerplate code many of us tend to use, but for others, there is more than one way of achieving the pattern with no generally agreed method.

1
  • Fabric patterns usually do indicate how things are put together, they specify stitch types, notion placement and other details. Come to think of it, since the choice of fabrics and colors etc is left to the tailor, fabric patterns pretty much describe exclusively how to put a garment together. Might wanna pick a different analogy. Commented Jan 12, 2017 at 20:23
2

Why isn't there java.util.Singleton and then we inherit it?

Because a singleton is static and we can't use inheritance on static members. Also, it's considered better practice to declare a Singleton using an enum:

public enum MySingleton{
    INSTANCE;

    //class content goes below
}

It would also be hard to use inheritance here as an enum extends java.lang.Enum and that cannot be changed, and there is no way to remove the 1 line of boilerplate code.

This is why java.util.Singleton doesn't exist.


Why aren't design patterns added to the languages constructs?

Quite a lot are already in the jdk standard library - quite a few classes provide some functionality when using patterns, for example: java.util.Observer is implemented when using the Observer patterns and others utilize design patterns, for example: java.lang.StringBuilder utilizes the Builder pattern.

As for why you don't see them all:

  • Some design patterns are hard to abstract away with classes/interfaces/enums/ect (java.util.Singleton for example).
  • It's not worth putting in the standard library.
  • It hasn't been thought of yet.
  • There is no need for it.
1
  • The first half of this answer is a rather specific limitation of the particular language and pattern chosen as an example. Plenty of languages do have the necessary machinery to implement a Singleton base class, and Java happens not to; but that doesn't really tell us much about the relationship between patterns and language features.
    – IMSoP
    Commented Jan 16, 2017 at 10:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.