'DESIGN PATTERN/실용주의 디자인패턴'에 해당되는 글 29건

 기본 아이디어

• 객체를 생성하는 코드를 객체의 내부 표현으로 부터 분리시켜 동일한 생성 과정을 통해 여러 종류의 표현을 생성할 수 있도록
• 비즈니스 객체(도메인 레벨의 추상화를 모델링하는 객체)를 세부구현 정보(비즈니스 객체를 어떻게 화면에 보일 것인가, 혹은 어떻게 데이터 베이스에 넣을 것인가 등)로 부터 분리시켜준다.
• 빌터 패턴은 사용하면 도메인 레벨의 객체가 자신의 다양한 표현형을 생성할 수 있게 된다.
• 비즈니스 객체는 패턴에서 Director의 역할을 맞고, Concrete Builder의 역할을 맡은 객체(builder interface 구현)표현을 생성

 //Table.Exporter : Builder

  public interface Exporter    //{=Table.Exporter}
 { 

public void startTable()   throws IOException;
  public void storeMetadata(
     String tableName,
     int width,
     int height,
     Iterator columnNames ) throws IOException;
  public void storeRow(Iterator data) throws IOException;
  public void endTable()     throws IOException;
 }

    //CSVExporter, JtableExporter : Contcrete Builder

public class JTableExporter implements Table.Exporter
{
     private String[] columnHeads;
     private Object[][] contents;
     private int   rowIndex = 0;

     public void startTable() throws IOException { rowIndex = 0; }

     public void storeMetadata( String tableName,
          int width,
          int height,
          Iterator columnNames ) throws IOException
 {
      contents = new Object[height][width];
      columnHeads = new String[width];

      int columnIndex = 0;
      while( columnNames.hasNext() )
           columnHeads[columnIndex++] = columnNames.next().toString();
 }

 public void storeRow( Iterator data ) throws IOException
 { 

int columnIndex = 0;
  while( data.hasNext() )
   contents[rowIndex][columnIndex++] = data.next();
  ++rowIndex;
 }

 public void endTable() throws IOException {/*nothing to do*/}

 /** Return the Concrete Product of this builder---a JTable
  *  initialized with the table data.
  */
 public JTable getJTable()
 { 

return new JTable( contents, columnHeads );
 }

 /** A unit test for the JTableExporter class
  * Run it with <em>java com.holub.database.JTableExporter\$Test</em>.
  */

public class CSVExporter implements Table.Exporter
{ 

private final Writer out;
 private    int  width;

 public CSVExporter( Writer out )
 { 

this.out = out;
 }

 public void storeMetadata( String tableName,
          int width,
          int height,
          Iterator columnNames ) throws IOException

 { 

this.width = width;
  out.write(tableName == null ? "<anonymous>" : tableName );
  out.write("\n");
  storeRow( columnNames ); // comma separated list of columns ids
 }

 public void storeRow( Iterator data ) throws IOException
 { 

int i = width;
  while( data.hasNext() )
  { Object datum = data.next();

   // Null columns are represented by an empty field
   // (two commas in a row). There's nothing to write
   // if the column data is null.
       if( datum != null ) 
    out.write( datum.toString() );

       if( --i > 0 )
            out.write(",\t");
      }
      out.write("\n");
 }

 public void startTable() throws IOException {/*nothing to do*/}
 public void endTable()   throws IOException {/*nothing to do*/}

}

  //ConcreteTable : Director

 public static class Test
{

public static void main( String[] args ) throws IOException
{

//Create Concrete Director
Table people = TableFactory.create( "people",
new String[]{ "First", "Last" } );

people.insert( new String[]{ "Allen", "Holub" } );
people.insert( new String[]{ "Ichabod", "Crane" } );
people.insert( new String[]{ "Rip", "VanWinkle" } );
people.insert( new String[]{ "Goldie", "Locks" } );

javax.swing.JFrame frame = new javax.swing.JFrame();
frame.setDefaultCloseOperation( JFrame.EXIT_ON_CLOSE );

//Create Concrete Builder

JTableExporter tableBuilder = new JTableExporter();

// Table의 Export method CSVExporter()대신 JTableExporter()를 넘긴다.

=> CSV표현 방법이 아닌 JTable를 표현(Export)한다.

=> Table이 아닌 구현된 Builder가 Export를 위임해서 일을 한다.

=> GetXML(), GetHTML, GetCSV() 와 같은 표현을 위한 함수를 만들지 않는다.

=> 구현된 Table Builder를 Director에 넘겨 동일한 일을 처리하게 하는 것이 Command Pattern과 비슷한 것 같다.       Builder pattern의 Point는 동일한 생성과정을 통해 하나의 타입의 다양한 표현을 하는 것으로 생각(2016.03.24)

people.export( tableBuilder );

frame.getContentPane().add(

   //데이터가 입련된 후에는 GetJtable()을 호출하여 JTableExporter로 부터 JTable을 가져온다.

   =>UI에서는 표현형에 상관없이 Builder를 통해서 도메인 모델에 접근하게 된다.

   =>다시 말해서 UI로직을 비즈니스 로직으로 부터 분리할 수 있도록 해준다.
    new JScrollPane( tableBuilder.getJTable() ) );

    frame.pack();
    frame.setVisible( true );
}
}
}

