디자인 패턴 공부 순서

출처: http://www.industriallogic.com/papers/learning.html

Design Patterns Navigation

l Factory Method		Session 1
Begin with Factory Method. This pattern is used by a number of patterns in the book and throughout the patterns literature.
u Strategy		Session 2
Strategy is used frequently throughout the book, and an early knowledge of it helps in understanding other patterns.
n Decorator		Session 3
For an early dose of elegance, nothing is better than the Decorator. The discussion of "skin" vs. "guts" is a great way to differentiate Decorator from the previous pattern, Strategy.
n Composite		Session 4
The Composite pattern appears everywhere and is often used with Iterator, Chain of Responsibility, Interpreter, and Visitor patterns.
u Iterator		Session 5
Reenforce the reader's understanding of Composite by studying Iterator.
u Template Method		Session 6
The author's footnote to Iterator explains that a method called "Traverse" in the Iterator example code is an example of a Template Method. This pattern also reenforces Strategy and Factory Method.
l Abstract Factory		Session 7
The reader now returns to the second-easiest creational pattern, the Abstract Factory. This pattern also helps reenforce Factory Method.
l Builder		Session 8
The reader now may compare another creational pattern, the Builder, with the Abstract Factory.
l Singleton		Session 9
Singleton is often used to model Abstract Factories, as the "Related Patterns" section of Singleton describes.
n Proxy		Session 10
The reader now has a chance to learn how Proxy is used to control access to an object. This pattern leads directly into the next pattern, Adapter.
n Adapter		Session 11
The Adapter pattern may be compared with what the reader understands about Decorator, Proxy, and later, Bridge.
n Bridge		Session 12
Finally, the reader learns how the Bridge pattern differs from both the Adapter and Proxy patterns.
u Mediator		Session 13
Now the reader learns the Mediator pattern, in preparation for understanding Observer and the Model-View-Controller design.
u Observer		Session 14
Discover how the Mediator is used by the Observer to implement the classic Model-View-Controller design.
u Chain of Responsibility		Session 15
After exploring how messages are passed using the Observer and Mediator patterns, the reader now may contrast how messages are handled by the Chain of Responsibility pattern.
u Memento		Session 16
The reader now moves on to Memento. This pattern leads directly into a discussion of undo and redo, which is related to the next pattern, Command.
u Command		Session 17
The Command pattern is used in a number of ways, one of which relates to the previous pattern, Mediator.
l Prototype		Session 18
Perhaps the most complex creational pattern, Prototype is often used with the Command pattern.
u State		Session 19
The reader may now study State to understand another way an object's behavior changes.
u Visitor		Session 20
Visitor is often combined with the Composite and/or Iterator patterns.
n Flyweight		Session 21
The Flyweight pattern is one of the more complex patterns. An examples use of this pattern is described in the next pattern, Interpreter.
u Interpreter		Session 22
The Interpreter pattern is complex. It makes reference to and helps reenforce one's understanding of Flyweight and Visitor.
n Facade		Session 23
The final pattern to read is Facade. Facade is relatively straightforward and follows nicely after Interpreter since the example code is similar in theme to example code in the Interpreter.

 
Opening Questions For A Study Group

