'DESIGN PATTERN'에 해당되는 글 33건

Strategy Pattern을 어떻게 대안이 될 수 있는가? ^^

    class FLEX :Equipment
    {
        public override void Start()
        {
            //VK93과 같은 일을 한다(중복코드 발생)
            //do someting V93K about start
        }

        public override void Load()
        {
            //CATALIST와 같은 일을 한다(중복코드 발생)
            //do someting CATALIST about load
        }

        public override void Modify()
        {
            //do someting FLEX about modify
        }
    }

  문제점 : VK93의 Start() or Catalist 의 Load() 함수가 변경된다면 같이 수정이 필요

    class D10 : Equipment
    {

        public override void Start()
        {
            //do someting D10 about load
        }

        public override void Load()
        {
            //do someting D10 about load
        }

    public partial class Form1 : Form
    {
        EquipmentCommander _ec = new EquipmentCommander();

        public Form1()
        {
            InitializeComponent();

            Equipment vk93 = EquipmentFactory.CreateEquipment("V93K");
            Equipment Catalist = EquipmentFactory.CreateEquipment("Catalist");
            Equipment D10 = EquipmentFactory.CreateEquipment("D10");
            Equipment Flex = EquipmentFactory.CreateEquipment("FLEX");

            _ec.Excute(vk93);
            _ec.Excute(Catalist);
            _ec.Excute(Flex);

 문제점 : LSP를 위반한다. 즉 기반 클래스로 서브클래스의 사용을 하지 못한다.

    public class Equipment
    {
        public int ID { get; set; }
        public string Name { get; set; }
        public string Location { get; set; }
        public string PropertyforManager { get; set; }

 Factory 에서 생성 시에  맞는 전략을 구현한다.

    class EquipmentFactory
    {
        public static Equipment CreateEquipment(string EqpName)
        {

            Equipment eqp = new Equipment();
            eqp.Name = EqpName;

            return eqp;
        }
    }

 문제점 해결 : 전략 객체를 이용해서 장비가 행위를 한다.

                      중복코드를 만들지 않는다.(수정이 필요하면 전략객체만을 수정하면 된다.)

                      새로운 행위가 필요하면 기반 클래스의 수정없이 전략 클래스를 확장(OCP를 지킴)

    public partial class Form1 : Form
    {
        EquipmentCommander _ec = new EquipmentCommander();

        public Form1()
        {
            InitializeComponent();

            Equipment vk93 = EquipmentFactory.CreateEquipment("V93K");
            Equipment Catalist = EquipmentFactory.CreateEquipment("Catalist");
            Equipment D10 = EquipmentFactory.CreateEquipment("D10");
            Equipment Flex = EquipmentFactory.CreateEquipment("FLEX");

            _ec.Excute(vk93);
            _ec.Excute(Catalist);
            _ec.Excute(Flex);

             //D10은 modify를 하지 않지만 ModifyNothing()을 구현해서 문제를 해결한다.

_ec.Excute(D10);

            //Flex장비의 행동을vk93과 같게 변경하고 싶다면??
            //클래스를 생성해서 위임해야 겠지만 예제 이므로 여기서 테스트 하였음
            Flex.start = new StartV93K();
            Flex.load = new LoadV93K();
            Flex.modify = new ModifyV93K();

            _ec.Excute(Flex);

  }

}

문제점 해결 : EquipmentCommander 의 Execute가 기반 타입으로 작동하는데 문제가 없다

                     즉 LSP를 위반하지 않는다 ^^

기본 아이디어

- Adapter 패턴은 클래스의 인터페이스를 클라이언트가 기대하는 다른 인터페이스로 변화(어댑팅)한다. 이는 호환성 없는 인터페이스 때문에 함께 사용할 수 없는 클래스를 개조하여 함께 작동하도록 해준다.

// ResultSet interface를 구현한 ResultSetAdapter

public class ResultSetAdapter implements java.sql.ResultSet 

{

public ResultSetAdapter() {}
public boolean next() throws SQLException {throw new SQLException("ResultSet.next() unsupported");}

public int findColumn(String columnName)throws SQLException 

{throw new SQLException("ResultSet.findColumn(String columnName) unsupported");}

public void updateObject(String colIndex, Object obj) throws SQLException {throw new SQLException("ResultSet.updateObject(String colIndex, Object obj) unsupported");}

public void updateObject(String colIndex, Object obj, int s) throws SQLException {throw new SQLException("ResultSet.updateObject(String colIndex, Object obj, int s) unsupported");}
public Statement getStatement() throws SQLException {throw new SQLException("ResultSet.getStatement() unsupported");}
public void close() throws SQLException {throw new SQLException("ResultSet.close() unsupported");}
public void checkClosed() throws SQLException {throw new SQLException("ResultSet.checkClosed() unsupported");} 

}

// ResultSetAdapter를 상속받은 JDBCResultSet

public class JDBCResultSet extends ResultSetAdapter
{
 private     final Cursor cursor;

 private static final NumberFormat  format =
        NumberFormat.getInstance();

 /** Wrap a result set around a Cursor. The cursor
  *  should never have been advanced; just pass this constructor
  *  the return value from {@link Table#rows}.
  */

 public JDBCResultSet(Cursor cursor) throws SQLException
 {

        this.cursor = cursor;
 }

 public boolean next()
 { return cursor.advance();
 }

 public String getString(String columnName) throws SQLException
 { try
  { Object contents = cursor.column(columnName);
   return (contents==null) ? null : contents.toString();
  }
  catch( IndexOutOfBoundsException e )
  { throw new SQLException("column "+columnName+" doesn't exist" );
  }
 }

 public double getDouble(String columnName) throws SQLException
 { try
  { String contents = getString(columnName);
   return (contents == null)
     ? 0.0
     : format.parse( contents ).doubleValue()
     ;
  }
  catch( ParseException e )
  { throw new SQLException("field doesn't contain a number");
  }
 }

 public int getInt(String columnName) throws SQLException
 { try
  { String contents = getString(columnName);
   return (contents == null)
     ? 0
     : format.parse( contents ).intValue()
     ;
  }
  catch( ParseException e )
  { throw new SQLException("field doesn't contain a number");
  }
 }

 public long getLong(String columnName) throws SQLException
 { try
  { String contents = getString(columnName);
   return (contents == null)
     ? 0L
     : format.parse( contents ).longValue()
     ;
  }
  catch( ParseException e )
  { throw new SQLException("field doesn't contain a number");
  }
 }

 public void updateNull(String columnName )
 { cursor.update(columnName, null );
 }
 public void updateDouble(String columnName, double value)
 { cursor.update(columnName, format.format(value) );
 }
 public void updateInt(String columnName, long value)
 { cursor.update(columnName, format.format(value) );
 }
 public ResultSetMetaData getMetaData() throws SQLException
 { return new JDBCResultSetMetaData(cursor);
 }
}

- Coursor 와 java.sql.ResultSet는 적어도 핵심관점에서는 차이가 없다, 또한 JDBCResultSet class는 Cursor 객채를 래핑하고 있기 때문에 Coursor 객체가 인터페이스를 구현하고 있는 것처럼 보일 수도 있다. 하지만 JDBCResultSet은 Cursor(Adaptee)가 Taget 인터페이스(java.sql.ResultSet)를 구현하고 있는 것처럼 보이도록 하는 Adapter이다.

 public final class ArrayIterator implements Iterator
 {
   private int position = 0;
   private final Object[] items;
  
   public ArrayIterator(Object[] items){ this.items = items; }
 
   public boolean hasNext()
   {
     return ( position < items.length );
   }
 
   public Object next()
   {
     if( position >= items.length )
        throw new NoSuchElementException();
      return items[ position++ ];
   }
 
   public void remove()
   {
      throw new UnsupportedOperationException(
      "ArrayIterator.remove()");
   }
 
   /** Not part of the Iterator interface, returns the data
   * set in array form. Modifying the returned array will
   * not affect the iteration at all.
   */
   public Object[] toArray()
   {
      return (Object[]) items.clone();
   }
 }

  Arrayiterator 클래스(Adapter)는 배열(Adaptee)이  Iterator 인터페이스를 구현하고 있는 것 처럼 만들어 주기 때문에 배열을 Iterator를 통해 접근할 수 있게 해준다.

Bridge 패턴 VS Adapter 패턴

  Bridge : 서브시스템들을 분리시키는 거 , 대규모

 Adapter: 어떤 클래스를 이 클래스가 구현하고 있지 않은 인터페이스를 사용하여 작성한 프로그램에 적용시키기 위한 것, 소규모

 Decorator 패턴 VS Adapter 패턴

  Decorator :  어떤 클래스의 메소드를 행위를 상속(Extends)을 하지 않고 변경시키는 것

                    구조 측면에서 보자면 항상 자신이 데코레이팅하는 객체와 같은 인터페이스를 구현한다.

  Adapter :    대부분의 경우 래핑되는 객체의 인터페이스를 구현하지 않는다.

- Command pattern과 비슷하다는 생각이 들어서 찾아본 검색 결과 후 답변

The Command design pattern is used to solve problems like:
- How can an object be configured (customized) with a request?
- And how can the request be (ex)changed dynamically at run-time?

The point of Command is to decouple a request from its invoker and encapsulate it in a separate object (Command interface).
Invoker then delegates a request to a command object dynamically.

The Adapter design pattern (object adapter) is used to solve problems like:
- How can an object be accessed that has an incompatible interface
without changing existing interfaces?

The point of Adapter is to work through a separate object that adapts an incompatible interface, i.e., that implements our needed interface (Target) in terms of (by delegating to) the incompatible interface.

The Command pattern is more similar to the Strategy pattern, which decouples an algorithm from its context and encapsulates it in a separate object (Strategy).

기본 아이디어

State 패턴은 객체의 내부 상태에 따라 행위를 변경할 수 있도록 해준다. 이렇게 하면 객체는 마치 클래스를 바꾸는 것처럼 보인다.

상태에 따라 변화하는 행위를 구현하는 가장 단순한 방법은 현재 상태를 나타내는 필드를 두고, 각 메소드에서 필드 값을 처리하는 switch 문을 두어 case 문이 현재 상태화 관련된 행위를 제공하는 것이다.

 class ChangesBehaviorWithState
{
    private static int state = 0;

    public void methodOne()
    {

    switch( state )
    {
        case 0: /* behavior for state 0 goes here */ break;
        case 1: /* behavior for state 1 goes here */ break;
        case 2: /* behavior for state 2 goes here */ break;
    }
}

public void methodTwo()
{

switch( state )
{
    case 0: /* behavior for state 0 goes here */ break;
    case 1: /* behavior for state 1 goes here */ break;
    case 2: /* behavior for state 2 goes here */ break;
}

}
//...

}

위 접근 방법은 2가지 문제점이 있다.

1. Swich 문은 코드를 읽기 어렵게 만든다

2. 특정 상태와 연관되어 있는 해위를 제공하는 부분이 코드 전반에 흩어져 있기 때문에 유지보수가 어렵게 된다.

그러므로 내부의 상태머신(어떻게 한 상태에서 다른 상태로 바뀌는지, 그리고 각상태와 연관된 행위를 결정하는 룰)을 바꾸는 것이 굉장히 어렵게 된다. 

=> State 패턴으로 이 문제를 해결하자.

 //State Pattern을 사용한 JDBCconnection 객체

public class JDBCConnection extends ConnectionAdapter
{

 private Database database;

 public JDBCConnection(String uri) throws SQLException,
            URISyntaxException,
            IOException
 {

 this( new URI(uri) );
 }

 public JDBCConnection(URI uri) throws SQLException,
           IOException
 { 

database = new Database( uri );
 }

//AutoCommitState을 Enabled State 객체로 설정

private AutoCommitBehavior autoCommitState = enabled;

 public Statement createStatement() throws SQLException
 { 

return new JDBCStatement(database);
 }

 /** Return true if auto-commit mode is enabled */
 public boolean getAutoCommit() throws SQLException
 { 

return autoCommitState == enabled;

}

}

기본 아이디어

어떤 객체(Real Object)를 Real Subject와 동일한 인터페이스를 구현한 다른 중개 객체(Proxy)를 통해 접근하는 것이 땔는 편리할 수 있다는 것이다. 중개 객체는 게으를 초기화(값비싼 필드 등을 필요시 로딩)와 같은 일을 하게 된다.

/** A Map proxy that handles lazy instantiation of tables from the disk.**/

 private final class TableMap implements Map
 {
    private final Map realMap;
    public TableMap( Map realMap )
      {
        this.realMap = realMap;
      }

 }

TableMap이 자신이 포함하고 있는 realMap 객체의 프록시가 된다.

기본 정의

 일련의 객체 집합이 잘 정의된 통로(Chain)를 통해 메시지를 전달함으로써 하나 이상의 객체에 메시지를 처리할 수 있는 기회를 준다. 주어진 메시지에 가장 적합한 객체가 메시지를 처리한다. 또한 하나 이상의 객체가 메시지를 처리하는 것도 가능하다.

• Handler : 이벤트 처리 인터페이스와 다음 이벤트 처리 객체로의 링크를 정의한다.
• Concrete Handler : 요청을 처리, 혹은 아무 일도 하지 않고 이벤트를 다음 객체로 포워딩한다.
• Dispacher : 이벤트를 각 핸들러에 차례로 전달한다. Handler가 링크드 리스트로 구성되어 있으면 필요하지 않다.

기본 아이디어

Decorator 패턴은 '구현 상속(Extends)' 대신 '인터페이스 상속(Implements)/위임'  전략을 사용하여

깨지기 쉬운 기반 클래스 문제를 해결한다.

 public Table select( Selector where )
 { 

Table resultTable = new ConcreteTable( null,
          (String[]) columnNames.clone() );

      //result table을 Selector의 전략에 맞게 꺼내오는 부분 생략 
      return new UnmodifiableTable(resultTable);
 }

 // - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 public Table select(Selector where, String[] requestedColumns )
 { 

      Table resultTable = new ConcreteTable( null,
         (String[]) requestedColumns.clone() );

 //result table을 Selector의 전략에 맞게 꺼내오는 부분 생략

       return new UnmodifiableTable(resultTable);
 }

 - ConcreteTable을 생성하고, 조회한 후에 UnmodifiableTalbe을 사용하여 실제 결과 테이블을 래핑하여 반환

 public class UnmodifiableTable implements Table
{ 

 /** Return an UnmodifieableTable that wraps a clone of the
  *  currently wrapped table. (A deep copy is used.)
  */

 public Object clone() throws CloneNotSupportedException
 { UnmodifiableTable copy = (UnmodifiableTable) super.clone();
  copy.wrapped = (Table)( wrapped.clone() );
  return copy;
 }

 public int  insert(String[] c, Object[] v   ){ illegal(); return 0;}
 public int  insert(Object[] v        ){ illegal(); return 0;}
 public int  insert(Collection c,Collection v ){ illegal(); return 0;}
 public int  insert(Collection v      ){ illegal(); return 0;}
 public int  update(Selector w     ){ illegal(); return 0;}
 public int  delete( Selector w     ){ illegal(); return 0;}

 public void begin  (    ){ illegal(); }
 public void commit  (boolean all){ illegal(); }
 public void rollback (boolean all){ illegal(); }

 private final void illegal()
 { 

     throw new UnsupportedOperationException();
 }

 public Table select(Selector w,String[] r,Table[] o)
 { 

     return wrapped.select( w, r, o );
 }
 public Table select(Selector where, String[] requestedColumns)
 { 

     return wrapped.select(where, requestedColumns );
 }
 public Table select(Selector where)
 { 

     return wrapped.select(where);
 }
 public Table select(Selector w,Collection r,Collection o)
 { 

     return wrapped.select( w, r, o );
 }
 public Table select(Selector w, Collection r)
 { 

     return wrapped.select(w, r);
 }
 public Cursor rows()
 { 

     return wrapped.rows();
 }
 public void  export(Table.Exporter exporter) throws IOException
 { 

     wrapped.export(exporter);
 }

 public String toString()   { return wrapped.toString(); }
 public String name()   { return wrapped.name();   }
 public void  rename(String s){    wrapped.rename(s);  }
 public boolean isDirty()  { return wrapped.isDirty();  }

 public Table extract(){ return wrapped; }

}

- Decorater(UnmodifieableTable)은 Table을 수정하는 메소드(insert, update, delete)가 호출 될 때는 예외

- 나머지 메소드들은 래핑된 Decorater에 작업을 위임한다.

  정리

   UnmodifiableTable은 ConcreteTable에 있는 여러 메소드의 행위를 변화시켜 Table을 효과적으로 수정 불가능하게 만드는 것이다.

   1. IsImmutable 플래그를 넣어 이 플래그를 검사하게 할 수도 있지만 이 해결방법은 너무 복잡하다.

   2. 클래스를 상속하여 테이블을 수정할 수 있는 메소드들이 예외를 던지도록 오버라이딩할 수도 있었지만

      이는 깨지기 쉬운 기반 클래스 문제를 야기할 수 있다.

      a. 기반 클래스에 테이블을 수정할 수 있는 메소드를 추가했는데 , 파생 클래스에서 이 메소드를 오버라이딩하는 것을 깜빡?

      b. 컴파일 타임 에러를 런타임 에러로 바꾸기 때문에 유지보수하기 어려운 코드를 만들 위험에 노출시키게 된다.

   3. 구현 상속으로 발생할 수 있는 문제를 인터페이스 상속/위임 전략을 통해 해결

      래핑된 객체가 구현하고 있는 인터페이스와 똑같은 인터페이스를 구현한 수에 필요한 경우 연산을 래핑되어 있는 객체에 위임

      (래핑되는 객체와 인터페이스를 공유하지 못한 다면 해당 객체를 기반 클래스로 해야 할 것이다)

    => 이 방법은 Extends를 사용하지 않고 행위를 변경시킬 수 있도록 해주기 때문에 깨지기 쉬운 기반 클래스 문제를 해결해준다.

 Java I/O 클래스 Decorator 패턴 - 압축되어 있는 바이트 스트림을 읽을 때 데코레이터 체인을 사용한 예

  1. 바이트를 읽는다.

  2. 버퍼링을 사용하여 읽기 작업을 보다 효율적으로 한다.

  3. 바이트 스트림의 압축을 푼다.

 자바는 위 문제를 세 개의 클래스를 이용하여 해결한다.

정리

 - 이러한 해결 방법은 유연하다. 원하는 기능을 위해 여러 가지 데코레이터를 조합하여 사용하면 되는 것인다.

 - 더 중요한 것은 각 데코레이터 자체는 단 하나의 문제를 해결하기 때문에 상대적으로 단순하다.

    => 결과적으로 데코레이터들은 작성 및 디버깅하기 쉬우며, 시스템에 다른 영향을 미치지 않으면서 수정이 용이

 - 여러 데코레이터들을 조합하면 여러 다양한 기능을 사용할 수 있다. 데코레이터 자체는 작지만, 합쳐지면 강력하다.

 - Decorator 패턴을 사용하면 향후 원하는 기능을 추가하기도 쉽다.

 - 주요 목적은 구현 상속의 대안을 제공하는 것이다. 기반 클래스의 행위를 수정하거나 기능을 추가하려 한다면  

    Decorator 패턴의   도입을 신중히 검토해 보자

-  Decorator들을 래핑하는 순서도 중요하다.

 Java Collection 클래스 decorator 패턴 사용의 예

=> Decorator 패턴의 핵심은 총 2개의 클래스를 추가하는 것 만으로도 구현 상속 시 18개의 클래스를 필요로 했던 문제 해결

 정리

 - Decorator 패턴의 핵심은 객체에 새로운 능력을 추가하거나 객체의 행위를 변화시킬 수 있도록 해준다.

 - Decorator 패턴에서는 상속대신 합성을 사용하여 클래스 계층 구조를 단순화시킨다.