먼저 이 글은 영문 위키의 글을 번역한 글임을 알려드립니다.

영어 실력이 부족한 관계로 오역이 있을 수도 있습니다.

원문 주소 : http://en.wikipedia.org/wiki/Chain-of-responsibility_pattern



행위 패턴 - Chain-of-responsibility




객체지향 프로그래밍(Object Oriented Design)에서 chain-of-responsibility 패턴command objects의 소스와 일련의 processing objects로 구성되는 디자인 패턴이다. 각각의 processing object는 그것이 다룰 수 있는 command objects의 타입을 정의하는 로직을 포함한다.; 나머지 것들은 체인(chain)의 다음processing object에게 전달된다. 메카니즘은 체인의 마지막에 새로운 processing objects를 추가하는 것에도 존재한다. 


기본 chain-of-responsibility 모델의 변경에서는, 일부 핸들러(handlers)가 dispatchers의 역할을 할 수도 있다. 여기에서 dispatcher는 책임의 나무(tree of responsibility)의 형태를 보이게끔 다양한 방향으로 명령들을(commands) 보낼 수 있다. 몇몇 상황에서는 이런 일이 재귀적으로 발생할 수 있는데, processing objects가 더 높은 레벨의(higher-up) processing objects를 호출하고 이 때의 commands는 문제의 더 작은 일부분을 풀기위한 시도이다.; 이런 상황에서 반복(recursion)은 command가 처리될때까지 계속되거나, 전체 트리(tree)를 다 돌았을때(explored, 탐험했을때) 끝난다. XML 인터프리터는 아마도 이러한 방법으로 동작할 것이다.


이 패턴은 programming best practice의 하나로 간주되는 느슨한 결합(lose coupling)의 아이디어에서 나온 것이다.

예 Example

아래의 코드는 로그를 기록하는 클래스를 예로 들어 이 패턴에 대해 설명한다. 각각의 로그 핸들러는 현재 로그 레벨에서 어떤 행동(action)을 취할지 결정하고 다음 로그 핸들러에게 메세지를 전달한다. 이 예는 어떻게 로그 클래스를 작성하는지에 대한 추천하는 것은 아니지 주의해라.


또한 chain of responsiblity 패턴의 순수한('pure') 구현에서 로거(logger)는 메세지를 처리하고 난 뒤에 다음 체인으로 책임을 전달하지 않을지도 모른다는 것을 알아둬라. 이 예에서는 처리가 되었든 안되었든 상관안하고 메세지는 체인으로 전달될 것이다.

Java

package chainofresp;
 
abstract class Logger {
    public static int ERR = 3;
    public static int NOTICE = 5;
    public static int DEBUG = 7;
    protected int mask;
 
    // The next element in the chain of responsibility
    protected Logger next;
 
    public Logger setNext(Logger log) {
        next = log;
        return log;
    }
 
    public void message(String msg, int priority) {
        if (priority <= mask) {
            writeMessage(msg);
        }
        if (next != null) {
            next.message(msg, priority);
        }
    }
 
    abstract protected void writeMessage(String msg);
}
 
class StdoutLogger extends Logger {
    public StdoutLogger(int mask) { 
        this.mask = mask;
    }
 
    protected void writeMessage(String msg) {
        System.out.println("Writing to stdout: " + msg);
    }
}
 
 
class EmailLogger extends Logger {
    public EmailLogger(int mask) {
        this.mask = mask;
    }
 
    protected void writeMessage(String msg) {
        System.out.println("Sending via email: " + msg);
    }
}
 
class StderrLogger extends Logger {
    public StderrLogger(int mask) {
        this.mask = mask;
    }
 
    protected void writeMessage(String msg) {
        System.err.println("Sending to stderr: " + msg);
    }
}
 
public class ChainOfResponsibilityExample {
    public static void main(String[] args) {
        // Build the chain of responsibility
        Logger logger, logger1,logger2;
        logger = new StdoutLogger(Logger.DEBUG);
        logger1 = logger.setNext(new EmailLogger(Logger.NOTICE));
        logger2 = logger1.setNext(new StderrLogger(Logger.ERR));
 
        // Handled by StdoutLogger
        logger.message("Entering function y.", Logger.DEBUG);
 
        // Handled by StdoutLogger and EmailLogger
        logger.message("Step1 completed.", Logger.NOTICE);
 
        // Handled by all three loggers
        logger.message("An error has occurred.", Logger.ERR);
    }
}
/*
The output is:
   Writing to stdout:   Entering function y.
   Writing to stdout:   Step1 completed.
   Sending via e-mail:  Step1 completed.
   Writing to stdout:   An error has occurred.
   Sending via e-mail:  An error has occurred.
   Writing to stderr:   An error has occurred.
*/


C#

using System;
using System.IO;
 
namespace ChainOfResponsibility
{
    public enum LogLevel
    {
        Info=1,
        Debug=2,
        Warning=4,
        Error=8,
        FunctionalMessage=16,
        FunctionalError=32,
        All = 63
    }
 
    /// 
    /// Abstract Handler in chain of responsibility Pattern
    /// 
    public abstract class Logger
    {
        protected LogLevel logMask;
 
        // The next Handler in the chain
        protected Logger next;
 
        public Logger(LogLevel mask)
        {
            this.logMask = mask;
        }
 
        /// 
        /// Sets the Next logger to make a list/chain of Handlers
        /// 
        public Logger SetNext(Logger nextlogger)
        {
            next = nextlogger;
            return nextlogger;
        }
 
        public void Message(string msg, LogLevel severity)
        {
            if ((severity & logMask) != 0)
            {
                WriteMessage(msg);
            }
            if (next != null)
            {
                next.Message(msg, severity);
            }
        }
 
        abstract protected void WriteMessage(string msg);
    }
 
    public class ConsoleLogger : Logger
    {
        public ConsoleLogger(LogLevel mask)
            : base(mask)
        { }
 
        protected override void WriteMessage(string msg)
        {
            Console.WriteLine("Writing to console: " + msg);
        }
    }
 
    public class EmailLogger : Logger
    {
        public EmailLogger(LogLevel mask)
            : base(mask)
        { }
 
        protected override void WriteMessage(string msg)
        {
            //Placeholder for mail send logic, usually the email configurations are saved in config file.
            Console.WriteLine("Sending via email: " + msg);
        }
    }
 
    class FileLogger : Logger
    {
        public FileLogger(LogLevel mask)
            : base(mask)
        { }
 
        protected override void WriteMessage(string msg)
        {
            //Placeholder for File writing logic
            Console.WriteLine("Writing to Log File: " + msg);
        }
    }
 
    public class Program
    {
        public static void Main(string[] args)
        {
            // Build the chain of responsibility
            Logger logger, logger1, logger2;
            logger1 = logger = new ConsoleLogger(LogLevel.All);
            logger1 = logger1.SetNext(new EmailLogger(LogLevel.FunctionalMessage | LogLevel.FunctionalError));
            logger2 = logger1.SetNext(new FileLogger(LogLevel.Warning | LogLevel.Error));
 
            // Handled by ConsoleLogger
            logger.Message("Entering function ProcessOrder().", LogLevel.Debug);
            logger.Message("Order record retrieved.", LogLevel.Info);
 
            // Handled by ConsoleLogger and FileLogger
            logger.Message("Customer Address details missing in Branch DataBase.", LogLevel.Warning);
            logger.Message("Customer Address details missing in Organization DataBase.", LogLevel.Error);
 
            // Handled by ConsoleLogger and EmailLogger
            logger.Message("Unable to Process Order ORD1 Dated D1 For Customer C1.", LogLevel.FunctionalError);
 
            // Handled by ConsoleLogger and EmailLogger
            logger.Message("Order Dispatched.", LogLevel.FunctionalMessage);
        }
    }
}
 
/* Output
Writing to console: Entering function ProcessOrder().
Writing to console: Order record retrieved.
Writing to console: Customer Address details missing in Branch DataBase.
Writing to Log File: Customer Address details missing in Branch DataBase.
Writing to console: Customer Address details missing in Organization DataBase.
Writing to Log File: Customer Address details missing in Organization DataBase.
Writing to console: Unable to Process Order ORD1 Dated D1 For Customer C1.
Sending via email: Unable to Process Order ORD1 Dated D1 For Customer C1.
Writing to console: Order Dispatched.
Sending via email: Order Dispatched.
*/

또 다른 예 Another Example

아래는 자바로 작성한 또 다른 예이다. 이 예에서 우리는 다른 역할들을 가지고 있다. 각각의 역할들은 정해진 구매 한계치(purchasing limit)와 하나의 후계자(successor)를 가진다.(여기에서 후계자는 앞에서 나왔던 chain이라고 생각하시면 됩니다. 책임을 전달한 객체를 의미하죠.) 역할을 담당해야하는 유저는 구매 요청을 받는데 이 구매 요청이 그의 한계를 초과하는 경우에, 요청은 그의 후계자로 전달된다.


processRequest 추상 메서드를 가지고 있는 PurchasePower 추상 클래스

abstract class PurchasePower {
    protected final double base = 500;
    protected PurchasePower successor;
 
