Creational Patterns ( ์ƒ์„ฑ ํŒจํ„ด )

These design patterns provides way to create objects while hiding the creation logic, rather than instantiating objects directly using new operator. This gives program more flexibility in deciding which objects need to be created for a given use case. 

์ƒ์„ฑํŒจํ„ด์€ ๊ฐ์ฒด์˜ ์ƒ์„ฑ๋กœ์ง์„ ์ˆจ๊ธฐ๊ณ  new ๋ช…๋ น์–ด๋ฅผ ํ†ตํ•˜์ง€ ์•Š๊ณ  ๊ฐ์ฒด๋ฅผ ์ƒ์„ฑํ•˜๋Š” ๋ฐฉ๋ฒ•๋“ค์„ ์ œ๊ณตํ•œ๋‹ค. ์ด๋Š” ํŠน์ • ์ƒํ™ฉ์—์„œ ์–ด๋–ค ๋ฐฉ๋ฒ•์œผ๋กœ ๊ฐ์ฒด๋ฅผ ์ƒ์„ฑํ•ด์•ผํ• ์ง€๋ฅผ ๊ฒฐ์ •ํ•˜๋Š”๋ฐ ์žˆ์–ด์„œ ์œ ์—ฐ์„ฑ์„ ์ œ๊ณตํ•œ๋‹ค. 


 Structural Patterns ( ๊ตฌ์กฐ์  ํŒจํ„ด )

These design patterns concern class and object composition. Concept of inheritance is used to compose interfaces and define ways to compose objects to obtain new functionalities. 

๊ตฌ์กฐ์  ํŒจํ„ด๋“ค์€ ํด๋ž˜์Šค์™€ ๊ฐ์ฒด์˜ ๊ตฌ์„ฑ์— ๊ด€์—ฌํ•œ๋‹ค.

 

 Behavioral Patterns ( ํ–‰์œ„์  ํŒจํ„ด )

These design patterns are specifically concerned with communication between objects.

์ด ํŒจํ„ด๋“ค์€ ๊ฐ์ฒด๋“ค ์‚ฌ์ด์˜ ์ปค๋ฎค๋‹ˆ์ผ€์ด์…˜์— ๊ด€์‹ฌ์„ ๊ฐ€์ง„๋‹ค.

 

์˜ค๋Š˜ ์‚ดํŽด๋ณผ  Memento ํŒจํ„ด์€ Behavioral ํŒจํ„ด์— ์†ํ•ฉ๋‹ˆ๋‹ค. 

 

Memento Pattern Structure

 




  

ํŒจํ„ด์˜ ๋ชฉ์  ( Intent ) :  

Without violating encapsulation, capture and externalize an object's internal state so that the object can be restored to this state later.


ํŒจํ„ด์ด ๋‚˜์˜ค๊ฒŒ ๋œ ๋™๊ธฐ ( Motivation ) :

    ๋‹ค์ด์–ด๊ทธ๋žจ์„ ๊ทธ๋ฆฌ๋Š” ํˆด์„ ์˜ˆ๋กœ ๋“ค์–ด๋ณด๊ฒ ์Šต๋‹ˆ๋‹ค. ์‚ฌ๊ฐํ˜• ๋‘๊ฐœ๋ฅผ ๊ทธ๋ฆฌ๊ณ  ๋‘ ์‚ฌ๊ฐํ˜•์„ ์„ ์œผ๋กœ ์—ฐ๊ฒฐํ•ฉ๋‹ˆ๋‹ค. ์ž ์ด์ œ ์•„๋ž˜์ชฝ ์‚ฌ๊ฐํ˜•์„ ์˜ค๋ฅธ์ชฝ์œผ๋กœ ์ด๋™์‹œํ‚ต๋‹ˆ๋‹ค. ๊ทธ๋Ÿฌ๋ฉด ์•„๋ž˜ ๊ทธ๋ฆผ์ฒ˜๋Ÿผ ๋‘ ์‚ฌ๊ฐํ˜•์„ ์ด์€ ์„ ๋„ ๋”ฐ๋ผ์„œ ์ด๋™ํ•˜๋ฉด์„œ ๋‘ ์‚ฌ๊ฐํ˜•์„ ๊ณ„์† ์ด์–ด์ค๋‹ˆ๋‹ค.  