• Builder 패턴은 객체를 표현을 '비즈니스' 로직과 분리해 주어 비즈니스 로직을 수정하지 않고도 새로운(혹은 변화된) 표현을 쉽게 추가할 수 있도록 해준다.
• 객체가 자신의 표현을 getter를 이용하여 반환하게 되면 유지 보수상에 문제가 생길 수 있다. Builder 패턴이 이러한 문제를 해결해준다.
• Builder 패턴을 사용하면 Director와 Builder가 강하게 결합된다, 또한 Builder의 인터페이스가 바꾸면 이를 구현한 모든 클래스(Concrete Builder)가 영향을 받게 된다. 그렇게 때문에 Builder 인터페이스 설계 시에는 세심한 주의가 필요하다.
• 하지만 Builder 인터페이스가 변화하더라도 이는 Concrete Builder에만 영향을 미친다. 반면 Getter와 Setter를 사용했을 경우에는 프로그램 전반에 영향을 미치게 된다.

• Bridge는 인터페이스를 통해 서브시스템을 격리 시킨다. 이는 한 서브시스템의 변화가 다른 서브시스템에 영향을 미치는 것을 막아준다.
• Facade 패턴의 주요 목적은 '단순화'이며 , 서브시스템을 격리시키지는 않는다.

1. Peer Class들은 java.awt.Toolkit라는 Abstract Factory를 사용하여 런타임에 생성된다.

2. Java.awt.Window 클래슨 Toolkit과 Peer에 대해서 알고 있다. Window를 생성할 때 window 객체를 적절한 peer를 생성하게 된다.

    Window의 객체의 관점에서 프로그래밍 한다면 어떠한 Peer가 있는지에 대해서 전혀 알필요가 없다.

=> 결과적으로 브리짓의 다른 측면에 있는 것들(모든 Peer)은 심지어 런타임에도 바뀔 수 있으며, 이러한 변화는 브리지의 다른 쪽에는  영향을 미치지 않는다. 마찬가지로 , 피어 구현 중 어떤 것도 자신이 어떻게 사용되고 있는지에 대해 알지 못한다.

public final class Database
{

public Database() { }

public Database( File path, Table[] database ) throws IOException
{ useDatabase( path );
for( int i = 0; i < database.length; ++i )
tables.put( database[i].name(), database[i] );
}

public void createTable( String name, List columns )
{

String[] columnNames = new String[ columns.size() ];
int i = 0;
for( Iterator names = columns.iterator(); names.hasNext(); )
columnNames[i++] = (String) names.next();

Table newTable = TableFactory.create(name, columnNames);

tables.put( name, newTable );
}

public void dropTable( String name )
{ tables.remove( name ); // ignore the error if there is one.

File tableFile = new File(location,name);
if( tableFile.exists() )
tableFile.delete();
}
}

 Database와 Table은 Bridge를 구성한다. Table 인터페이스는 다양한 Table 구현체를 은닉시켜 준다.

 그리고 TableFactory는 다양한 Table 구현체 중 하나를 선택하여 사용할 수 있도록 해준다.

 Database 관점에서 보면 데이타 저장 서브시스템(Table 측)의 변화가 Table 인터페이스를 통해서 은닉된다.

  Facade 패턴은 서브시스템에 있는 인터페이스 집합에 대해 하나의 단순화된 통합 인터페이스를 제공하여

  서브 시스템을 쉽게 사용하게 해준다.

 Client ( Life, Clock, Neighborhood Class) 는 Facede(MenuSite)를 SubSystem에 객체지향적인 방식으로 접근할 수 있도록 한다.

•  MenuSite는 자바 메뉴사이트(SubSystem)에 대한 Facede 이면, 메뉴 시스템을 단순화해 준다.
• 또한 공유된 메뉴바에 메뉴를 쉽게 추가 할 수 있도록 해준다.

   Composite pattern 특징

• 같은 인터페이스를 구현하는 두 종류(Composite 와 Leaf)의 클래스 객체로 구성
• 공통 인터페이스는 Component의 담당
• 계층 구조에서 Leaf의 역할을 하는 객체 혹은 객체군이 존재 / 자식을 같지 않아 브랜치를 끝내는 노드 : Button CheckBox
• Composite 패턴을 이용하여 코드를 작성하면 계층 구조에 포함되어 있는 객체가 Leaf인지 composite인지 알 필요 없다
• => 둘 모두 하나의 인터페이스를 통해 접근 할 수 있다 => 코드가 단순해진다.