    public void setSuccessor(PurchasePower successor) {
        this.successor = successor;
    }
 
    abstract public void processRequest(PurchaseRequest request);
}


위의 추상 클래스를 상속받는 4개의 구현들 : Manager, Director, Vice President, President

class ManagerPPower extends PurchasePower {
    private final double ALLOWABLE = 10 * base;
 
    public void processRequest(PurchaseRequest request) {
        if (request.getAmount() < ALLOWABLE) {
            System.out.println("Manager will approve $" + request.getAmount());
        } else if (successor != null) {
            successor.processRequest(request);
        }
    }
}
 
class DirectorPPower extends PurchasePower {
    private final double ALLOWABLE = 20 * base;
 
    public void processRequest(PurchaseRequest request) {
        if (request.getAmount() < ALLOWABLE) {
            System.out.println("Director will approve $" + request.getAmount());
        } else if (successor != null) {
            successor.processRequest(request);
        }
    }
}
 
class VicePresidentPPower extends PurchasePower {
    private final double ALLOWABLE = 40 * base;
 
    public void processRequest(PurchaseRequest request) {
        if (request.getAmount() < ALLOWABLE) {
            System.out.println("Vice President will approve $" + request.getAmount());
        } else if (successor != null) {
            successor.processRequest(request);
        }
    }
}
 
class PresidentPPower extends PurchasePower {
    private final double ALLOWABLE = 60 * base;
 
    public void processRequest(PurchaseRequest request) {
        if (request.getAmount() < ALLOWABLE) {
            System.out.println("President will approve $" + request.getAmount());
        } else {
            System.out.println( "Your request for $" + request.getAmount() + " needs a board meeting!");
        }
    }
}


아래의 코드는 이 예에서 요청 데이터를 유지하는 PurchaseRequest 클래스를 정의한다.

class PurchaseRequest {
    private int number;
    private double amount;
    private String purpose;
 
    public PurchaseRequest(int number, double amount, String purpose) {
        this.number = number;
        this.amount = amount;
        this.purpose = purpose;
    }
 
    public double getAmount() {
        return amount;
    }
    public void setAmount(double amt)  {
        amount = amt;
    }
 
    public String getPurpose() {
        return purpose;
    }
    public void setPurpose(String reason) {
        purpose = reason;
    }
 
    public int getNumber(){
        return number;
    }
    public void setNumber(int num) {
        number = num;
    }   
}


아래의 사용 예에서 후계자들(successors)은 뒤에 나오는 순서대로이다. : Manager->Director->Vice President->President

class CheckAuthority {
    public static void main(String[] args) {
        ManagerPPower manager = new ManagerPPower();
        DirectorPPower director = new DirectorPPower();
        VicePresidentPPower vp = new VicePresidentPPower();
        PresidentPPower president = new PresidentPPower();
        manager.setSuccessor(director);
        director.setSuccessor(vp);
        vp.setSuccessor(president);
 
        // Press Ctrl+C to end.
        try {
            while (true) {
                System.out.println("Enter the amount to check who should approve your expenditure.");
                System.out.print(">");
                double d = Double.parseDouble(new BufferedReader(new InputStreamReader(System.in)).readLine());
                manager.processRequest(new PurchaseRequest(0, d, "General"));
           }
        } catch(Exception e) {
            System.exit(1);
        }  
    }
}


'Design Patterns > 영문 위키(Wikipedia)' 카테고리의 다른 글

Interpreter pattern  (0) 2012.06.15
Command Pattern  (0) 2012.06.15
Chain-of-responsibility pattern  (0) 2012.06.08
Proxy pattern (프록시 패턴)  (0) 2012.06.06
Flyweight pattern (플라이웨이트 패턴)  (0) 2012.06.05
Facade pattern (퍼사드 패턴)  (0) 2012.06.04
Posted by Code-Moon

댓글을 달아 주세요

먼저 이 글은 영문 위키의 글을 번역한 글임을 알려드립니다.

영어 실력이 부족한 관계로 오역이 있을 수 있습니다.

원문 주소 : http://en.wikipedia.org/wiki/Proxy_pattern



구조적 패턴 - 프록시 패턴



컴퓨터 프로그래밍(computer programming)에서 프록시 패턴은 소프트웨어 디자인 패턴(software design pattern) 중 하나이다. 


가장 일반적인 형태의 프록시는 뭔가 다른 것의 인터페이스로 동작하는 클래스의 형태이다. 프록시는 어떤 인터페이스든지 가능하다. : 네트웍 연결, 메모리의 큰 객체, 파일, 또는 비용이 많이 들거나 복제하기 거의 불가능한 자원.


프록시 패턴의 잘 알려진 예는 참조 카운팅 포인터(reference counting pointer)객체이다. 


복잡한 객체를 여러개 복사해야하는 상황이 있다면, 프록시 패턴은 애플리케이션의 메모리 공간을 줄이기 위해 flyweight pattern에 맞춰질 수도 있다. 일반적으로 복잡한 객체 하나와 여러개의 프록시 객체들이 만들어지면, 이들 모두는 하나의 원본 복합 객체에 대한 참조를 포함한다 .프록시에서 수행되는 어떠한 동작(operations)들도 원본 객체로 연결되어진다.(forwared.. 포워드한다는 말인데, 원본 객체에게 위임한다는 표현이 더 어울릴 수도 있겠네요.) 일단 프록시의 모든 객체들이 영역 밖이라면, 복합 객체의 메모리는 해제될지도 모른다.




예 Example

아래의 자바 예는 가상 프록시(virtual proxy) 패턴을 보여주고 있다. ProxyImage 클래스는 원격 메서드에 접근하기 위해서 사용된다.

interface Image {
    void displayImage();
}
 
// on System A 
class RealImage implements Image {
    private String filename;
 
    public RealImage(String filename) { 
        this.filename = filename;
        loadImageFromDisk();
    }
 
    private void loadImageFromDisk() {
        System.out.println("Loading   " + filename);
    }
 
    public void displayImage() { 
        System.out.println("Displaying " + filename); 
    }
 
}
 
//on System B 
class ProxyImage implements Image {
    private String filename;
    private RealImage image;
 
    public ProxyImage(String filename) { 
        this.filename = filename; 
    }
 
    public void displayImage() {
        if (image == null) {
           image = new RealImage(filename);
        } 
        image.displayImage();
    }
}
 
class ProxyExample  {
    public static void main(String[] args) {
        Image image1 = new ProxyImage("HiRes_10MB_Photo1");
        Image image2 = new ProxyImage("HiRes_10MB_Photo2");     
 
        image1.displayImage(); // loading necessary
        image1.displayImage(); // loading unnecessary
        image2.displayImage(); // loading necessary
        image2.displayImage(); // loading unnecessary
        image1.displayImage(); // loading unnecessary
    }
}

프로그램의 결과는 아래와 같다.

Loading   HiRes_10MB_Photo1
Displaying HiRes_10MB_Photo1
Displaying HiRes_10MB_Photo1
Loading   HiRes_10MB_Photo2
Displaying HiRes_10MB_Photo2
Displaying HiRes_10MB_Photo2
Displaying HiRes_10MB_Photo1


Posted by Code-Moon

댓글을 달아 주세요

먼저 이 글은 영문 위키의 글을 번역한 글임을 알려드립니다.

영어 실력이 부족한 관계로 오역이 있을 수도 있습니다.

원문 주소 : http://en.wikipedia.org/wiki/Flyweight_pattern



구조적 패턴 - 플라이웨이트 패턴



컴퓨터 프로그래밍에서 플라이웨이트는 소프트웨어 디자인 패턴 중 하나이다. 플라이웨이트는 가능한 많은 데이터는 다른 유사한 객체들과 공유함으로써 메모리 사용을 최소화하는 객체이다. ; 이는 어떤 단순 반복되는 표현(representation)이 받아들일 수 없을 정도의 메모리를 사용할 때 객체를 수없이 많이 사용하는 방법이다. 종종 객체 상태의 일부분은 공유될 수 있고, 이를 외부 자료구조(data structures)에 두고, 사용될 때에 플라이웨이트 객체에 전달하는 방법이 일반적이다.




플라이웨이트 패턴의 고전적인 사용예는 워드 프로세서(word processor)에서 문자들의 그래픽적 표현에 대한 자료구조이다. 한 문서, 폰트의 외곽선을 포함하는 글자모양(glyph) 객체(그냥 글자의 모양을 표현하는 외곽선이라 생각하면 쉬울 듯 합니다. ), 폰트 매트릭스, 그리고 다른 포맷 데이터 각각에 각 문자들을 가지고 있는 것이 바람직할지도 모르지만, 이렇게 하면 한 문자당 수백 또는 수천 바이트가 필요할지도 모른다. 대신에, 모든 문자들이 그 문서 안의 같은 문자 객체에 의해 공유되는 플라이웨이트 글자모양 객체에 대한 레퍼런스(reference)가 될 수 있다.; 오직 각 문자의 위치정보만이 내부적으로 저장될 필요가 있을 것이다.


다른 문맥에서 동일한 자료 구조를 공유하는 아이디어는 hash consing이라 불린다.

역사 History