์ด๋ ‡๊ฒŒ ๋‘ ๊ฐ์ฒด ์‚ฌ์ด์˜ ์—ฐ๊ฒฐ ๊ด€๊ณ„๋ฅผ ์œ ์ง€์‹œํ‚ค๋Š” ์ž˜ ์•Œ๋ ค์ง„ ๋ฐฉ๋ฒ•์ค‘ ํ•˜๋‚˜๋Š” ์ œ์•ฝ-ํ•ด๊ฒฐ ์‹œ์Šคํ…œ(constraint-solving system)์ž…๋‹ˆ๋‹ค. ์ด ์‹œ์Šคํ…œ์€ ConstraintSolver ์— ์บก์Šํ™”๋˜์–ด ์žˆ์Šต๋‹ˆ๋‹ค. ConstraintSolver๋Š” ๊ฐ์ฒด๋“ค ์‚ฌ์ด์˜ ์—ฐ๊ฒฐ์„ ๊ธฐ๋กํ•˜๊ณ  ์ด ์—ฐ๊ฒฐ์„ ์„ค๋ช…ํ•˜๋Š” ์ˆ˜ํ•™์‹์„ ์ƒ์„ฑํ•ฉ๋‹ˆ๋‹ค. ๊ทธ๋ž˜์„œ ๊ฐ์ฒด์˜ ์œ„์น˜๊ฐ€ ๋ณ€๊ฒฝ์ด ๋˜๋ฉด ์ด ์ˆ˜ํ•™์‹์„ ๋‹ค์‹œ ๊ณ„์‚ฐํ•˜์—ฌ ์„ ์„ ์–ด๋–ป๊ฒŒ ๊ทธ๋ ค์•ผ ํ•˜๋Š”์ง€๋ฅผ ์•Œ ์ˆ˜ ์žˆ๋Š” ๊ฒƒ์ž…๋‹ˆ๋‹ค.

 

ํ•˜ ์ง€๋งŒ ๋˜๋Œ๋ฆฌ๊ธฐ ๊ธฐ๋Šฅ์€ ์ƒ๊ฐ์ฒ˜๋Ÿผ ์‰ฝ์ง€๊ฐ€ ์•Š์Šต๋‹ˆ๋‹ค. ๋งŒ์•ฝ ์‚ฌ๊ฐํ˜•์ด ์›€์ง์ธ ๊ฑฐ๋ฆฌ๋ฅผ ๊ณ„์‚ฐํ•˜์—ฌ ๊ทธ๋งŒํผ ๋‹ค์‹œ ๋˜๋Œ๋ฆฐ๋‹ค๊ณ  ํ–ˆ์„ ๋•Œ ๊ณผ์—ฐ ๋‘ ์‚ฌ๊ฐํ˜•์„ ์—ฐ๊ฒฐํ•˜๋Š” ์„ ์€ ์–ด๋–ป๊ฒŒ ์›€์ง์—ฌ์•ผ ํ•˜๋Š”๊ฐ€๋ฅผ ์ƒ๊ฐํ•ด์•ผ ํ•ฉ๋‹ˆ๋‹ค. ๊ทธ๋ ‡์ง€ ์•Š์œผ๋ฉด ์•„๋ž˜์™€ ๊ฐ™์ด ๋ถˆ์™„์ „ํ•œ ๋˜๋Œ๋ฆฌ๊ธฐ๊ฐ€ ๋˜์–ด๋ฒ„๋ฆด ํ…Œ๋‹ˆ๊นŒ์š”.

 

