Wikipedia (2010). Structural patterns. Online resource at
http://en.wikipedia.org/wiki/Structural_pattern.
Wikipedia's article on the Bridge pattern says it is often confused with the Adapter pattern, and is often implemented using the Class adapter pattern. At what point does a variation on one design pattern become a wholly new design pattern, rather than simply a variation of the original? Many of these patterns do very similar things - most are concerned with wrapping a class or altering it somehow so that it will work with an interface - and I wonder how they got divided into these specific choices.
Can you provide a concrete example of the Decorator pattern? While the examples on Wikipedia explain what it is quite well, I can't think of any real-world examples where it would be the most sensible approach.
How does the adapter pattern differ from the bridge pattern, since they seem fairly similar from my viewpoint?
What is the deal with aggreg*? It makes sense for aggregation to be
relationship between objects, but why do we need to name iterators this
way? Isn't there an iterator design pattern?
The Python and Ruby examples are so much more concise than the Java and
C++ examples, but they don't seem to be worse. Is that magic?
The "Composite Pattern" is referred to as a specific design pattern. I was under the impression that objects composing other objects was a basic concept, but this article refers to a specific design pattern. Is it important for me to be aware of this distinction?
Could you elaborate on what the Bridge Pattern is? The description was vague and didn't include a good example of when and why to use it.
Is there a danger of overusing the Adapter pattern? It has been suggested by previous readings that inheritance is too often the solution of choice for design problems. It seems like the use of Adapter classes might exacerbate that, and potentially allow for subclasses that are significantly unrelated to one another.
Does the Retrofit Interface Pattern violate Single Responsibility? My understanding's a bit vague since it doesn't have an article, and I'd like if we could talk about it.
I'm confused with how the extensibility pattern could be implemented. They mention things such as Little Languages and Facade Patterns. Does the extensibility pattern always need to be used in conjunction with multiple other patterns?
Is it common to use multiple design patterns in conjunction with each other?
Regarding pipelines, I'm confused with what the article means by multi-processed pipelines. Does this mean that each 'end of the pipe' is running concurrently?
Under the decorator pattern, the wiki reading uses an example of creating two decorators which both add functionality to the same method. Isn't the use of two decorators somewhat dangerous? What if the added functionality from the two methods conflicts in some way? (i.e. borders get drawn on top of scrollbars).
A proxy is described as a "place-holder" for an object that is expensive to instantiate; could you better explain or provide an example of how exactly a proxy is used in this setting?
What is the minimum number of objects to warrant a configuration using flyweights (10, 100, 1000..)?
Could you give some non-GUI examples of a flyweight?
(Half project/Half reading question)
Could we use flyweight objects in our project in the visual representation of the board, even though each cell will have its own 'state' (color/species)? How could we do this?
;