Designe Patterns: Elements of Reusable Object-Oriented Software 책에 따르면, 플라이웨이트 패턴은 1990년에 Paul Calder와 Mark Linton이 WYSIWYG 문서 편집기의 글자모양 정보를 효율적으로 다루기 위해 처음 도입되고 널리 연구되어졌다. 비록 비슷한 기술이 다른 시스템에서 이미 사용되고 있었지만 말이다.(1988년에 Weinand 등의 한 애플리케이션 프레임웍에서..)

자바 예 Example in Java

Posted by Code-Moon

댓글을 달아 주세요

먼저 이 글은 영문 위키의 글을 번역한 글임을 알려드립니다.

영어 실력이 부족한 관계로 오역이 있을 수도 있습니다.

원문 주소 : http://en.wikipedia.org/wiki/Facade_pattern



구조적 패턴 - 퍼사드 패턴



퍼사드 패턴은 객체 지향 프로그래밍에서 종종 사용되는 소프트웨어 디자인 패턴이다. 그 이름은 건축학의 퍼사드(전면, facade)에서 유추되었다. 

퍼사드는 많은 양의 코드를 단순화된 인터페이스로 제공하는 객체이다. (예를들면 클래스 라이브러리가 있다.)

퍼사드는 다음과 같은 것들을 할 수 있다. 

  • 퍼사드는 공통적인 작업(tasks)에 대해 편리한 메서드를 가지기 때문에, 더 사용하기 쉽고, 이해하기 쉽고, 테스트하기 쉽게 소프트웨어 라이브러리를 만들 수 있다. 
  • 같은 이유로 라이브러리를 더 읽기 쉽게 만들 수 있다.
  • 대부분의 코드가 퍼사드를 사용하기 때문에, 바깥 코드와 라이브러리 안쪽 코드의 의존성(dependency)을 줄일 수 있고, 따라서 시스템을 개발하는데에 더 유연성을 제공한다.
  • 형편없이 설계된 API의 컬렉션을 하나의 잘 설계된 API로 감쌀 수 있다.


감싸는 클래스(wrapper)가 특정 인터페이스를 준수해야하고 다형성(polymorphic)을 지원해야만 한다면 어댑터(adapter)가 사용된다. 반면에, 퍼사드는 더 쉽거나 간단한 인터페이스를 원할 때 사용한다.

구조 Structure


Facde - 퍼사드 클래스는 Package 1, 2, 3을 나머지 애플리케이션으로부터 추상화시킨다.

Clients - Package들의 리소스에 접근하기 위해 퍼사드 패턴을 사용하는 객체

예 Example

이 추상적인 예는 복잡한 시스템에서(CPU와 하드 드라이브 같은 컴퓨터 내부) 클라이언트(당신)가 어떻게 퍼사드(컴퓨터)와 상호작용하는지 보여준다.

/* Complex parts */
 
class CPU {
    public void freeze() { ... }
    public void jump(long position) { ... }
    public void execute() { ... }
}
 
class Memory {
    public void load(long position, byte[] data) { ... }
}
 
class HardDrive {
    public byte[] read(long lba, int size) { ... }
}
 
/* Facade */
 
class Computer {
    private CPU cpu;
    private Memory memory;
    private HardDrive hardDrive;
 
    public Computer() {
        this.cpu = new CPU();
        this.memory = new Memory();
        this.hardDrive = new HardDrive();
    }
 
    public void startComputer() {
        cpu.freeze();
        memory.load(BOOT_ADDRESS, hardDrive.read(BOOT_SECTOR, SECTOR_SIZE));
        cpu.jump(BOOT_ADDRESS);
        cpu.execute();
    }
}
 
/* Client */
 
class You {
    public static void main(String[] args) {
        Computer facade = new Computer();
        facade.startComputer();
    }
}


Posted by Code-Moon

댓글을 달아 주세요

먼저 이글은 영문 위키의 글을 번역한 글임을 알려드립니다.
영어 실력이 부족한 관계로 오역이 있을 수도 있습니다.


구조적 패턴 - 데코레이터 패턴




객체 지향 프로그래밍에서 데코레이터 패턴은 이미 존재하는 객체에 동적으로 행위(동작, behaviour)를 추가할 수 있도록 하는 디자인 패턴이다.

도입 Introduction

데코레이터 패턴은 런타임에 특정 객체의 기능을 확장하는데 사용될 수 있는데, 이 때 같은 클래스의 다른 객체에는 무관하게 기능을 확장할 수 있고,  이는 기초작업이 설계할 때 이미 완료되었을 때 가능한 일이다. 이는 원래(original) 클래스를 감싸는 새로운 데코레이터 클래스를 설계함으로써 얻을 수 있는 성과이다. 이렇게 데코레이터로 감싸는 것은 아래의 순서에 따라 하게 된다.

  1. 원래의(original) "Decorator"클래스를 "Component"클래스로부터 서브 클래싱한다.(뒤에 나오는 UML 다이어그램을 보라.)
  2. Decorator 클래스에서 Component에 대한 포인터를 필드(멤버 변수)로 추가해라.
  3. Component를 Decorator의 생성자에 인자로 전달해서, Decorator클래스에서 Component 포인터를 초기화할 수 있도록 하라.
  4. Decorator클래스에서 모든 "Component" 메서드를 "Component" 포인터로 재전송하라(redirect. 이 말을 다시 설명하자면, Component 클래스에 있는 operation()이라는 메서드를 Decorator에서 오버라이드를 하게 되는데, 이 때 Decorator에서 포인터로 가지고 있는 Component객체의 operation()을 다시 호출하라는 의미입니다. )
  5. ConcreteDecorator 클래스에서 Component 클래스의 수정이 필요한 메서드를 오버라이드 하라.


이 패턴은  매번 오버라이드된 메서드에 새로운 기능이 추가될 때마다(새로운 데코레이터로 감쌀때마다), 여러개의 데코레이터들이 스택처럼 쌓일 수 있게 설계한다.

데코레이터 패턴은 서브 클래싱의 대안이다. 서브 클래싱은 컴파일할 때 행동을 추가하게 되고, 그때 클래스의 변화는 모든 원래의(original) 클래스의 객체에 대해 변화를 일으킨다. ; 꾸미는 것(decorating)은 런타임에 각각의 객체에 새로운 행위를 제공할 수 있다. 


이러한 차이는 기능을 확장하는 몇몇 독립적인 방법들이 있을 때 아주 중요하게 다가온다. 일부 객체 지향 프로그래밍 언어에서는 클래스가 런타임에 생성될 수 없고, 전형적으로(보통, typically) 이는 설계할 때에 어떤 확장의 조합이 필요한지 예측할 수 없게된다. 이는 새로운 클래스는 모든 가능한 조합에 대해 만들어져야 함을 의미할지도 모른다. 대조적으로 데코레이터는 런타임에 만들어지는 객체라서 사용할 때마다 조합될 수 있다. 자바와 .NET 프레임웍의 I/O Streams 구현은 데코레이터 패턴을 포함하고 있다.

동기 Motivation

한 예로써, 윈도우 시스템의 윈도우를 생각해보자. 윈도우의 컨텐츠를 스크롤할 수 있도록 하기 위해, 우리는 수평 스크롤바나 수직 스크롤바를 추가하고 싶을 수도 있다. 윈도우가 Window클래스의 객체에 의해 표현된다고 가정하고, 이 클래스는 스크롤바를 추가하는 기능이 없다고 가정하자. 우리는 스크롤 기능을 제공하는 ScrollingWindow를 Window로 부터 서브클래싱하여 만들거나, 이미 존재하는 Window객체에 스크롤 기능을 추가하는 ScrollingWindowDecorator를 만들 수 있다. 이 상황에서는 둘 중 어떤 해결책도 괜찮다.


그렇다면 이번에는 우리의 윈도우에 경계선(borders)을 추가하고 싶다고 가정해보자. 마찬가지로 원래의 Window클래스는 이러한 기능을 지원하지 않는다. ScrollingWindow 서브클래스는 효과적으로 새로운 윈도우를 만들었기 때문에 한가지 문제가 생겼다. 

만약 우리가 모든 윈도우에 경계선을 추가하고 싶다면 WindowWithBorder라는 서브클래스와 ScrollingWindowWithBorder라는 서브클래스를 만들면 된다. 확실히 이런 문제는 모든 새로운 기능이 추가될 때마다 더 문제가 된다. 

데코레이터 방법으로는 런타임에 간단히 BorderWindowDecorator를 만들면 된다. 우리는 이미 존재하는 윈도우를 ScrollingWindowDecorator나 BorderedWindowDecorator로 꾸밀 수 있다.


데코레이터가 사용되면 좋은 또다른 상황은 어떤 규칙에 따라 객체의 속성이나 메서드에 대한 접근을 한정지어야 할 필요가 있을 때 이다. (예를들면 다른 사용자 자격인증서.) 이러한 경우에 원래의 객체에 접근 제어를 구현하는 것보다는 원래 객체는 변화시키지 않고 속성이나 메서드 사용에 대해 아무것도 모르도록하고, 접근 제어를 할 수 있는 데코레이터 객체로 감싸면 오직 승인된 인터페이스만 제공하도록 할 수 있다.