์ผ ๋ฐ˜์ ์œผ๋กœ ConstraintSolver์˜ public interface ๋Š” undo๊ธฐ๋Šฅ์„ ์™„์ „ํžˆ ๊ตฌํ˜„ํ•˜๊ธฐ์— ๋ถˆ์ถฉ๋ถ„ํ•ฉ๋‹ˆ๋‹ค. undo ๋ฉ”์นด๋‹ˆ์ฆ˜์€ ์ด์ „์˜ ์ƒํƒœ๋ฅผ ๋‹ค์‹œ ๋ถˆ๋Ÿฌ์˜ค๊ธฐ ์œ„ํ•ด์„œ ConstraintSolver์™€ ์ข€ ๋” ๋ฐ€์ ‘ํ•œ ๊ด€๊ณ„๋ฅผ ๋งบ์–ด์•ผ ํ•˜์ง€๋งŒ ํ•œํŽธ์œผ๋กœ๋Š” ConstraintSolver์˜ ๋‚ด๋ถ€๋ฅผ ๋…ธ์ถœ์‹œํ‚ค๋ฉด ์•ˆ๋ฉ๋‹ˆ๋‹ค. ์ด ๋ฌธ์ œ๋ฅผ ํ’€๊ธฐ์œ„ํ•ด์„œ ๋‚˜์˜จ ํŒจํ„ด์ด ๋ฐ”๋กœ ๋ฉ”๋ฉ˜ํ†  ํŒจํ„ด์ž…๋‹ˆ๋‹ค. ๋ฉ”๋ฉ˜ํ† ๋Š” ๋‹ค๋ฅธ ๊ฐ์ฒด(๋ฉ”๋ฉ˜ํ† ์˜ originator)์˜ ๋‚ด๋ถ€ ์ƒํƒœ๋ฅผ ์ €์žฅํ•˜๋Š” ๊ฐ์ฒด์ž…๋‹ˆ๋‹ค. undo ๋ฉ”ํƒ€๋‹ˆ์ฆ˜์€ originator์˜ ์ด์ „ ์ƒํƒœ๊ฐ€ ํ•„์š”ํ•  ๋•Œ ๋ฉ”๋ฉ˜ํ† ๋ฅผ ์š”์ฒญํ•˜๊ฒŒ ๋ฉ๋‹ˆ๋‹ค. originator๋Š” ์ž์‹ ์˜ ํ˜„์žฌ ์ƒํƒœ๋ฅผ ๋ฉ”๋ฉ˜ํ† ์— ์ €์žฅํ•ฉ๋‹ˆ๋‹ค. ๊ทธ๋ฆฌ๊ณ  ์˜ค๋กœ์ง€ originator๋งŒ์ด ๋ฉ”๋ฉ˜ํ† ์— ์ €์žฅํ•œ ์ž์‹ ์˜ ์ƒํƒœ๋ฅผ ์ €์žฅ ๋˜๋Š” ์ฝ์–ด์˜ฌ ์ˆ˜๊ฐ€ ์žˆ์Šต๋‹ˆ๋‹ค โ€” ๋ฉ”๋ฉ˜ํ† ๋Š” ๋‹ค๋ฅธ ๊ฐ์ฒด๋“ค์—๊ฒŒ "์˜คํŒŒํฌ(์นจํˆฌํ•  ์ˆ˜ ์—†๋Š” ๊ฒƒ)"๋ผ๊ณ  ํ•  ์ˆ˜ ์žˆ์ฃ . ์œ„์—์„œ ์˜ˆ๋กœ ๋“  ํˆด์—์„œ ConstraintSolver๋Š” originator์˜ ์—ญํ• ์„ ํ•˜๋Š”๊ฑฐ์ฃ .  

 

The following sequence of events characterizes theundo process:

      1. The editor requests a memento from the ConstraintSolver as aside-effect of the move operation.

      2. The ConstraintSolver creates and returns a memento, an instance of a class SolverState in this case. A SolverState memento contains data structures that describe the current state of the ConstraintSolver's internal equations and variables.

      3. Later when the user undoes the move operation, the editor gives the SolverState back to the ConstraintSolver.

      4. Based on the information in the SolverState, the ConstraintSolver changes its internal structures to return its equations and variables to their exact previous state.

This arrangement lets the ConstraintSolver entrust other objects with the information it needs to revert to a previous state without exposing its internal structure and representations.



์œ ์šฉ์„ฑ ( Applicability ) :

 

