Design-Pattern-in-java

It's not so much about: This is the only way we can do this!

But more: Hey, check out this crazy alternative way to do this!

With design patterns in general, I would strongly encourage you to just look at them as ideas of how to do certain things and not as solutions to specific problems.

It's more like... they will teach you interesting ways to approach certain circumstances, that you might not have considered before. So when you get to a point where you actually need something similar, your brain doesn't say 'Nope, never thought that way, leave me alone.", but make connections it might not make otherwise.

I've never seen anyone go: "Let's use the XYZ Design Pattern to do this!" However, when people have to explain their code, I have sometimes heard them refer to certain design patterns. It means they don't have to explain that specific part of their train of thought and still be understood.

Like "Well, it's kind of like a Chain of Responsibility Pattern, except ..."

So don't spend too much time wondering why and use your time to explore and understand the how. Talking about design choices takes way too much time anyway. There are pros and cons to everything.

Finally, let's actually talk about the why for a moment, as much as I don't want to. I'll keep it brief though and I'm sure there are other aspects to consider as well.

(Note: When I say 'part of the chain' I mean a lower part ending at the same end point. Like A->B->C->D->E->F. I would be talking about C->D->E->F or D->E->F, but not about B->C->D)

• If you want to switch out part of the chain, you only need to change one variable. In your for, there'll be a whole lot of ifs to either remove, comment out or put somewhere else because you don't need them anymore. Also, you can easily keep your old chain around without cluttering up the code that is being used.
• It is very easy to use part of the same chain at different places. If you only use part of the if-statements in your loop but replace others, that means you'll need to create a new loop where the parts you do still use get copied over. Better to avoid duplicate code.
• Well... testing and having multiple developers working on different parts at once would be easier with the chain, but only if your loop is very simple. If you start calling methods to do parts (ideally from different classes), it should be just as easy to do it without the pattern.
• The person that created the design pattern might nod at you approvingly if you ever meet them and tell them you used their pattern.

Honestly though, except for the last point, the others will also be achieved by just structuring the code surrounding your loop differently. Then again, that is pretty much exactly what you do by using this design pattern anyway ;)

Q1) Interface adaptation just means adapting one interface to implement another, i.e., what adapters are for. I'm not sure what they mean by "built-in", but it sounds like a specific feature of Smalltalk, with which I'm not familiar.

Q2) A "Pluggable Adapter" is an adapter class that implements the target interface by accepting implementations for its individual methods as constructor arguments. The purpose is to allow adapters to be expressed succinctly. In all cases, this requires the target interface to be small, and it usually requires some kind of language facility for succinctly providing a computation - a lambda or delegate or similar. In Java, the facility for inline classes and functional interfaces means that a specific adapter class that accepts lambda arguments is unnecessary.

Pluggable adapters are a convenience. They are not important beyond that. However...

Q3) The quoted text isn't about pluggable adapters, and neither of the two use cases has a pluggable adapter in it. That part is about the Interface Segregation Principle, and it is important.

In the first example, TreeDisplay is subclassed. The actual adapter interface is the subset of methods in TreeDisplay that require implementation. This is less than ideal, because there is no concise definition of the interface that the adapter must implement, and the DirectoryTreeDisplay cannot simultaneously implement another similar target interface. Also such implementations tend interact with the subclass in complex ways.

In the second example, TreeDisplay comes with a TreeAccessorDelegate interface that captures the requirements for things it can display. This is a small interface that that can be easily implemented in a variety of ways, including by a pluggable adapter. (although the example DirectoryBrowser is not pluggable). Also, interface adaptation does not have to be the sole purpose of the adapter class. You see that DirectoryBrowser class implements methods that have nothing to do with tree display.

The Node type in these examples would be an empty/small interface, i.e., another adapter target, or even a generic type argument so that no adaptation is required. I think this design could be improved, actually, by making Node the only adaptation target.

You have to implement them because in this case ShapeDecorator is only an abstract class implements Shape: it simply provide a uniform way to store the decorated Shape:

BufferedInputStream is implemented in exactly the same way as your Car example. It decorates an InputStream which, although it's an abstract class, still provides a contract, just as an interface would. An abstract class was chosen in this case because there are methods with default behaviour (read and skip) and, at the time the class was written, interfaces were not able to support this (they can now, but default methods in interfaces were added much later).

Because an abstract class was used for the contract, BufferedInputStream extends FilterInputStream, just as CarDecorator implements Car. Both are just simple holders for a delegate. They contain a single protected field (an InputStream and a Car) and delegate all method calls to the field. The reason for this is because, if you have a large number of methods in your contract, delegating all of the methods in every decorator might result in a lot of code duplication. When your interface only has a single method, as yours does, then it provides very little benefit.

This is certainly not a necessary component of the decorator pattern; it's just a slightly different way of implementing it. Your implementation is still a 100% correct implementation of the decorator pattern.

Your suggestion is fine IMHO. It also matches the GOF original: decorator

When discussing patterns in general, it's important to remember that variants are acceptable, there's no "Pattern Police" to reprimand you for every tiny deviation (as long as it's well considered)... If it were me, I'd change some of the article's AbstractClasses to interfaces, and I still believe my design intent would be clear and acceptable.

Perhaps you can ask the author in the comments (though it's an old post). If I had to guess, I'd assume the author wanted to leave some flexibility in the "currentSandwich" declaration/location (like taking it from a threadLocal, putting together 2 sandwitches, etc), but such 'creativity' would ruin the generality and modularity - namely the freedom to wrap several decorators one over the other. I'd prefer my decorators to stick to a well-defined "currentSandwitch", in which case it's fine to adopt your idea.