구조 Structure


예 Examples

자바

첫번째 예 (window / scrolling 시나리오)

아래의 자바 예는 window/scrolling 시나리오에서 데코레이터의 사용을 설명하고 있다.

// the Window interface
interface Window {
    public void draw(); // draws the Window
    public String getDescription(); // returns a description of the Window
}
 
// implementation of a simple Window without any scrollbars
class SimpleWindow implements Window {
    public void draw() {
        // draw window
    }
 
    public String getDescription() {
        return "simple window";
    }
}


아래의 클래스는 모든 Window클래스(데코레이터 자신들을 포함한)에 대한 데코레이터들이다.

// abstract decorator class - note that it implements Window
abstract class WindowDecorator implements Window {
    protected Window decoratedWindow; // the Window being decorated
 
    public WindowDecorator (Window decoratedWindow) {
        this.decoratedWindow = decoratedWindow;
    }
    public void draw() {
        decoratedWindow.draw();
    }
}
 
// the first concrete decorator which adds vertical scrollbar functionality
class VerticalScrollBarDecorator extends WindowDecorator {
    public VerticalScrollBarDecorator (Window decoratedWindow) {
        super(decoratedWindow);
    }
 
    public void draw() {
        decoratedWindow.draw();
        drawVerticalScrollBar();
    }
 
    private void drawVerticalScrollBar() {
        // draw the vertical scrollbar
    }
 
    public String getDescription() {
        return decoratedWindow.getDescription() + ", including vertical scrollbars";
    }
}
 
// the second concrete decorator which adds horizontal scrollbar functionality
class HorizontalScrollBarDecorator extends WindowDecorator {
    public HorizontalScrollBarDecorator (Window decoratedWindow) {
        super(decoratedWindow);
    }
 
    public void draw() {
        decoratedWindow.draw();
        drawHorizontalScrollBar();
    }
 
    private void drawHorizontalScrollBar() {
        // draw the horizontal scrollbar
    }
 
    public String getDescription() {
        return decoratedWindow.getDescription() + ", including horizontal scrollbars";
    }
}

여기 아래에는 완전히 꾸며진(fully decorated) Window객체를 생성하는 테스트 프로그램이고, 실행해보면 설명을 출력한다.

public class DecoratedWindowTest {
    public static void main(String[] args) {
        // create a decorated Window with horizontal and vertical scrollbars
        Window decoratedWindow = new HorizontalScrollBarDecorator (
                new VerticalScrollBarDecorator(new SimpleWindow()));
 
        // print the Window's description
        System.out.println(decoratedWindow.getDescription());
    }
}

이 프로그램의 결과는 "simple window, including vertical scrollbars, including horizontal scrollbars"라고 나올 것이다. 두 데코레이터의 getDescription 메서드에서 어떻게 처음에 꾸며진(decorated) Window의 설명(description)을 가져오고 그 뒤에 꾸미는 작업(decorates)을 하게되는지 유심히 살펴보아라.




두번째 예(커피 만드는 시나리오)

다음의 자바 예는 커피를 만드는 시나리오에서 데코레이터를 사용하는 방법을 설명하고 있다. 이 예에서 시나리오는 가격과 재료만 포함하고 있다.

// The Coffee Interface defines the functionality of Coffee implemented by decorator
public interface Coffee {
    public double getCost(); // returns the cost of the coffee
    public String getIngredients(); // returns the ingredients of the coffee
}
 
// implementation of a simple coffee without any extra ingredients
public class SimpleCoffee implements Coffee {
    public double getCost() {
        return 1;
    }
 
    public String getIngredients() {
        return "Coffee";
    }
}

다음의 클래스들에는 모든 커피 클래스가 포함되어 있다.(데코레이터 자신도 포함해서 말이다.)

// abstract decorator class - note that it implements Coffee interface
abstract public class CoffeeDecorator implements Coffee {
    protected final Coffee decoratedCoffee;
    protected String ingredientSeparator = ", ";
 
    public CoffeeDecorator(Coffee decoratedCoffee) {
        this.decoratedCoffee = decoratedCoffee;
    }
 
    public double getCost() { // implementing methods of the interface
        return decoratedCoffee.getCost();
    }
 
    public String getIngredients() {
        return decoratedCoffee.getIngredients();
    }
}
 
// Decorator Milk that mixes milk with coffee
// note it extends CoffeeDecorator
public class Milk extends CoffeeDecorator {
    public Milk(Coffee decoratedCoffee) {
        super(decoratedCoffee);
    }
 
    public double getCost() { // overriding methods defined in the abstract superclass
        return super.getCost() + 0.5;
    }
 
    public String getIngredients() {
        return super.getIngredients() + ingredientSeparator + "Milk";
    }
}
 
// Decorator Whip that mixes whip with coffee
// note it extends CoffeeDecorator
public class Whip extends CoffeeDecorator {
    public Whip(Coffee decoratedCoffee) {
        super(decoratedCoffee);
    }
 
    public double getCost() {
        return super.getCost() + 0.7;
    }
 
    public String getIngredients() {
        return super.getIngredients() + ingredientSeparator + "Whip";
    }
}
 
// Decorator Sprinkles that mixes sprinkles with coffee
// note it extends CoffeeDecorator
public class Sprinkles extends CoffeeDecorator {
    public Sprinkles(Coffee decoratedCoffee) {
        super(decoratedCoffee);
    }
 
    public double getCost() {
        return super.getCost() + 0.2;
    }
 
    public String getIngredients() {
        return super.getIngredients() + ingredientSeparator + "Sprinkles";
    }
}

아래에는 완전히 꾸며진(fully decorated) Coffee의 객체를 생성하는 테스트 프로그램이고, 여기에서는 커피의 가격을 계산하고 재료를 출력한다.

public class Main
{
    public static void main(String[] args)
    {
        Coffee c = new SimpleCoffee();
        System.out.println("Cost: " + c.getCost() + "; Ingredients: " + c.getIngredients());
 
        c = new Milk(c);
        System.out.println("Cost: " + c.getCost() + "; Ingredients: " + c.getIngredients());
 
        c = new Sprinkles(c);
        System.out.println("Cost: " + c.getCost() + "; Ingredients: " + c.getIngredients());
 
        c = new Whip(c);
        System.out.println("Cost: " + c.getCost() + "; Ingredients: " + c.getIngredients());
 
        // Note that you can also stack more than one decorator of the same type
        c = new Sprinkles(c);
        System.out.println("Cost: " + c.getCost() + "; Ingredients: " + c.getIngredients());
    }
}

이 프로그램의 출력 결과는 다음과 같다.

Cost: 1.0; Ingredients: Coffee
Cost: 1.5; Ingredients: Coffee, Milk
Cost: 1.7; Ingredients: Coffee, Milk, Sprinkles
Cost: 2.4; Ingredients: Coffee, Milk, Sprinkles, Whip
Cost: 2.6; Ingredients: Coffee, Milk, Sprinkles, Whip, Sprinkles



동적인 언어들(Dynamic languages)

데코레이터 패턴은 동적인 언어들에서도 사용될 수 있는데, 이때에는 인터페이스와 전통적인 OOP 상속을 사용하지 않고 쓴다.

자바스크립트(커피 만드는 시나리오)

// Class to be decorated
function Coffee() {
 
}
 
Coffee.prototype.cost = function() {
        return 1;
};
 
// Decorator A
function Milk(coffee) {
        var currentCost = coffee.cost();
        coffee.cost = function() {
                return currentCost + 0.5;
        };
 
        return coffee;
}
 
// Decorator B
function Whip(coffee) {
        var currentCost = coffee.cost();
        coffee.cost = function() {
                return currentCost + 0.7;
        };
 
        return coffee;
}
 
// Decorator C
function Sprinkles(coffee) {
        var currentCost = coffee.cost();
        coffee.cost = function() {
                return currentCost + 0.2;
        };
 
        return coffee;
}
 
// Here's one way of using it
var coffee = new Milk(new Whip(new Sprinkles(new Coffee())));
alert( coffee.cost() );
 
// Here's another
var coffee = new Coffee();
coffee = new Sprinkles(coffee);
coffee = new Whip(coffee);
coffee = new Milk(coffee);
alert(coffee.cost());


Posted by Code-Moon

댓글을 달아 주세요

먼저 이 글은 영문위키의 글을 번역한 글임을 알려드립니다.

영어 실력이 부족한 관계로 오역이 있을 수도 있습니다.

원문 주소 : http://en.wikipedia.org/wiki/Composite_pattern



구조적 패턴 - 콤포짓 패턴



소프트웨어 공학에서 콤포짓 패턴은 분할하는(partitioning) 디자인 패턴이다. (왜 partitioning이라는 단어가 나왔는지 잘 이해가 안되네요.;;) 콤포짓 패턴은 객체 그룹이 단일 객체와 같이 취급되도록 한다. 컴포짓의 목적(의도, intent)은 객체들을 트리(tree) 구조로 "구성(compose)"하여 부분-전체 구조(part-whole hierarchies)를 표현하기 위함이다. 콤포짓 패턴을 구현하는 것은 단일 객체(individual objects)와 구성(composition, 여기에서는 그룹 정도로 이해해도 괜찮을 것 같네요.)을 동일하게 취급하도록 해준다.