Use the Memento pattern when

    • a snapshot of (some portion of) an object's state must be saved so that it can be restored to that state later, and

    • a direct interface to obtaining the state would expose implementation details and break the object's encapsulation.



๋“ฑ์žฅ ์ธ๋ฌผ ( Participants ) :


โ€ข Memento (SolverState)

o stores internal state of the Originator object. The memento may store as much or as little of the originator's internal state as necessary at its originator's discretion.
o protects against access by objects other than the originator. Mementos have effectively two interfaces. Caretaker sees a narrow interface to the Mementoโ€”it can only pass the memento to other objects. Originator, in contrast, sees a wide interface, one that lets it access all the data necessary to restore itself to its previous state. Ideally, only the originator that produced the memento would be permitted to access the memento's internal state.

โ€ข Originator (ConstraintSolver)

o creates a memento containing a snapshot of its current internal state.
o uses the memento to restore its internal state.

โ€ข Caretaker (undo mechanism)

o is responsible for the memento's safekeeping.
o never operates on or examines the contents of a memento.

 

 

์›๋ฆฌ ( Collaborations ) :  

โ€ข A caretaker requests a memento from an originator, holds it for a time, and passes it back to the originator, as the following interaction diagram illustrates:   



 

 

Sometimes the caretaker won't pass the memento back to the originator, because the originator might never need to revert to an earlier state.

โ€ข Mementos are passive. Only the originator that created a memento will assign or retrieve its state.

 


ํŒจํ„ด ์‚ฌ์šฉ๋ฒ•

    1. Identify the roles of โ€œcaretakerโ€ and โ€œoriginatorโ€.
    2. Create a Memento class and declare the originator a friend.
    3. Caretaker knows when to "check point" the originator.
    4. Originator creates a Memento and copies its state to that Memento.
    5. Caretaker holds on to (but cannot peek into) the Memento.
    6. Caretaker knows when to "roll back" the originator.
    7. Originator reinstates itself using the saved state in the Memento.

ํŒจํ„ด ์‚ฌ์šฉ์˜ ์žฅ๋‹จ์  ( Consequences ): 

The Memento pattern has several consequences:

 

    1. Preserving encapsulation boundaries. Memento avoids exposing information that only an originator should manage but that must be stored nevertheless outside the originator. The pattern shields other objects from potentially complex Originator internals, thereby preserving encapsulation boundaries.

    2. It simplifies Originator. In other encapsulation-preserving designs, Originator keeps the versions of internal state that clients have requested. That puts all the storage management burden on Originator. Having clients manage the state they ask for simplifies Originator and keeps clients from having to notify originators when they're done.

    3. Using mementos might be expensive. Mementos might incur considerable overhead if Originator must copy large amounts of information to store in the memento or if clients create and return mementos to the originator often enough. Unless encapsulating and restoring Originator state is cheap, the pattern might not be appropriate.

    4. Defining narrow and wide interfaces. It may be difficult in some languages to ensure that only the originator can access the memento's state.

    5. Hidden costs incaring for mementos. A caretaker is responsible for deleting the mementos it cares for. However, the caretaker has no idea how much state is in the memento. Hence an otherwise lightweight caretaker might incur large storagecosts when it stores mementos.


๊ด€๋ จ ํŒจํ„ด๋“ค :  

 

Command : Commands can use mementos to maintain state for undoable operations.  

Iterator : Mementos can be used for iteration as described earlier.



์ถ”๊ฐ€ ์ •๋ณด :       

    • Command and Memento act as magic tokens to be passed around and invoked at a later time. In Command, the token represents a request; in Memento, it represents the internal state of an object at a particular time. Polymorphism is important to Command, but not to Memento because its interface is so narrow that a memento can only be passed as a value.
    • Command can use Memento to maintain the state required for an undo operation.
    • Memento is often used in conjunction with Iterator. An Iterator can use a Memento to capture the state of an iteration. The Iterator stores the Memento internally.

 

 


 

์ถœ์ฒ˜ :  http://sourcemaking.com/design_patterns/memento

Design Patterns : Element of Reusable Object Oriented Software ( by GoF, 1994 )