l Factory Method		Session 1
How does Factory Method promote loosely coupled code?
u Strategy		Session 2
Part 1: What happens when a system has an explosion of Strategy objects? Is there some way to better manage these strategies? Part 2: In the implementation section of this pattern, the authors describe two ways in which a strategy can get the information it needs to do its job. One way describes how a strategy object could get passed a reference to the context object, thereby giving it access to context data. But is it possible that the data required by the strategy will not be available from the context's interface? How could you remedy this potential problem?
n Decorator		Session 3
In the Implementation section of the Decorator Pattern, the authors write: A decorator object's interface must conform to the interface of the component it decorates. Now consider an object A, that is decorated with an object B. Since object B "decorates" object A, object B shares an interface with object A. If some client is then passed an instance of this decorated object, and that method attempts to call a method in B that is not part of A's interface, does this mean that the object is no longer a Decorator, in the strict sense of the pattern? Furthermore, why is it important that a decorator object's interface conforms to the interface of the component. it decorates?
n Composite		Session 4
Part 1: How does the Composite pattern help to consolidate system-wide conditional logic? Part 2: Would you use the composite pattern if you did not have a part-whole hierarchy? In other words, if only a few objects have children and almost everything else in your collection is a leaf (a leaf can have no children), would you still use the composite pattern to model these objects?
u Iterator		Session 5
Consider a composite that contains loan objects. The loan object interface contains a method called "AmountOfLoan()", which returns the current market value of a loan. Given a requirement to extract all loans above, below or in between a certain amount, would you write or use an Iterator to do this?
u Template Method		Session 6
The Template Method relies on inheritance. Would it be possible to get the same functionality of a Template Method, using object composition? What would some of the tradeoffs be?
l Abstract Factory		Session 7
In the Implementation section of this pattern, the authors discuss the idea of defining extensible factories. Since an Abstract Factory is composed of Factory Methods, and each Factory Method has only one signature, does this mean that the Factory Method can only create an object in one way? Consider the MazeFactory example. The MazeFactory contains a method called MakeRoom, which takes as a parameter one integer, representing a room number. What happens if you would also like to specify the room's color & size? Would this mean that you would need to create a new Factory Method for your MazeFactory, allowing you to pass in room number, color and size to a second MakeRoom method? Ofcourse, nothing would prevent you from setting the color and size of the Room object after is has been instantiated, but this could also clutter your code, especially if you are creating and configuring many objects. How could you retain the MazeFactory and keep only one MakeRoom method but also accomodate different numbers of parameters used by MakeRoom to both create and configure Room objects?
l Builder		Session 8
Like the Abstract Factory pattern, the Builder pattern requires that you define an interface, which will be used by clients to create complex objects in pieces. In the MazeBuilder example, there are BuildMaze(), BuildRoom() and BuildDoor() methods, along with a GetMaze() method. How does the Builder pattern allow one to add new methods to the Builder's interface, without having to change each and every sub-class of the Builder?
l Singleton		Session 9
The Singleton pattern is often paired with the Abstract Factory pattern. What other creational or non-creational patterns would you use with the Singleton pattern?
n Proxy		Session 10
If a Proxy is used to instantiate an object only when it is absolutely needed, does the Proxy simplify code?
n Adapter		Session 11
Would you ever create an Adapter that has the same interface as the object which it adapts? Would your Adapter then be a Proxy?
n Bridge		Session 12
How does a Bridge differ from a Strategy and a Strategy's Context?
u Mediator		Session 13
Since a Mediator becomes a repository for logic, can the code that implements this logic begin to get overly complex, possible resembling speggheti code? How could this potential problem be solved?
u Observer		Session 14
Part 1: The classic Model-View-Controller design is explained in Implementation note #8: Encapsulating complex update semantics. Would it ever make sense for an Observer (or View) to talk directly to the Subject (or Model)? Part 2: What are the properties of a system that uses the Objserver pattern extensively? How would you approach the task of debugging code in such a system? Part 3: Is it clear to you how you would handle concurrency problems with is pattern? Consider an Unregister() message being sent to a subject, just before the subject sends a Notify() message to the ChangeManager (or Controller).
u Chain of Responsibility		Session 15
Part 1: How does the Chain of Responsibility pattern differ from the Decorator pattern or from a linked list?. Part 2: Is it helpful to look at patterns from a structural perspective? In other words, if you see how a set of patterns are the same in terms of how they are programmed, does that help you to understand when to apply them to a design?
u Memento		Session 16
The authors write that the "Caretaker" participant never operates on or examines the contents of a memento. Can you consider a case where a Caretaker would infact need to know the identity of a memento and thus need the ability to examine or query the contents of that memento? Would this break something in the pattern?
u Command		Session 17
In the Motivation section of the Command pattern, an application's menu system is described. An application has a Menu, which in turn has MenuItems, which in turn execute commands when they are clicked. What happens if the command needs some information about the application in order to do its job? How would the command have access to such information such that new comamnds could easily be written that would also have access to the information they need?
l Prototype		Session 18
Part 1: When should this creational pattern be used over the other creational patterns? Part 2: Explain the difference between deep vs. shallow copy.
u State		Session 19
If something has only two to three states, is it overkill to use the State pattern?
u Visitor		Session 20
One issue with the Visitor pattern involves cyclicality. When you add a new Visitor, you must make changes to existing code. How would you work around this possible problem?
n Flyweight		Session 21
Part 1: What is a non-GUI example of a flyweight? Part 2: What is the minimum configuration for using flyweight? Do you need to be working with thousands of objects, hundreds, tens?
u Interpreter		Session 22
As the note says in Known Uses, Interpreter is most often used "in compilers implemented in object-oriented languages...". What are other uses of Interpreter and how do they differ from simply reading in a stream of data and creating some structure to represent that data?
n Facade		Session 23
Part 1: How complex must a sub-system be in order to justify using a facade? Part 2: What are the additional uses of a facade with respect to an organization of designers and developers with varying abilities? What are the political ramifications?