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.

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

 

์˜ค๋Š˜ ์‚ดํŽด๋ณผ  Command ( ๋ช…๋ น, ์ปค๋งจ๋“œ )ํŒจํ„ด์€ Behavioral ํŒจํ„ด์— ์†ํ•œ๋‹ค.   

๋ช…๋ น ํŒจํ„ด์ด๋ผ~ ๋ช…๋ น์„ ๋‚ด๋ฆฌ๋Š” ํŒจํ„ด์ด๋ผ๋Š” ๊ฑฐ๊ฒ ์ฃ ??

์ž์„ธํžˆ ์•Œ์•„๋ด…์‹œ๋‹ค.

 

Command Pattern Structure

 


 


  

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

Encapsulate a request as an object, thereby letting you parameterize clients with different requests, queue or log requests, and support undoable operations.  

๋ช…๋ น ํŒจํ„ด, ์ปค๋งจ๋“œ ํŒจํ„ด์€ ํ•˜๋‚˜์˜ ์š”์ฒญ์„ ํ•˜๋‚˜์˜ ๊ฐ์ฒด๋กœ ์บก์Šํ™”ํ•˜์—ฌ ์š”์ฒญ์„ ํŒŒ๋ผ๋ฏธํ„ฐ์ฒ˜๋Ÿผ ์‚ฌ์šฉํ•  ์ˆ˜ ์žˆ๊ฒŒ๋” ํ•ด์ฃผ๋ฉฐ ๋˜๋Œ๋ฆฌ๊ธฐ ๊ธฐ๋Šฅ์„ ์ง€์›ํ•œ๋‹ค. 


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

   Need to issue requests to objects without knowing anything about the operation being requested or the receiver of the request.

์ด ํŒจํ„ด์ด ๋‚˜์˜ค๊ฒŒ ๋œ ๋™๊ธฐ๋ผ ํ•˜๋ฉด ๊ฐ„๋‹จํžˆ ๋งํ•ด์„œ ์š”์ฒญ์„ ๋‚ ๋ฆด ๋•Œ ์–ด๋–ค ์š”์ฒญ์ด ๋‚ ์•„๊ฐ€๋Š”์ง€ ๋ฆฌ์‹œ๋ฒ„๊ฐ€ ๋ˆ„๊ตฌ์ธ์ง€์— ๋Œ€ํ•ด์„œ ๋ชฐ๋ผ๋„ ๋˜๊ฒŒ๋” ํ•˜๊ธฐ ์œ„ํ•ด์„œ ์ž…๋‹ˆ๋‹ค.  

 

GoF์˜ ๋””์ž์ธ ํŒจํ„ด์—์„œ๋Š” ์‘์šฉํ”„๋กœ๊ทธ๋žจ์˜ ๋ฉ”๋‰ด๋ฅผ ํด๋ฆญํ–ˆ์„ ๋•Œ ์–ด๋–ค ๋ช…๋ น์„ ์‹คํ–‰ํ•˜๋Š” ๊ฒƒ์„ ์˜ˆ๋กœ ๋“ค์—ˆ์Šต๋‹ˆ๋‹ค.


 ์œ„ ํด๋ž˜์Šค ๋‹ค์ด์–ด๊ทธ๋žจ์€ ์‘์šฉํ”„๋žจ์—์„œ ๋ฉ”๋‰ด๋ฅผ ์„ ํƒํ•ด์„œ ๋“ค์–ด๊ฐ€๊ณ  ํ•˜์œ„๋ฉ”๋‰ด๋ฅผ ํด๋ฆญํ–ˆ์„ ๋•Œ ํŠน์ • ๋ช…๋ น์ด ์‹คํ–‰๋˜๋Š” ๊ฒƒ์„ ๋‚˜ํƒ€๋‚ด๊ณ  ์žˆ์Šต๋‹ˆ๋‹ค.๋ฉ”๋‰ด์•„์ดํ…œ์€ ์ปค๋งจ๋“œ ๊ฐ์ฒด๋ฅผ ๊ฐ€์ง€๊ณ  ์žˆ๊ณ  ์ด ์ปค๋งจ๋“œ ๊ฐ์ฒด๋Š” ์‹คํ–‰ํ•  ์ˆ˜ ์žˆ๋Š” ๊ธฐ๋Šฅ์ด ๊ตฌํ˜„๋˜์–ด ์žˆ์„ ๊ฒƒ์ž…๋‹ˆ๋‹ค. ๋ฉ”๋‰ด์•„์ดํ…œ๊ฐ์ฒด๋Š” ์ด ์ปค๋งจ๋“œ๊ฐ์ฒด๊ฐ€ ๋ฌด์Šจ ๋ช…๋ น์„ ์‹คํ–‰ํ•˜๋Š” ์ง€๋Š” ๋ชจ๋ฅด๊ณ  ๊ทธ๋ƒฅ ์‹คํ–‰๋งŒ ์‹œํ‚ค๋Š” ๊ฒ๋‹ˆ๋‹ค. 

 

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

