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

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; }
   }
 

class Singleton
{ 
  private static Singleton instance = null;
  public static instance()
  { 
    if( instance == null )
    { 
          instance = new Singleton();
    }
    return instance;
  }
  //...
}

class Singleton2
{

    private static Singleton instance = new Singleton();
    public instance()

   {

         return instance;

    }    

}

public static void main( String[] args )
{ //...
    Connection.pointTo( new URL(args[i]) ); //런타임에 인자를 가지고 URL을 생성
//...
}

class Connection
{
  private static URL server;
  public static pointAt( URL server ){ this.server = server; }
 
  private Connection()
  { //...
    establishConnectionTo( server );
    //...
  }
  
  private static Connection instance;
 
  public synchronized static Connection instance()
  {
    if( instance == null )
      instance = new Connection();
     
    return connection();
  }
} 

class DoubleChecked
{
  private static volatile DoubleChecked instance = null;
  private static Object lock = new Object();
 
  public static DoubleChecked instance()
  {
    if( instance == null)
      synchronized( lock )
      {
        if( instance == null )
          instance = new DoubleChecked();
      }
    return instance;
  }
}

class Employee

{ //...
    public void youAreFired()
    { 

         // lots of code
    }
}

인터페이스를 추가 , 구현한 클래스
 interface Employee
 {    

     void youAreFired();
 }

 class Peon implements Employee // used to be Employee
 {

public void youAreFired()
 { 

      // lots of code
 }

  }

Abstract Factory Pattern을 이용해서 구현

public interface Employee
{ 
      void youAreFired();
}

public static class EmployeeFactory
{ 
      private Factory(){/*empty*/}

public static Employee create()
{
    return new Peon();
}

}

 /*package*/

class Peon implements Employee
{ 
      public void youAreFired()
      { 

         // lots of code
      }

}

public static class EmployeeFactory
{

private EmployeeFactory(){/*empty*/}

public static Employee create()
{

    return new Peon();

}

익명 내부 클래스로 팩토리 버전

.

public static class EmployeeFactory
{

private Factory(){/*empty*/}

public static Employee create()
{

return new Employee()
{

public void youAreFired()
{ 

    // lots of code

}

}

}

}

 * 올바른 OO 디자인을 다음과 같은 과정을 밟는다.

1. Learn the "problem domain" (accounting, order processing, and so on).
2. Talk to your users to figure out the problems they need to solve.
3. Identify use cases—stand-alone tasks performed by an end user that have some
    useful outcome—that cover all these problems.
4. Figure out the activities you need to do to accomplish the goals established in theuse case.
5. Create a "dynamic model" that shows how a bunch of objects will send messages
    to one another at runtime to perform the activities identified in the previous step.

* Employee와 Manager가 동일한 연산을 동일한 방식으로 수행한다.

   : 같은 클래스로 구현한다.

* Employee와 Manager가 동일한 연산을 다른 방식으로 수행한다.

   : 두 클래스가 공통의 인터페이스를 구현한다.

* Employee와 Manager에 공통된 연산이 없다.

  : 별도의 클래스로 구현한다.

* Manager가 Employee에 약간의 연산을 추가한다.

  : Manager가 Employee를 extends하도록 한다.

기반 클래스는 깨지기 쉽기 때문에 구현 상속 기반의 프레임워크 역시 깨지기 쉽다.

그러므로 Template Method Pattern은 가능한 절제해 사용해야 한다

Factory Method 패턴은 파생클래스가 어떤 객체를 생성할지를 결정하도록 한다.

Factory Method 패턴은 Template Method 패턴의 생성 패턴 버전(구현상속이용)

이라 할 수 있다.

Strategy 패턴 들은 Factory method 패턴의 멋진 대안이(인터페이스 상속이용) 된다.

Factory Method 패턴은 Extends 관계를 잘못 사용하고 있다. 파생클래스가 기반 클래스에 아무런 기능도 추가하지 않기 때문이다.

참고 : http://paransilverlight.tistory.com/164

class Stack extends ArrayList
{

private int topOfStack = 0;

public void push( Object article )
{ 

    add( topOfStack++, article );
}
public Object pop()
{ 

    return remove( --topOfStack );
}
public void pushMany( Object[] articles )
{ 

    for( int i = 0; i < articles.length; ++i )
    push( articles[i] );
}

}

Stack aStack = new Stack();
aStack.push("1");
aStack.push("2");
aStack.clear();

해결 방법(다른 문제를 발생)

1.  스택이 스택의 내부 상태를 변경하는 모든 메소드를 오버라이드 하는 것