동기 Motivation

트리 구조의 데이터를 다룰 때, 프로그래머는 종종 리프노드(leaf-node)와 브랜치(branch)를 구분해야만 한다. 이는 코드를 더욱 복잡하게 만들고 따라서 에러가 발생하기도 쉽다. 해결책은 복합객체(complex)와 원시객체(primitive)를 동일하게 다루는 인터페이스를 사용하는 것이다. 객체 지향 프로그래밍에서 컴포짓은 하나 이상의 비슷한 객체들을 가지고 하나의 구성(composition)으로 설계된 객체이다. 이는 객체 사이의 "has-a"관계로 알려져있다. 중요한 컨셉은 객체의 한 인스턴스를 다룰 때, 그 객체들의 그룹을 다루는 것처럼 다룰 수 있다는 것이다. 모든 컴포짓 객체들에서 당신이 수행할 수 있는 동작들(operations)은 종종 최소 공통 분모(least common denominator) 관계에 있다. 예를 들어, 그룹핑된(grouped) 도형(shapes)들을 화면에 그리는 시스템을 정의한다고 하면, 도형들의 그룹을 리사이징(resizing)하는 것이 하나의 도형을 리사이징하는 것과 같은 효과를 가지도록 정의하는 것이 유용할 것이다. 

언제사용하는가? When to use

컴포짓은 클라이언트 프로그램이 객체들의 구성(composition)과 개개의 객체 사이에 차이점을 무시해야할 때 사용될 수 있다. 만약 프로그래머가 여러개의 객체들을 같은 방법으로 사용하거나, 종종 그 객체 각각을 다루기 위해 거의 비슷한 코드를 사용하고 있는 자신의 모습을 발견한다면, 컴포짓이 좋은 선택이 될 수 있다. ; 이러한 상황에서 원시(primitive)객체와 구성 객체를 동일하게 다루는 것이 덜 복잡하다. 

구조 Structure

Component

  • 컴포넌트 자신을 포함한 모든 컴포넌트에 대한 추상화이다.
  • 구성(composition)에 있는 객체들의 인터페이스를 정의한다.
  • (선택적으로) component의 부모에 대한 접근하기 위한 재귀적인 구조(recursive structure)의 인터페이스를 정의하고, 적절하다면 구현한다.

Leaf

  • 구성(composition)에 있는 leaf 객체들을 표현한다.
  • component의 모든 메서드를 구현한다.

Composite

  • composite 컴포넌트를 표현한다.(자식들을 가지는 컴포넌트)
  • 자식들을 다루기 위한 메서드를 구현한다.
  • 모든 component 메서드를 구현한다.(일반적으로 메서드 기능을 자식에게 위임해서 구현한다. 여기에서 위임이라함은 자식의 기능을 호출한다고 보면 될 것 같네요.)

변형 Variation

Design Patterns에 묘사되어 있듯이,  이 패턴에는 Composite 클래스 뿐만 아니라 메인 Component 인터페이스에도 자식을 관리하는 메서드를 포함하고 있다. 더 최근의 몇몇 설명에서는 이러한 메서드를 누락시키고 있다. 

예 Example

자바로 작성된 다음의 예제는 Graphic 클래스를 구현하는데, 이 클래스는 Ellipse(타원)이나 다른 몇몇 그래픽의 구성(composition)이 될 수 있다. 모든 그래픽은 출력될 수 있다.


수학적으로 표현하면 다음과 같다.

Graphic = ellipse | GraphicList
GraphicList = empty | Graphic GraphicList


이는 직사각형과 같은 다른 도형들과 translate와 같은 다른 메서드들을 구현하게 끔 확장될 수도 있다.


Posted by Code-Moon

댓글을 달아 주세요

먼저 이 글은 영문 위키의 글을 번역한 것임을 알려드립니다.

영어 실력이 부족한 관계로 오역이 있을 수도 있습니다.

원문 주소 : http://en.wikipedia.org/wiki/Bridge_pattern



구조적 패턴 - 브릿지 패턴




브릿지 패턴은 소프트웨어 공학에서 사용되는 디자인 패턴인데, 이는 "구현(implementation)으로부터 추상(abstraction) 레이어를 분리하여 이 둘이 서로 독립적으로 변화할 수 있도록 한다."

브릿지는 캡슐화(encapsulation), 집합(aggregation)을 사용하고 또한 다른 클래스들로 책임을 분리시키기 위해 상속(inheritance)를 사용할 수 있다. 


어떤 클래스가 자주 바뀐다면(varies), 객체 지향 프로그래밍의 특징들은 아주 유용해질 수 있다. 왜냐하면 프로그램 코드를 수정하는데 프로그램에 대해 최소한만 알고도 쉽게 수정할 수 있기 때문이다. 브릿지 패턴은 어떤 클래스와 그 클래스가 하는 일이 자주 변화할 때 유용하게 사용될 수 있다. 여기에서 어떤 클래스는 구현(implementation)이라 생각할 수 있고, 그 클래스가 할 수 있는 일은 추상(abstraction)으로 생각할 수 있다. 브릿지 패턴은 추상화(abstraction)의 두 계층(layer)로 생각할 수도 있다.


브릿지 패턴은 종종 어댑터 패턴과 혼동될 수 있다. 사실, 브릿지 패턴은 종종 클래스 어댑터 패턴을 사용해서 구현되기도 한다. 아래에 나오는 자바 코드가 그 예가 될 것이다.


변종(Variant) : 추상(abstraction)이 사용되는 시점까지 구현의 존재를 미룸으로써 구현을 더욱 갈라놓을 수 있다.(정확히 이해는 안되지만 구현 객체를 최대한 늦게 생성함으로써 구현과 추상의 관계를 더욱 약하게 할 수 있다는 말인것 같네요;

원문 : The implementation can be decoupled even more by deferring the presence of the implementation to the point where the abstraction is utilized.)

구조 Structure

Abstraction - 추상 인터페이스를 정의한다. Implementor에 대한 레퍼런스를 유지한다.

RefinedAbstraction - Abstraction에 의해 정의된 인터페이스를 확장한다.(extends)

Implementor - 구현 클래스를 위한 인터페이스를 정의한다.

ConcreteImplementor - Implementor 인터페이스를 구현한다. 

예 Example

아래의 자바 프로그램은 'shape'를 이용한 예이다. 


/** "Implementor" */
interface DrawingAPI {
    public void drawCircle(double x, double y, double radius);
}
 
/** "ConcreteImplementor"  1/2 */
class DrawingAPI1 implements DrawingAPI {
   public void drawCircle(double x, double y, double radius) {
        System.out.printf("API1.circle at %f:%f radius %f\n", x, y, radius);
   }
}
 
/** "ConcreteImplementor" 2/2 */
class DrawingAPI2 implements DrawingAPI {
   public void drawCircle(double x, double y, double radius) {
        System.out.printf("API2.circle at %f:%f radius %f\n", x, y, radius);
   }
}
 
/** "Abstraction" */
abstract class Shape {
   protected DrawingAPI drawingAPI;
 
   protected Shape(DrawingAPI drawingAPI){
      this.drawingAPI = drawingAPI;
   }
 
   public abstract void draw();                             // low-level
   public abstract void resizeByPercentage(double pct);     // high-level
}
 
/** "Refined Abstraction" */
class CircleShape extends Shape {
   private double x, y, radius;
   public CircleShape(double x, double y, double radius, DrawingAPI drawingAPI) {
      super(drawingAPI);
      this.x = x;  this.y = y;  this.radius = radius;
   }
 
   // low-level i.e. Implementation specific
   public void draw() {
        drawingAPI.drawCircle(x, y, radius);
   }
   // high-level i.e. Abstraction specific
   public void resizeByPercentage(double pct) {
        radius *= pct;
   }
}
 
/** "Client" */
class BridgePattern {
   public static void main(String[] args) {
       Shape[] shapes = new Shape[] {
           new CircleShape(1, 2, 3, new DrawingAPI1()),
           new CircleShape(5, 7, 11, new DrawingAPI2()),
       };
 
       for (Shape shape : shapes) {
           shape.resizeByPercentage(2.5);
           shape.draw();
       }
   }
}



Posted by Code-Moon

댓글을 달아 주세요

먼저 이 글은 영문 위키의 글을 번역한 글임을 알려드립니다.

영어 실력이 부족한 관계로 오역이 있을 수 있습니다.^^;

원문 주소 : http://en.wikipedia.org/wiki/Adapter_pattern



구조 패턴 - 어댑터(Apapter)



컴퓨터 프로그래밍에서 어댑터 패턴은(종종 wrapper pattern이라고 언급되기도 하고, 더 간단히 wrapper라고 불리기도 한다.) 한 클래스의 인터페이스를 호환 가능한 다른 인터페이스로 변환시키는 디자인 패턴이다. 

호환되지 않는 인터페이스때문에 일반적인 방법으로는 같이 사용할 수 없는 클래스들을 어댑터 패턴을 이용하면 같이 사용할 수 있다. 이는 클라이언트 코드에게 원래 클래스의 인터페이스를 노출시키는 대신에 어댑터의 인터페이스를 노출시킴으로써 가능해진다. 