디렉토리 시스템 ; composite pattern의 예

Composite 패턴에서는 루트노드가 파생(자식) 클래스이며, 보통 Leaf 노드 클래스 아랫부분에 표시하게 된다.

- 다이어그램을 보면 Directory Class가 SimpleFile 밑에 표시되어 있다.

- 객체의 구조는 다이어그램과 반대이다. (컨테이너, 노드를 윗부분 / Leat 노드는 아랫부분에)

Composite 패턴을 사용하면 디렉토리 순회 시 하부 디렉토리(디렉토리, 파일)를 동일한 방식으로 취급할 수 있다.

위 그림의 주석 부분을 보면 객체에 단지 Print() 메시지를 보낼 뿐이다.

- 객체가 Simplefile이라면 단순히 파일 이름만 출력될 것이고

- 객체가 Directory라면 디렉토리가 포함하고 있는 내용을 출력할 것이다

public class Clock

{

 public void tick()
 { 

publisher.publish
  ( 

     //Clock이 생성한 Distributor 구현은 Concrete Visitor

new Publisher.Distributor()
   { 

public void deliverTo( Object subscriber )
    { 

if( !menuIsActive() )
      ((Listener)subscriber).tick();
   }
  }

);

 }

}

public class Publisher
{
     public interface Distributor
     { 
           void deliverTo( Object subscriber ); // the Visitor pattern's
     }           // "visit" method.

     private volatile Node subscribers = null;

 synchronized public void subscribe( Object subscriber )
 { 
       subscribers = new Node( subscriber, subscribers );
 }

 synchronized public void cancelSubscription( Object subscriber )
 { 
       subscribers = subscribers.remove( subscriber );
 }

}

private class Node
{ 
    public final Object subscriber;
    public final Node next;
 
   private Node( Object subscriber, Node next )
   { 
       this.subscriber = subscriber;
      this.next  = next;
   }
 
   public Node remove( Object target )
   { 
     if( target == subscriber )
     return next;
 
    if( next == null )       // target is not in list
     throw new java.util.NoSuchElementException
             (target.toString());
 
    return new Node(subscriber, next.remove(target));
   }
 

• Clock : 클라이언트 객체
• Publisher는 Object Structure
• Distributor는 Visitor 인터페이스
• Node는 객체 구조 안에 포함되어 있는 Element
• Node.accept() : 'Accept) 요청
• deliverTo() : 'visit' 요청이다.
• Clock이 생성한 Distributor 구현은 Concrete Visitor

주로 호스트 객체는 자료 구조로 구성되어 있으며 Visitor는 이 자료 구조를 순회하며 호스트 객체를 방문/처리 한다.

Visitor 패턴 장점

• Visitor는 기존 객체를 변경하지 않으면서 새로운 연산을 추가할 수 있도록 해준다
• 이는 구현 시에 생각하지 못했던 혹은 알려지지 않았던 연산을 쉽게 구현할 수 있도록 해준다.
• 드물게 사용되는 연산을 외부에 구현할 수 있도록 해주기 때문에 클래스가 작아진다.

Visitor 패턴 주의 사항

• Visotor는 캡슐화를 위반 할수도 있으며, Visitor와 Element 사이의 결합도가 높다.
• 가능하면 Visitor가 Element의 Public 인터페이스 혹은 제한된 인터페이스를 접근하도록 하자

 죽어 있는 셀은 정확히 3개 이웃 셀이 살아 있다면 살아난다.

 검은 색은 살아 있는 것 / 흰색은 다음 턴에 살아난다.

 셀은 두 개 혹은 세 개의 이웃을 가지면 계속 살아 있는 상태로 있는다.

검은 색 셀들은 계속 살아 있게 된다.

 앞의 두 경우에 해달되지 않으면 셀은 외로움에 빠져 , 혹은 군주에 질식되어 죽어 버린다.

 회색 셀은 다음 번에 죽게 된다.