Use the Command pattern when you want to

๋ช…๋ น ํŒจํ„ด์€ ์ด๋Ÿด ๋•Œ ์“ฐ์„ธ์š”. 

โ€ข parameterize objects by an action to perform, as MenuItem objects did above. You can express such parameterization in a procedural language with a callback function, that is, a function that's registered somewhere to be called at a later point. Commands are an object-oriented replacement for callbacks.  

 

โ€ข specify, queue, and execute requests at different times. A Command object can have a lifetime independent of the original request. If the receiver of a request can be represented in an address space-independent way, then you can transfer a command object for the request to a different process and fulfill the request there.

 

โ€ข support undo. The Command's Execute operation can store state for reversing its effects in the command itself. The Command interface must have an added Unexecute operation that reverses the effects of a previous call to Execute. Executed commands are stored in a history list. Unlimited-level undo and redo is achieved by traversing this list backwards and forwards calling Unexecute and Execute, respectively.

 

โ€ข support logging changes so that they can be reapplied in case of a system crash. By augmenting the Command interface with load and store operations, you can keep a persistent log of changes. Recovering from a crash involves reloading logged commands from disk and reexecuting them with the Execute operation.

 

โ€ข structure a system around high-level operations built on primitives operations. Such a structure is common in information systems that support transactions. A transaction encapsulates a set of changes to data. The Command pattern offers a way to model transactions. Commands have a common interface, letting you invoke all transactions the same way. The pattern also makes it easy to extend the system with new transactions.



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


โ€ข Command

o declares an interface for executing an operation.  

โ€ข ConcreteCommand

o defines a binding between a Receiver object and an action.

o implements Execute by invoking the corresponding operation(s) on Receiver.

โ€ข Client 

           o creates a ConcreteCommand object and sets its receiver.
โ€ข Invoker

           o asks the command to carry out the request.
โ€ข Receiver

           o
knows how to perform the operations associated with carrying out a request. Any class may serve as a Receiver.


์›๋ฆฌ ( Collaborations ) :

  • The client creates a ConcreteCommand object and specifies its receiver.
  • An Invoker object stores the ConcreteCommand object.
  • The invoker issues a request by calling Execute on the command. When commands are undoable, ConcreteCommand stores state for undoing thecommand prior to invoking Execute.

  • The ConcreteCommand object invokes operations on its receiver to carryout the request.

 

The following diagram shows the interactions between these objects.It illustrates how Command decouples the invoker from the receiver(and the request it carries out).

 

 


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

  1. Define a Command interface with a method signature like execute().
  2. Create one or more derived classes that encapsulate some subset of the following: a "receiver" object, the method to invoke, the arguments to pass.
  3. Instantiate a Command object for each deferred execution request.
  4. Pass the Command object from the creator (aka sender) to the invoker (aka receiver).
  5. The invoker decides when to execute().

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

The Command pattern has the following consequences:  

  1. Command decouples the object that invokes the operation from the one that knows how to perform it.
  2. Commands are first-class objects.They can be manipulated and extended like any other object.
  3. You can assemble commands into a composite command. In general, composite commands are an instance of the Composite pattern.
  4. It's easy to add new Commands, because you don't have to change existing classes.

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

A Composite can be used to implement MacroCommands.
A Memento can keep state the command requires to undo its effect.

A command that must be copied before being placed on the historylist acts as a Prototype.


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

  • Chain of Responsibility, Command, Mediator, and Observer, address how you can decouple senders and receivers, but with different trade-offs. Command normally specifies a sender-receiver connection with a subclass.
  • Chain of Responsibility can use Command to represent requests as objects.
  • 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.
  • MacroCommands can be implemented with Composite.
  • A Command that must be copied before being placed on a history list acts as a Prototype.
  • Two important aspects of the Command pattern: interface separation (the invoker is isolated from the receiver), time separation (stores a ready-to-go processing request that's to be stated later).

 

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

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