어댑터는 어댑터 인터페이스에 대한 호출을 원래 클래스의 인터페이스 호출로 변환하고, 이를 위해 필요한 코드 량은 일반적으로 작다. 어댑터는 또한 데이터를 적절한 형태로 변환하는 역할도 한다. 

예를 들어, 여러개의 불(boolean) 값이 하나의 정수에 들어있는데(예를들면 flag같은 경우), 당신의 클라이언트 코드에서는 하나의 'true'나 'false' 값만 필요하다면 어댑터는 이 정수에서 적절한 값을 추출해내는 역할을 할 수 있다. 

다른 예는 날짜의 형태를 변경하는 것이다.(예를들면 YYYYMMDD를  MM/DD/YYYY 형태로 만들거나 DD/MM/YYYY 같은 형태로 만들 수 있다.)




구조 Structure

어댑터 패턴에는 두가지 종류가 있다. 

객체 어댑터 패턴 Object Adapter Pattern

이 타입의 어댑터 패턴에서 어댑터는 감싸야할 클래스의 객체를 포함하고 있다. 이러한 상황에서 어댑터는 감싸진 객체를 호출하는 일을 한다.






클래스 어댑터 패턴 Class Adapter Pattern

이 타입의 어댑터는 목표를 달성하기 위해 여러개의 다형성 인터페이스(polymorphic interfaces)를 사용한다. 어댑터는 구현될 예정인 인터페이스나 이미 구현된 인터페이스를 상속받아서 만들어진다. 구현될 예정인 인터페이스는 순수(pure) 인터페이스 클래스로 만들어지는 것이 일반적인데, 특히 자바같이 다중 상속(multiple inheritance)을 지원하지 않는 언어들에서 그러하다.




어댑터 패턴은 이미 존재하는 클래스가 당신이 필요로하는 일부 또는 전체 서비스를 제공하지만 당신에게 필요한 인터페이스는 제공하지 않는 상황에 유용할 수 있다. 어댑터의 좋은 실제 예는 XML 문서의 DOM(Document Object Model)의 인터페이스를 볼 수 있는  트리 구조로 바꾸는 것이다. 어댑터 디자인 패턴을 사용하는 튜토리얼 링크는 아래에 나열해 놓았다. 



더 발전된 형태의 실시간 어댑터 패턴(?) A further form of runtime Adapter Pattern

아래에 나오는 것과 같이 더 발전된 형태의 실시간으로 사용될 수 있는 어댑터 패턴이 있다 : 

classA가 약간의 데이터를 가지고(String데이터라 가정하고) classB를 지원하도록 요구되어진다. 컴파일 시의 해결책은 다음과 같다.



classB.setStringData(classA.getStringData());


string데이터의 포맷(형식)이 다양해져야 한다고 가정해보자. 컴파일 시의 해결책은 상속을 사용하는 것이다.:
Format1ClassA extends ClassA {
   public String getStringData() {
      return format(toString());
   }
}


그리고 팩토리 패턴의 도움으로 런타임시에 정확하게 표현할 형식(formatting) 객체를 만들 수 있다.



어댑터를 사용하는 방법의 진행 절차는 다음과 같다.:



(i) 중개하는 Provider 인터페이스를 정의하고, 데이터의 소스를 감싸는 Provider 인터페이스의 구현을 작성해라. 이 예에서는 ClassA가 데이터 소스가 되고, 적절한 형태를 갖춘 데이터를 만들어낸다.


public interface StringProvider {
    public String getStringData();
}
 
public class ClassAFormat1 implements StringProvider {
    ClassA classA;
 
    public ClassAFormat1(ClassA classA) {
        this.classA = classA;
    }
 
    public String getStringData() {
        return format(classA.toString());
    }
}



(ii) Provider의 특정 구현을 반환하는 Adapter클래스를 작성한다.
public class ClassAFormat1Adapter extends Adapter {
   public Object adapt(Object o) {
      return new ClassAFormat1((ClassA) o);
   }
}


(iii) Adatper를 전역 레지스트리에 등록해서 Adapter가 런타임 시에 사용될 수(can be loocked up) 있도록 한다.
AdapterFactory.getInstance().registerAdapter(ClassA.class, ClassAFormat1Adapter.class, "format1");



(iv) 당신의 코드에서 ClassA의 데이터를 ClassB로 옮기고 싶다면 다음과 같이 작성한다.


Adapter adapter = AdapterFactory.getInstance().getAdapterFromTo(ClassA.class, StringProvider.class, "format1");
StringProvider provider = (StringProvider) adapter.adapt(classA);
String string = provider.getStringData();
classB.setStringData(string);


또는 더 간결하게 하자면,

classB.setStringData(((StringProvider) AdapterFactory.getInstance().getAdapterFromTo(ClassA.class, StringProvider.class, "format1").adapt(classA)).getStringData());


(v) 만약 데이터를 두번째 형식으로 전송하고 싶다면 다른 Adapter와 Provider를 찾아서(look up) 쓸 수 있다는 것이 장점이라 볼 수 있다.


Adapter adapter = AdapterFactory.getInstance().getAdapterFromTo(ClassA.class, StringProvider.class, "format2");



(vi) 그리고 만약 ClassA로부터 ClassC의 이미지 데이터로 출력하고 싶다면 :
Adapter adapter = AdapterFactory.getInstance().getAdapterFromTo(ClassA.class, ImageProvider.class, "format1");
ImageProvider provider = (ImageProvider) adapter.adapt(classA);
classC.setImage(provider.getImage());



(vii) 이런 방법으로 Adapter와 Provider를 사용하는 것은 여러개의 뷰(views)를 제공할 수 있다. 일반적으로, 기존 객체 구조에 새로 장착할 수 있는 객체들 사이를 중개 데이터가 들어갈 수 있는 메카니즘을 허용한다.(그러니까 기존 객체 구조를 유지하고 어댑터를 이용한 메카니즘을 사용한다는 의미인 것 같은데,,, 해석하려니 말이 어렵네요-_-)




어댑터 패턴의 구현 Implementation of Adapter pattern

어댑터 패턴을 구현할 때, 명료성을 위해서 클래스 이름을 "[AdapteeClassName]To[Interface]Adapter"와 같은 식으로 만든다. 예를들면 DAOToProviderAdapter(여기에서 DAO가 AdapteeClassName에 해당하고, Provider가 Interface에 해당하겠죠?). 

이를 위해서는 adaptee클래스를 인자로 받는 생성자가 필요하다. 이 인자는 "[AdapteeClassName]To[Interface]Adapter"의 객체 멤버로 전달될 것이다.


Class SampleAdapter implements ClientClass
{
    private AdapteeClass mInstance;
    public SampleAdapter(AdapteeClass instance)
    {
         mInstance=instance;
    }
    @Override
    public void ClientClassMethod()
    {
       // call AdapteeClass's method to implement ClientClassMethod
    }
 
}


Posted by Code-Moon

댓글을 달아 주세요

먼저 이 글은 영문 위키의 글을 번역한 글임을 알려드립니다.

영어 실력이 부족한 관계로 오역이 있을 수도 있으니 이해해주세요^^;

원문 주소 : http://en.wikipedia.org/wiki/Singleton_pattern



생성 패턴 - 싱글톤



