Gamma, Erich, Helm, Richard, Johnson, Ralph, Vlissides, John (1995).
Design Patterns: Elements of Reusable Object-Oriented Software.
Chapter 1: Introduction. Boston, MA: Addison-Wesley.
I notice that this was published in 1995 - have design patterns really not changed all that much in the past 15 years? Or is this simply the standard text to give background on design patterns, and we'll be using auxiliary materials to learn about new developments?
This is the work that coined the concept of Design Patterns (at least in CS; they stole it from architecture). I think it does a better job than many in talking about the key concepts. And, certainly, these are the core patterns. (In some sense, these are like stacks and queues - there are newer data structures, but you need to know about stacks and queues before you consider others.)
Could you elaborate on the differences between design patterns with a class scope and those in the scope of objects?
I had a bit of trouble tracing the graph on page 12. Could we go over it in class (if it's pertinent to what we're supposed to take from the reading)?
I found the section on "Relating Run-Time and Compile-Time Structures" (page 22) difficult to comprehend, especially since they use as an example a concept I am also unfamiliar with (the distinction between aggregation and acquaintance). Googling yielded such unhelpful results as equally incomprehensible academic papers and a link to a pdf of this same chapter.
Could you also clarify the difference in aggregation and acquaintance. I'm not sure what is meant by an object lasts the lifetime of its owner versus the idea that an object knows of another object. I'm not sure how they're related.
It's the old "aggregation vs. composition" or "aggregation vs. association" issue. Many designers clearly think that it's useful to note cases in which an object is used only by one other object. (Certainly, there are implementation benefits to having that knowledge.)
Granularity is the extent to which a system is broken down into small parts (or objects). In Object Oriented Programming, how is this granularity measured and how can one determine the ideal amount of granularity? How do design patterns such as Facade, Flyweight, and Builder help us with this? (13)
Because design patterns are so ubiquitous, should
programming languages include them as language features? In Java, stating that
an object implements Serializable makes it Serializable without any other
changes, so it seems like this could be extended to design patterns like
Singleton or Flyweight pretty easily. Is there any reason not to do this?
They add complexity to the language and therefore encourage subsetting. The "obvious" usage may not be obvious to everyone. But, certainly, there's movement in that direction. (E.g., Iterators are now standard to most languages.)
I always hear "program to an interface, not an implementation". It says to not declare variables as instances as concrete classes, but how do creational patterns manage to avoid having to do that?
Actually, many of the creational patterns are designed to deal with just this issue. So, for example, the Factory patterns are designed to make it easier to create values w/o knowing the class (therefore letting you fill in the field) and the Builder pattern lets you initialize that variable, even though it's not in a concrete class.
On page 17 the authors discuss programming to an interface rather than an implementation. I'm not entirely clear what he means by that.
It means that you program using only on the specification of the methods (and, preferably, a rather general specification), not on particular details of a particular implementation of those methods. For example, code that uses a Map should not care (except for efficiency) whether that Map is implemented as hash table, an association list, a BST, or whatever.
Are these design patterns strictly for use in an object oriented environment, or do many of these ideas translate to a functional programming paradigm too? When patterns such as the factory and builder are mentioned they are described in detail using the terminology of OO. Could these patterns be interpreted as basic higher order functions? If so, are they straightforward enough in a language like Lisp that they aren't really "design patterns" anymore, but are instead just "the way you program"?
Didn't we discuss this? Some design patterns are obvious enough in a functional environment that they don't even seem worthy of deep exploration. Others are still useful. Some don't necessarily translate well. For example, Builder implies state changes, which isn't necessarily appropriate in a functional language.
This reading brings up the idea of a "mixin class". What is your stance on these? It seems to me that in many cases it would be better to either subclass differently or use composition. I assume there are cases where they are useful, so could you provide an example of one? Has the movement towards supporting multiple inheritance in programming languages been in anyway triggered by a desire to use mixin classes?
I think of it a bit differently ... If your class needs the functionality of two other classes, multiple inheritance is one technique for achieving that goal. But, as you note, association with delegation can also provide that functionality. (And, in fact, that's how the term "mixin" has come to be used.) I'll work on an example.
The authors claim that "frameworks are becoming increasingly common and important" (28). In what domains are frameworks most commonly used, and what are some examples? How do frameworks differ from libraries and APIs?
;