 Command 패턴은 빌딩 블록 패턴이며, Staratage 패턴은 Command 패턴의 특별한 경우이다.

class CommandObject implements Runnable
{
  public void run()
  {
    // stuff to do on the thread goes here
  }
};

Thread controller = new Thread( new CommandObject()); //쓰레드가 어떤 Command Object 사용할지 전달
controller.start(); // fire up the thread : Run 함수를 실행

Stratagy 패턴은 특정 연산을 '어떻게'  수행할 것인지에 대한 전략을 캡슐화한 Strategy 객체를 전달한다.

이때 Starategy 객체는 무엇을 수행해야 하는가가 좀 더 명확한 Command 객체라 할 수 있다.

public void main( String[] args )
{
  // sort the command-line arguments:
  Arrays.sort
  (  args,
    new Comparator()
    {
      public int compare( Object o1, Object o2 )
      {
        // By using a minus sign to reverse the sign
        // of the result, "larger" items will be
        // treated as if they're "smaller."
         return -( o1.compareTo(o2) );
      }
    }
  );
}

Comparator 인터페이스 구현체를  정렬(무엇)을 어떻게 해야 하는지에 대한 전략을 캡술화한 Strategy 객체이다. 

Startagy 객체의 구현에 따라 다양한 전략으로 정렬을 할 수 있다.

Frame container = new Frame();
container.setLayout( new FlowLayout() );
container.add( new Button("1") );
container.add( new Button("2") );
container.add( new Button("3") );
container.add( new Button("3") );

You can lay the buttons out in a two-by-two grid like this:

Frame container = new Frame();
container.setLayout( new GridLayout(2,2) );
container.add( new Button("1") );
container.add( new Button("2") );
container.add( new Button("3") );
container.add( new Button("3") );

대부분의 상황에서 Strategy 패턴은 Factory Method 패턴의 좋은 대안이 된다. 

가능한 구현 상속을 이용하는 Factory Method 패턴 대신 인터페이스 상속을 하는 Strategy 패턴을 사용하기를 바란다

namespace AbstractFactoryCreateDynamicInstance.ConcreateFactory
{
    public class URL : URLInterFace
    {
        public Type Spec { get; private set; }

        public URL(Type spec)
        {
            this.Spec = spec;
        }

        
        public URLConnection openConnection()
        {
            URLConnection con = null;

            //Connection Class가 추가될 때마다 수정 필요
            if (Spec.Equals(typeof(HttpURLConnection)))
            {
                con = new HttpURLConnection();
            }
            else if (Spec.Equals(typeof(FtpURLConnection)))
            {
                con = new FtpURLConnection();
            }else
            {
                con = new OtherURLConnection();
            }

           
            return con;
        }

        
        public dynamic openConnectionDynamicCreateInstance()
        {
            //Connection Class가 추가되더라도 수정 불필요
            return System.Reflection.Assembly.GetExecutingAssembly().
                CreateInstance(Spec.ToString());
        }
    }
}

    class Program
    {
        static void Main(string[] args)
        {
            //Factory 생성
            URLInterFace url = new URL(typeof(HttpURLConnection));

            URLConnection StaticConnetion = url.openConnection();
            URLConnection DynamicConnection = url.openConnectionDynamicCreateInstance();

            Console.WriteLine(StaticConnetion.connect());
            Console.WriteLine(DynamicConnection.connect());

        }
    }

interface URLConnection
{
   void setDoInput (boolean on);
   void setDoOutput (boolean on);
   void connect ();
  
   InputStream getInputStream();
}
 
 abstract class InputStream // used as interface
 {
    public abstract int read();
 }
 
 class URL
 {
    private String spec;
  
    public URL( String spec ){ this.spec = spec; }
  
    public URLConnection openConnection()
   {
      return new HttpURLConnection(this);
   }
 }
 
 class HttpURLConnection implements URLConnection
 {
   public HttpURLConnection(URL toHere) { /*...*/ }
   public InputStream getInputStream()
   {
      return new InputStream()
   {
  
   public int read()
   {

      // code goes here to read using the HTTP Protocol
      return -1;
   }
 };
 }
 
   public void setDoInput (boolean on) { /*...*/ }
   public void setDoOutput (boolean on) { /*...*/ }
   public void connect ( ) { /*...*/ }
 }

* 패턴을 오버랩하여 사용하여, 하나의 클래스가 여러 패턴에 참여하는 것은 흔한 일이다 관점의 전환에 익숙해지자

 Abstract factory 패턴은 인터페이스(Employee)를 통해 생성하려는 객체의 실체 타입(Peon)을 은닉시켜준다.

생성된 객체를 사용하는 클라이언트는 인터페이스만을 알고 있으므로 인터페이스를 구현하고 있는 구체 클래스의

변화로부터 자유롭다.(Peon 클래가 변화 더라도 new Peon 부분에 대한 변경이 필요 없다.)

 구체 클래스는 인터페이스보다 변하기 쉽기 때문에 가능하면 인터페이스를 사용하라는 '의존 역전의 원칙(DIP,Dependency Inversion Principle)'을 생각해보자.

interface Iterator
{
   Object next();
   boolean hasNext();
   //...
 }

 class Tree  implements Collection
 {
   public Iterator iterator()
   {
      return new Walker();
   }

}

   private class Walker implements Iterator
   {
     public Object next() { /*...*/ return null; }
     public boolean hasNext() { /*...*/ return false; }
   }