  => 매우 많은 수고 필요, 기반 클래스에 새로운 메소드가 추가되었을 때는 속수무책

2. 파생 클래스가 상속을 원치않는 기반 클래스의 메소드(Clear())에서 예외를 던지는 방법

  => LSP를 어기는 것이면 결과적으로 OCP까지 지킬 수 없게 된다

       컴파일 에러를 런타임 에러로 바꾸는 문제를 가지게 된다.

* 구현 상속을 사용하면 기반 클래스를 수정할 떄마다 파생 클래스들이 제대로 작동하는지를 테스트 해야한다.

구성을 통한 해결 방법

class Stack
{

private int topOfStack = 0;

private ArrayList theData = new ArrayList();

public void push( Object article )
{ 

    theData.add( topOfStack++, article );
}
public Object pop()
{ 

    return theData.remove( --topOfStack );
}
public void pushMany( Object[] articles )
{ 

    for( int i = 0; i < articles.length; ++i )
    push( articles[i] );
}
public int size() // current stack size.
{ 

    return theData.size();
}

}

 * 기반 클래서를 수정할 때마다 파생 클래스를 검토해 보아야 한다면 이는 기반 클래스를 확장하고 있는 것이 아니라

   인터페이스를 구현하고 있는 것이다.

interface를 구현한 해결 방법

interface Stack

{
    void push( Object o );
    Object pop();
    void pushMany( Object[] articles );
   int size();
}

 class SimpleStack implements Stack
 {
     private int topOfStack = 0;
     private ArrayList theData = new ArrayList();

     public void push( Object article )
     {

          theData.add( topOfStack++, article );
     }

     public Object pop()
    {

    return theData.remove( --topOfStack );

}

 public void pushMany( Object[] articles )
 {

for( int i = 0; i < articles.length; ++i )
 push( articles[i] );

 }

 public int size() // current stack size.
 {

return theData.size();

      }

 }

     class MonitorableStack implements Stack

{
     private int highWaterMark = 0;
     private int lowWaterMark = 0;

 SimpleStack stack = new SimpleStack();

 public void push( Object o )
 { 

 stack.push(o);

 if( stack.size() > highWaterMark )
 highWaterMark = stack.size();

}

public Object pop()

{
     Object returnValue = stack.pop();
     if( stack.size() < lowWaterMark )
     lowWaterMark = stack.size();
     return returnValue;

}

 public void pushMany( Object[] articles )
 {

      for( int i = 0; i < articles.length; ++i )
      push( articles[i] );

      if( stack.size() > highWaterMark )

      highWaterMark = stack.size();
 }

 public int maximumSize() { return highWaterMark; }
 public int minimumSize() { return lowWaterMark; }
 public void resetMarks () { highWaterMark = lowWaterMark = size(); }
 public int size() { return stack.size(); }

    }

결론

구현 상속은 구현이 편리한 대신 위험하고, 인터페이스 상속은 안전한 대신 구현이 고될 수 있다. 이클립스와 같은 IDE가 고됨을 대신해 준다. 가능하면 인터페이스 상속을 사용하라

An enum pattern, in which each enumerated case is associated to an instance of a generic attribute class, is identified and implemented. It is particularly useful in situations where there is a finite number of cases and each case is characterized by a set of constants.

void f()
{ 

LinkedList list = new LinkedList();
//...
modify( list );

}

void modify( LinkedList list )

{

list.add( ... );
doSomethingWith( list );

}

f()
{
    Collection c = new HashSet();
    //...
    examine( c );
}
void examine( Collection c )
{

 for( Iterator i = c.iterator(); i.hasNext() ;)

 //...

}

void f()
{
    Collection c = new HashSet();
    //...
    examine( c.iterator() );
}

void examine( Iterator i )
{ 

for(; i.hasNext() ; i.next() )
//...

}