'Archive' 카테고리의 다른 글
Dependency Injection (의존성 주입) (0) | 2012.01.24 |
---|---|
Enum을 사용한 State 패턴 (0) | 2012.01.24 |
한글 띄워쓰기 쉽게 교정하는 방법 (1) | 2012.01.17 |
Eclipse에서 Shift + Enter 기능 (0) | 2012.01.15 |
Javadoc에 @link로 링크걸기 (0) | 2012.01.15 |
Dependency Injection (의존성 주입) (0) | 2012.01.24 |
---|---|
Enum을 사용한 State 패턴 (0) | 2012.01.24 |
한글 띄워쓰기 쉽게 교정하는 방법 (1) | 2012.01.17 |
Eclipse에서 Shift + Enter 기능 (0) | 2012.01.15 |
Javadoc에 @link로 링크걸기 (0) | 2012.01.15 |
Pattern | Intent | Refactoring Motivations |
Builder | Separate the construction of a complex object from its representation so that the same construction process can create different representations. |
Simplify code Remove duplication Reduce creation errors |
Factory Method | Define an interface for creating an object, but let the subclasses decide which class to instantiate. The Factory Method lets a class defer instantiation to subclasses. | Remove duplication Communicate intent |
Template Method | Define the skeleton of an algorithm in an operation, deferring some steps to client subclasses. Template Method lets subclasses redefine certain steps of an algorithm without changing the algorithm's structure. | Remove duplication |
테스트하기 쉬운 코드 (0) | 2011.10.05 |
---|---|
/etc/passwd 파일의 포맷 (0) | 2011.10.04 |
디자인 패턴 공부 순서 (0) | 2011.10.04 |
프로그래머를 위한 공부론 - 김창준 (0) | 2011.10.04 |
리팩토링 (0) | 2011.10.04 |
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. |
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? |
/etc/passwd 파일의 포맷 (0) | 2011.10.04 |
---|---|
Stop Over-Engineering (0) | 2011.10.04 |
프로그래머를 위한 공부론 - 김창준 (0) | 2011.10.04 |
리팩토링 (0) | 2011.10.04 |
동시성을 고려한 설계를 하면 좋은 이유 (0) | 2011.10.04 |
|
슈뢰딩거의 고양이 이야기 (0) | 2011.10.02 |
---|---|
직교성과 테스트 (0) | 2011.10.01 |
직교적인 설계가 되어있는지 테스트하는 방법 (0) | 2011.10.01 |
코드의 직교성의 장점 (0) | 2011.10.01 |
코드내의 문서화 (0) | 2011.10.01 |