소프트웨어 공학에서 싱글톤 패턴은 클래스의 인스턴스화를 하나의 객체로 제한을 둠으로써 싱글톤의 수학적 컨셉(수학에 싱글톤이라는게 있나 보군요. 참고 : http://en.wikipedia.org/wiki/Singleton_(mathematics))을 구현한 디자인 패턴이다. 이 패턴은  시스템에 걸쳐 딱 하나의 객체가 필요할 때에 유용하다. 


이 컨셉은 다음과 같은 시스템에서 일반적으로 사용된다. 

1. 오직 하나의 객체가 존재하는 것이 더 효과적일 때

2. 일정 개수의 객체만 생성하도록 제한을 둬야할 때


싱글톤 패턴을 사용함에 있어서 비판적인 시각도 있는데, 일부에서는 싱글톤이 남용되고 있거나 굳이 하나의 유일한 객체가 필요한 상황이 아닌 곳에서도 불필요하게 도입될 수도 있고, 애플리케이션 안에서 전역 상태(global state)를 도입한다고 판단하기 때문에 안티패턴(자주 사용되기는 하나 효과적이지 못하거나 부작용이 낳는 패턴)으로 간주하기도한다. 


C++에서는 싱글톤이 프로그래머에게 제어를 넘김으로써, 동적 초기화의 순서에 대한 예측 불가능으로부터 분리시킬 수 있다. (정확히는 모르겠지만, 의미를 추측해보면 c++에서는 전역 변수를 사용할 때 어떤 변수가 먼저 초기화될지 순서를 예측하기 힘들 수 있는데, 싱글톤을 이용하면 명시적으로 그 초기화 순서를 정할 수 있다는 의미인 것 같습니다.)


일반적인 사용 Common Uses

  • 추상 팩토리, 빌더, 프로토타입 패턴을 구현할 때에 싱글톤을 사용할 수 있다.
  • 오직 하나의 퍼사드 객체만이 필요하기 때문에, 퍼사드(Facade) 객체는 종종 싱글톤이다.
  • 상태 객체(State Object, 스테이트 패턴 객체를 의미하는 듯 합니다.)는 종종 싱글톤이다.
  • 싱글톤은 종종 아래와 같은 이유때문에 전역 변수보다 선호된다.
    • 싱글톤은 불필요한 변수들로 전역 네임스페이스를 오염시키지 않는다. 
    • 많은 언어에서 전역 변수가 항상 자원(메모리)을 소비하는데에 비해, 싱글톤은 게으른 할당과 초기화를 지원한다.


구조 Structure


구현 Implementation

싱글톤 패턴의 구현은 하나의 인스턴스와 전역 접근 원칙을 만족해야만한다. 이는 클래스 객체를 생성하지 않고 싱글톤 클래스 멤버에 접근할 수 있는 메카니즘과 클래스 객체들 사이에서 클래스 멤버의 값을 유지하는 메커니즘을 필요로 한다. 싱글톤 패턴은 객체가 없을 때에 새로운 클래스 객체를 생성하는 메서드를 가지는 클래스를 만듦으로써 구현할 수 있다. 만약 객체가 이미 존재한다면 해당 메서드에서는 이미 생성된 객체에 대한 레퍼런스를 반환한다. 객체가 다른 방법으로 생성되지 않도록 하기 위해서 생성자는 private으로 한다. 


간단한 스태틱 객체와 싱글톤의 차이에 주목하라. : 싱글톤은 스태틱 객체로 구현되기는 하지만, 늦게 생성될 수 있고 필요하기 전까지는 메모리나 자원을 필요로하지 않는다. 또다른 주목할만한 차이점은 인터페이스가 단순히 마커(marker)가 아닐 경우에, 스태틱 멤버 클래스는 그 인터페이스를 구현할 수 없다는 점이다. 따라서 클래스가 어떤 인터페이스를 구현하기 위해서는 스태틱 멤버 클래스가 아닌 싱글톤으로 구현해야 한다. (두번째 차이는 이해가 잘 안되네요;; 스태틱 멤버 클래스도 사용하는 부분에서만 스태틱으로 선언해서 사용하는 것이지 정의 부분은 일반 클래스랑 다를게 없는데, 왜 인터페이스를 구현하는 것이 안된다는지....?)


싱글톤 패턴은 멀티 스레드 기반의 애플리케이션에서 조심스럽게 사용해야 한다. 만약 싱글톤 객체가 아직 생성되지 않은 시점에서 두개의 스레드가 동시에 싱글톤의 생성 메서드를 호출하면, 두 스레드에서 동시에 싱글톤 객체의 생성여부를 체크할 것이고 이때 단 하나의 객체만 생성하도록 해야한다. 만약 프로그래밍 언어에서 동시(concurrent) 처리 능력(capabilities)을 가지고 있다면 그 메서드(싱글톤 객체를 체크하고 생성하는 메서드)는 상호 보완(mutually exclusive)적으로 만들어져야만 한다.(번역을 하니 말이 조금 어려운데요, 쉽게 풀자면 프로그래밍 언어에서 뮤텍스나 세마포어 같은 기능을 지원할 경우에 싱글톤의 객체 생성 메서드의 원자성을 보장해야한다는 의미입니다.)


이 문제에 대한 고전적인 해결방법은 그 클래스에 상호배제(mutual exclusion)를 사용해서 객체가 생성 중임을 알리는 것이다. (싱글톤 객체 생성 메서드에서 세마포어 등을 이용해서 두 개 이상의 스레드가 동시 접근이 불가능하도록 하라는 의미입니다.)


예 Example

여기에서 보여주는 자바 솔루션은 모두 스레드 세이프(thread-safe, 멀티 스레드 환경에서 상호배제를 보장해 준다는 것을 의미)하도록 만들었다. 자바 5.0부터는 싱글톤을 생성하는 가장 쉬운 방법은 enum 타입 방식인데 이 색션의 가장 마지막에 보여줄 것이다. 


게으른 초기화 Lazy initialization


public class Singleton {
        private static Singleton _instance = null;
 
        private Singleton() {   }
 
        public static synchronized Singleton getInstance() {
                if (_instance == null) {
                        _instance = new Singleton();
                }
                return _instance;
        }
}


전통적인 간단한 방법 Traditional simple way

이 방법은 언어 상의 특별한 구조가 필요없이 스레드 세이프한 방법이지만 위에서 보여준 게이른 초기화를 하지 않는 방법이다. 싱글톤 클래스가 초기화될 때 그 객치(instance)또한 생성된다. 이는 getInstance()를 호출하기 훨~씬 전일 수도 있다. 예를들어 싱글톤 클래스의 스태틱 메서드가 호출될 때 싱글톤 객체가 생성될 수 있다. 게으른 초기화가 필요없거나, 애플리케이션이 실행된 초기에 싱글톤 객체가 생성될 필요가 있거나, 당신의 싱글톤 클래스에 다른 스태틱 멤버나 스태틱 메서드가 없다면(스태틱 멤버나 메서드가 없다는 것은 유일한 스태틱 메서드인 getInstance()가 호춭될 때 싱글톤 객체가 생성됨을 의미한다.), 이 간단한 방법이 사용될 수 있을 것이다.


public class Singleton {
        private static final Singleton instance = new Singleton();
 
        // Private constructor prevents instantiation from other classes
        private Singleton() { }
 
        public static Singleton getInstance() {
                return instance;
        }
}


스태틱 블럭 초기화 Static block initialization

몇몇 저자들은 전처리(pre-processing)를 하는 비슷한 방법을 말한다. 이 방법에서 보면 전통적인 방법은 이 방법의 특별한 케이스로 볼 수 있다. 

public class Singleton {
  private static final Singleton instance;
 
  static {
    try {
      instance = new Singleton();
    } catch (IOException e) {
      throw new RuntimeException("Darn, an error's occurred!", e);
    }
  }
 
  public static Singleton getInstance() {
    return instance;
  }
 
  private Singleton() {
    // ...
  }
}


빌 퍼그의 방법 The solution of Bill Pugh

Maryland 대학의 컴퓨터 공학 연구자인 Bill Pugh는 자바에서 구현될 때 싱글톤 패턴의 코드 이슈에 관해 글을 썼었다. "Double-checked locking" 에 들어있는 Pugh의 노력은 자바5의 메모리 모델의 변화를 야기했고, 자바에서 싱글톤을 구현하는 표준 방법으로 간주됐다. initialization on demand holder idiom으로 알려진 이 기술은 가능한 게으르게 하고, 모든 자바 버전에서 동작한다.  이 방법은 클래스 초기화에 대한 언어의 보증(guarantees)을 이용하고, 따라서 모든 자바를 따르는 컴파일러나 가상머신에서 잘 동작한다.


중첩된 클래스는 getInstance()가 호출되기 전까지는 참조되지 않는다. 따라서 이 방법은 특별한 언어의 구조가 필요없는(예를들면 volatile이나 synchronized) 스레드 세이프(thread-safe)한 방법이다.


public class Singleton {
        // Private constructor prevents instantiation from other classes
        private Singleton() { }
 
        /**
        * SingletonHolder is loaded on the first execution of Singleton.getInstance() 
        * or the first access to SingletonHolder.INSTANCE, not before.
        */
        private static class SingletonHolder { 
                public static final Singleton instance = new Singleton();
        }
 
        public static Singleton getInstance() {
                return SingletonHolder.instance;
        }
}

내부 클래스인 Singletonholder는 static final이나 읽기만 가능한 클래스 멤버에 접근 가능한 프로퍼티(Property)를 구현함으로써 대체될 수 있다. C#에 있는 게으른(lazy) 객체처럼 Singleton.Instance 프로퍼티가 호출될 때마다, 이 싱글톤은 제일 처음 인스턴스화된다.


Enum을 이용한 방법 The Enum way

Joshua Bloch는 그의 책 "Effective Java"2판에서 enums을 지원하는 어떤 자바 버전이든 상관없이 "유일한 enum 타입은 싱글톤을 구현하는데 가장 좋은 방법이다.(a single-element enum type is the best way to implement singleton)"라고 언급했다. enum의 사용은 구현하기 매우 쉬운 방법이고, 직렬화 가능한 객체(serializable objects)와 관련된 문제가 없다.(이러한 문제가 있다면 다른 방법으로 우회해서 구현해야한다.)


public enum Singleton {
        INSTANCE;
        public void execute (String arg) {
                //... perform operation here ...
        }
}

public메서드는 필요한 타입의 인자를 사용하는데 쓰일 수 있다. ; 여기에서는 String 인자가 사용됐다.

이 접근법은 자바의 enum 값이 자바 프로그램 내에서 오직 한번만 인스턴스화 되는 점을 이용함으로써 싱글톤을 구현한다. 자바의 enum 값은 전역적으로 접근 가능하기 때문에, 이는 싱글톤이다. 이 방법의 문제점은 enum 타입이 유연성이 떨어질 수 있다는 점이다. ; 예를들면 늦은 초기화를 지원하지 못한다는 점이다.


프로토타입에 기반한 싱글톤 Prototype-based singleton

클래스 대신에 객체가 사용되는 프로토타입 기반 프로그래밍(prototype-based programming) 언어에서 "싱글톤"은 단순히 복제되지 않거나 다른 객체의 프로토타입으로 사용되지 않는 것을 의미한다. 


Foo := Object clone
Foo clone := Foo


팩토리 메서드 패턴과 함께 사용되는 예 Example of use with the factory method pattern

싱글톤 패턴은 구체적인 타입을 사용하는 부분에서 모르는 시스템 전역 자원을 생성하기 위해 종종 팩토리 메서드 패턴과의 조합으로 사용되고는 한다. 이 두 패턴을 사용하는 한 예는 자바의 Abstract Window Toolkit(AWT)이다.

java.awt.Toolkit은 다양한 AWT 컴포넌트를 특정 네이티브 툴킷 구현으로 바인딩시키는(bind) 추상클래스이다. Toolkit클래스는 Toolkit.getDefaultToolkit() 팩토리 메서드를 가지고 있는데, 이 메서드는 플랫폼에 특화된 Toolkit의 서브클래스를 리턴한다. AWT가 바인딩을 위한 오직 하나의 객체만 필요로 하고, 이 유일한 객체는 상대적으로 생성 비용이 크게 들기 때문에, Toolkit 객체는 싱글톤으로 한다. toolkit 메서드는 한 객체에서 구현되어야 하고, 클래스의 static 메서드로 구현되어서는 안되는데 그 이유는 구체적인 구현은 플랫폼 독립적인 컴포넌트에게 알려져 있지 않기 때문이다. Toolkit클래스의 서브클래스 이름은 System.getProperties()를 통해 얻어지는 "awt.toolkit" 환경 속성으로 정해진다.


예를들어, toolkit에 의해 수행되는 바인딩은 java.awt.Window를 플랫폼 특화된 java.awt.peer.WindowPeer 구현으로 바인딩하는 지원 구현(backing implementation)을 허락한다. Window클래스와 window를 사용하는 애플리케이션도 peer의 어떤 플랫폼 특화된 서브클래스가 사용되는지 알 필요가 없다.


문제점 Drawbacks

이 패턴은 전역 상태(global state)를 애플리케이션에 도입함으로써, 유닛 테스트를 더 어렵게 만든다. 또한 멀티 스레드에서 싱글톤에 접근하기 위해서는 직렬화되어야(serialised) 하기 때문에(예를들면 lock을 걸어서) 프로그램에서 동시성 가능성도 낮춘다는 것을 잘 알아야 한다. dependency injection의 대변자들은 이 패턴이 private과 static메서들르 사용하기 때문에 안티패턴으로 간주한다. 일부에서는 자바나 PHP같은 언어에서 리플렉션(reflection)을 이용해서 싱글톤 패턴을 부수는 방법을 제안하기도 했다. 

Posted by Code-Moon

댓글을 달아 주세요

먼저 이 글은 영문 위키의 글을 번역한 글임을 알려드립니다.

영어 실력이 부족하여 오역이 있을 수도 있습니다.

원문 주소 : http://en.wikipedia.org/wiki/Prototype_pattern



생성 패턴 - 프로토타입



The prototype pattern(이하 프로토타입 패턴)은 프로토타입(원형, 기본틀 등으로 해석할 수 있겠네요.) 객체에 의해 생성될 객체의 타입이 결정되는 생성 디자인 패턴이다. 이 패턴은 새로운 객체를 생성하기 위해 clone(복제)을 이용한다. 

이 패턴은 

  • 클라이언트 어플리케이션에서 객체 생성자의 서브 클래싱을 피한다.(반대로 추상 팩토리 패턴에서는 객체 생성자를 서브 클래싱해야만 한다.)
  • 주어진 애플리케이션에서 일반적인 방법(new 키워드를 이용한 방법)으로 객체를 생성할 때에 필요한 비용이 엄청난 경우에 이 비용을 없앨 수 있다.


이 패턴을 구현하기 위해, pure virtual(순수 추상 메서드라고 하면 되나요?... 전 원래 그냥 퓨어 버츄얼이라고 읽어서..) clone()메서드를 가지는 추상 클래스를 선언한다. polymorphic constructor(다형적인 생성자)가 필용한 어떤 클래스든지 추상 클래스를 상속받아서 clone()메서드를 구현해야 한다.

클라이언트는 new 연산자와 클래스 이름을 같이 쓰기보다는 프로토타입 객체의 clone()메서드를 호출하거나, 팩토리에 원하는 클래스에 해당하는 인자를 넣어서 호출하거나, 다른 디자인 패턴에 의해 제공되는 어떤 메커니즘을 통해 clone()메서드를 호출할 수도 있다.


구조 Structure



예 Example

프로토타입 패턴은 프로토타입 객체를 이용해서 어떤 종류의 객체를 생성할 지 정할 수 있다. 새로운 객체의 프로토타입은 종종 완전히 만들어지기 전에 생성이된다. 하지만 이 예에서는 프로토타입이 수동적이고(passive) 스스로는 복제하지는 않는다. 세포의 유사분열(두개의 독립적인 세포가 만들어진다.)은 프로토타입의 한 예이다. 유사분열은 스스로는 복제하는 일을 하기 때문에 프로토타입 패턴의 실례라 할 수 있다. 세포가 분열될 때, 두개의 독립적인 유전자 형이 결과물로 나온다. 다른 말로 세포가 스스로를 복제한다는 말이다. 


Java



/**
 * Prototype class
 */
abstract class Prototype implements Cloneable {
        @Override
        public Prototype clone() throws CloneNotSupportedException {
                return (Prototype)super.clone();
        }
 
        public abstract void setX(int x);
 
        public abstract void printX();
 
        public abstract int getX();
}
 
/**
 * Implementation of prototype class
 */
class PrototypeImpl extends Prototype {
        int x;
 
        public PrototypeImpl(int x) {
                this.x = x;
        }
 
        public void setX(int x) {
                this.x = x;
        }
 
        public void printX() {
                System.out.println("Value :" + x);
        }
 
        public int getX() {
                return x;
        }
}
 
/**
 * Client code
 */
public class PrototypeTest {
        public static void main(String args[]) throws CloneNotSupportedException {
                Prototype prototype = new PrototypeImpl(1000);
 
                for (int i = 1; i < 10; i++) {
                        Prototype tempotype =  prototype.clone();
 
                        // Usage of values in prototype to derive a new value.
                        tempotype.setX( tempotype.getX() * i);
                        tempotype.printX();
                }
        }
}
 
/*
**Code output**
 
Value :1000
Value :2000
Value :3000
Value :4000
Value :5000
Value :6000
Value :7000
Value :8000
Value :9000
*/


경험에 의한 규칙 Rules of Thumb

때때로 생성 패턴은 겹친다. - 프로토타입이나 추상팩토리 둘 중 하나가 적절한 경우가 있다. 

또 다른 경우에 생성 패턴들은 상호 보완적이기도 하다. : 추상 팩토리는 제품 객체를 복제해서 리턴해주기 위해 프로토타입의 집합을 저장하고 있을 수 있다. 추상 팩토리, 빌더, 프로토타입은 각자의 구현에 싱글톤을 사용할 수도 있다. 

추상 팩토리는 종종 팩토리 메서드로 구현되기도하지만(상속 inheritance을 통해 제품 객체를 생성하는 경우), 프로토타입을 이용해서 구현할 수도 있다.(위임 delegate를 이용해 생성하는 경우)


종종 설계자가 어디에서 더 유연한 설계가 필요한지를 발견하기 때문에,  설계는 팩토리 메서드를 사용해서 시작하고 추상 팩토리, 프로토타입, 똔느 빌더 등으로 발전할 수 있다.


프로토타입은 서브클래싱이 필요없지만, 초기화"initialize" 메서드를 필요로한다. 팩토리 메서드는 서브클래싱이 필요하지만, 초기화는 불필요하다.


콤포짓(Composite)과 데코레이터(Decorator)패턴을 많이 사용하는 설계에서는 종종 프로토타입을 사용하는 것이 좋을 수 있다. 


경험에 의하면 런타임시에 당신이 복제하기 위하는 객체를 트루 카피(true copy)해서 생성하고 싶을 때 clone()메서드가 필요할 수 있다. True copy라하면 새로 생성되는 객체의 모든 속성(attributes)이 그를 복제해내는 객체와 같아야 한다는 것이다. 만약 당신이 new를 사용해서 그 클래스를 초기화할 수 있었다면, 초기값들을 속성으로 가진 객체를 얻어냈을 것이다. 예를 들어, 당신이 은행 거래를 수행하는 시스템을 설계했다고 하면, 당신은 자신의 계좌 정보를 가지고 있는 객체를 복사하고, 복제된 객체를 이용해 거래를 하고나서 수정된 객체로 기존 객체를 덮고 싶을 것이다. 이러한 경우에 당신은 new 대신 clone()을 사용하고 싶을 것이다. 

Posted by Code-Moon

댓글을 달아 주세요