linuxism

컴퓨터 과학에서의 디자인 패턴

소프트웨어 개발 방법에서 사용되는 디자인 패턴은, 프로그램 개발에서 자주 나타나는 과제를 해결하기 위한 방법 중 하나로, 과거의 소프트웨어 개발 과정에서 발견된 설계의 노하우를 축적하여 이름을 붙여, 이후에 재이용하기 좋은 형태로 특정의 규약을 묶어서 정리한 것이다. 알고리즘과 같이 프로그램 코드로 바로 변환될 수 있는 형태는 아니지만, 특정한 상황에서 구조적인 문제를 해결하는 방식을 설명해 준다.

이 용어를 소프트웨어 개발 영역에서 구체적으로 처음 제시한 곳은, GoF(Gang of Four)라 불리는 네명의 컴퓨터 과학 연구자들이 쓴 서적 'Design Patterns: Elements of Reusable Object-Oriented Software'(재이용 가능한 객체지향 소프트웨어의 요소 - 디자인 패턴)이다. GoF는 컴퓨터 소프트웨어 공학 분야의 연구자인 에릭 감마, 리차드 헬름, 랄프 존슨, 존 블리시디스의 네명을 지칭한다.

[편집]디자인 패턴과 패턴 학회

GoF의 디자인 패턴과 그 멤버들 그리고 패턴에 관심을 갖는 학자, 엔지니어, 출판업자들이 모여서 PLoP라는 학회를 시작하게 된다. 1994년부터 시작된 학회는 2012년 현재까지 미국에서 각 주를 돌아가며, 전 세계의 패턴 저자 및 학습자들을 불러 새로운 패턴, 패턴언어, Agile등에 대해서 토의한다. 2010년도부터 AsianPLoP와 기타 Licensing된 미국밖 세계 PLoP움직임으로 퍼져나가고 있다. 한국에서도 KPLoP로 패턴저자인 손영수님과 그가 리딩하는 스터디 그룹인 EVA가 주축이 되어, 주요 국내 커뮤니티 행사등에서 패턴을 전도하고 있다.

public abstract class Pizza
{
    public abstract decimal GetPrice();
 
    public enum PizzaType
    {
        HamMushroom, Deluxe, Seafood
    }
    public static Pizza PizzaFactory(PizzaType pizzaType)
    {
        switch (pizzaType)
        {
            case PizzaType.HamMushroom:
                return new HamAndMushroomPizza();
 
            case PizzaType.Deluxe:
                return new DeluxePizza();
 
            case PizzaType.Seafood:
                return new SeafoodPizza();
 
        }
 
        throw new System.NotSupportedException("The pizza type " + pizzaType.ToString() + " is not recognized.");
    }
}
public class HamAndMushroomPizza : Pizza
{
    private decimal price = 8.5M;
    public override decimal GetPrice() { return price; }
}
 
public class DeluxePizza : Pizza
{
    private decimal price = 10.5M;
    public override decimal GetPrice() { return price; }
}
 
public class SeafoodPizza : Pizza
{
    private decimal price = 11.5M;
    public override decimal GetPrice() { return price; }
}
 
// Somewhere in the code
...
  Console.WriteLine( Pizza.PizzaFactory(Pizza.PizzaType.Seafood).GetPrice().ToString("C2") ); // $11.50
...

//Our pizzas
function HamAndMushroomPizza(){
  var price = 8.50;
  this.getPrice = function(){
    return price;
  }
}
 
function DeluxePizza(){
  var price = 10.50;
  this.getPrice = function(){
    return price;
  }
}
 
function SeafoodPizza(){
  var price = 11.50;
  this.getPrice = function(){
    return price;
  }
}
 
//Pizza Factory
function PizzaFactory(){
  this.createPizza = function(type){
     switch(type){
      case "Ham and Mushroom":
        return new HamAndMushroomPizza();
      case "DeluxePizza":
        return new DeluxePizza();
      case "Seafood Pizza":
        return new SeafoodPizza();
      default:
          return new DeluxePizza();
     }     
  }
}
 
//Usage
var pizzaPrice = new PizzaFactory().createPizza("Ham and Mushroom").getPrice();
alert(pizzaPrice);

class HamAndMushroomPizza
  def price
    8.50
  end
end
 
class DeluxePizza
  def price
    10.50
  end
end
 
class SeafoodPizza
  def price
    11.50
  end
end
 
class PizzaFactory
  def create_pizza(style='')
    case style
      when 'Ham and Mushroom'
        HamAndMushroomPizza.new
      when 'DeluxePizza'
        DeluxePizza.new
      when 'Seafood Pizza'
        SeafoodPizza.new
      else
        DeluxePizza.new
    end   
  end
end
 
# usage
factory = PizzaFactory.new
pizza = factory.create_pizza('Ham and Mushroom')
pizza.price #=> 8.5
# bonus formatting
formatted_price = sprintf("$%.2f", pizza.price) #=> "$8.50"
# one liner
sprintf("$%.2f", PizzaFactory.new.create_pizza('Ham and Mushroom').price) #=> "$8.50"

# Our Pizzas
 
class Pizza:
    HAM_MUSHROOM_PIZZA_TYPE = 0
    DELUXE_PIZZA_TYPE = 1
    SEAFOOD_PIZZA_TYPE= 2
 
    def __init__(self):
        self.__price = None
 
    def getPrice(self):
        return self.__price
 
class HamAndMushroomPizza(Pizza):
    def __init__(self):
        self.__price = 8.50
 
class DeluxePizza(Pizza):
    def __init__(self):
        self.__price = 10.50
 
class SeafoodPizza(Pizza):
    def __init__(self):
        self.__price = 11.50
 
class PizzaFactory:
    def createPizza(self, pizzaType):
        if pizzaType == Pizza.HAM_MUSHROOM_PIZZA_TYPE:
            return HamAndMushroomPizza()
        elif pizzaType == Pizza.DELUXE_PIZZA_TYPE:
            return DeluxePizza()
        elif pizzaype == Pizza.SEAFOOD_PIZZA_TYPE:
            return SeafoodPizza()
        else:
            return DeluxePizza()
 
# Usage
pizzaPrice = PizzaFactory().createPizza(Pizza.HAM_MUSHROOM_PIZZA_TYPE).getPrice()
print "$%.02f" % pizzaPrice

Factory Method 패턴 (팩토리 메소드 패턴) ^[1] 은 GoF (Gang of Four; 4 명의 갱단들)에 의해 정의된 디자인 패턴 중 하나이다. Factory Method 패턴은 다른 클래스의 생성자를 서브 클래스에서 덮어쓸 수있는 자신의 메서드로 대체하여 응용 프로그램에 전문화된 객체의 생성을 서브 클래스로 내몰고, 클래스의 재사용성을 높이는 것을 목적으로한다.

Virtual Constructor 패턴이라고도 불리는 ^[1] .

목차   [ 숨기기 ]  1 클래스 다이어그램 2 이용 예 3 관계 패턴 4 Abstract Factory 패턴의 차이 5 관련 항목 6 참고 문헌

클래스 다이어그램 [ 편집 ]

Factory Method 패턴의 클래스 다이어그램 은 다음과 같다.

여기서 anOperation은 factoryMethod를 호출 Product 서브 클래스의 인스턴스를 얻고 이용한다. factoryMethod 같은 메소드는 factory method했다.

factoryMethod 기본 동작을 포함한 구체적인 방법이 될 수있다. 매개 변수를 그것에 의해 생성하는 클래스를 바꿀 수도있다. ConcreteCreator마다 작업 방법을 Product로 다른 클래스에 제공하는 케이스는 factoryMethod를 public으로 공개한다. ^{[1] .} 그러나 factoryMethod는 덮어 쓰지 가정이기 때문에 private로하지 않는다.

사용 예제 [ 편집 ]

예를 들어, Java List의 요소를 다양한 정렬하는 프로그램을 생각한다. 이 소스 코드는 J2SE 1.5 이상 버전에서 작동한다.

import  java.util.ArrayList ; 
import  java.util.Arrays ; 
import  java.util.Collections ; 
import  java.util.Comparator ; 
import  java.util.List ;
 
/ / Creator에 해당하는 
abstract  class ListPrinter { 
    / / anOperaton에 해당하는 
    public  void printList ( List < String > list )  { 
        Comparator < String > comparator = createComparator ( ) ; 
        list =  New ArrayList < String > ( list ) ;
 
        Collections . sort ( list, comparator ) ;
 
        for  ( String Item : list )  { 
            System . out . println ( item ) ; 
        } 
    }
 
    / / factoryMethod에 해당하는 
    protected  abstract Comparator < String > createComparator ( ) ; 
}
 
/ / ConcreteCreator에 해당하는 
class DictionaryOrderListPrinter extends ListPrinter {
    @ Override
    protected Comparator < String > createComparator ( )  { 
        return  New DictionaryOrderComparator ( ) ; 
    } 
}
 
/ / java.util.Comparator가 Product에 해당하는
 
/ / ConcreteProduct에 해당하는 
class DictionaryOrderComparator Implements Comparator < String >  {
    @ Override
    public  int Compare ( String str1, String str2 )  { 
        return str1. compareTo ( str2 ) ; 
    } 
}
 
/ / ConcreteCreator에 해당하는 
class LengthOrderListPrinter extends ListPrinter {
    @ Override
    protected Comparator < String > createComparator ( )  { 
        return  New LengthOrderComparator ( ) ; 
    } 
}
 
/ / ConcreteProduct에 해당하는 
class LengthOrderComparator Implements Comparator < String >  { 
    public  int Compare ( String str1, String str2 )  { 
        return str1. length ( )  - str2. length ( ) ; 
    } 
}
 
/ / 기본 클래스 
public  class FactoryMethodSample { 
    public  static  void Main ( String args [ ] )  { 
        List < String > list =  Arrays . asList ( "딸기" , "모모" , "무화과" ) ;
 
        System . out . println ( "가나다 순으로보기 :" ) ; 
        New DictionaryOrderListPrinter ( ) . printList ( list ) ;
 
        System . out . println ( ) ;
 
        System . out . println ( "길이 순으로보기 :" ) ; 
        New LengthOrderListPrinter ( ) . printList ( list ) ; 
    } 
}

이 프로그램은 다음과 같은 결과를 출력한다.

가나다 순으로보기 :
딸기
무화과
모모

길이 정렬 :
모모
딸기
무화과

상반기에 목록을 사전 순으로 표시하여 나중에 목록을 문자열 길이 순으로 표시하고있다. 목록을 정렬 바꾸어보기 ListPrinter # printList 메서드는 정렬 바꾸어 사용 Comparator를 생성할 때 new 연산자를 사용하여 직접 생성하는 것이 아니라 추상 메서드 createComparator를 사용하여 서브 클래스 생성을 맡긴다.

관련된 패턴 [ 편집 ]

factory method는 보통 template method ( Template Method 패턴 참조)이다 anOperation 호출된다. 그러나 factory method를 public으로 다른 클래스에서 부르는 경우도있다 ^[1] .

Abstract Factory 패턴 의 AbstractFactory 클래스는 factory method를 가지고 그것을 개별 서브 클래스가 재정 생성하는 Product를 바꾸는 수법이 일반적이다. 하지만 Prototype 패턴 을 사용하여 prototype과 객체의 변경에 의해 생성하는 Product를 바꾸는 방법도있다 ^[1] .

Abstract Factory 패턴의 차이 [ 편집 ]

"객체 지향의 재사용을위한 디자인 패턴"에서는 Factory Method 패턴은 "클래스 패턴 '으로 분류되고있다. 반면 Abstract Factory 패턴은 "개체 패턴 '으로 분류되고있다.

Factory Method 패턴은 부모 클래스인 Creator 클래스가 자식 클래스이다 ConcreteCreator 클래스 객체의 생성을 맡긴다는, Creator 클래스와 ConcreteCreator 클래스와 관련이있다. 한편 Abstract Factory 패턴은 Client의 인스턴스가 ConcreteFactory의 인스턴스에 객체 생성을 맡긴다는 오브젝트 간의 관련이다.

관련 항목 [ 편집 ]

• Template Method 패턴
• Abstract Factory 패턴
• 디자인 패턴

참고 문헌 [ 편집 ]

1. ^ ^{A b C D e} 에릭 감마 , 랄프 존슨 , 리처드 헬름 , 존 부리시디스 (의), 그라 디 · 부찌 (서문),本位田신이치, 요시다 카즈키 (監訳), "객체 지향의 재사용을 위해 디자인 패턴 ", 소프트 뱅크 퍼블리싱 , 1995. ISBN 978-4-7973-1112-9 .

소프트웨어 공학에서 리팩토링(refactoring)은 주로 '결과의 변경 없이 코드의 구조를 재조정함'을 뜻한다. 주로 가독성을 높이고 유지보수를 편하게 한다. 버그를 없애거나 새로운 기능을 추가하는 행위는 아니다. 사용자가 보는 외부 화면은 그대로 두면서 내부 논리나 구조를 바꾸고 개선하는 유지보수 행위이다.

마틴 파울러의 저서 《리팩토링》에 다양한 리팩토링 패턴들이 정리되어있다. 그 중 대표적인 것 몇 가지를 들자면, 필드 은닉, 메소드 추출, 타입 일반화, 메소드 이름 변경 등이 있다.

 리팩토링 (refactoring)은 컴퓨터 프로그래밍 에서 프로그램 외부에서 본 동작을 바꾸지 않고 소스 코드 의 내부 구조를 구성한다. 어떤 리팩토링 기법의 총칭으로서 사용된다. 충분히 확립된 기술은 말할 수 없으며, "리팩토링"단어에 정확한 정의가있는 것은 아니다.

리팩토링 등장 경위와 목적 [ 편집 ]

리팩토링이 등장하기 전에는 일단 정상적인 작동을하는 프로그램 은 다시 닿으 안된다라고했다. 섣불리 손을 넣어 동작이 바뀌어 버리면, 이에 따라 관련 부분에 수정이 가해 곧 수정 프로젝트 전체에 파급 대처할 수 없게 될지도 모른다. 또한 소프트웨어 테스팅 을 충분히하고 정상적인 동작이 확인 되더라도 해당 프로그램을 조금이라도 변경하면 버그 (결함)이 발견되면 수정이 프로그램을 의심해야한다.

그러나 프로그램에는 반드시 변화가 있고 프로그램은 다만 누더기 투성이가되는 것은 불가피하다. 사양 개발 시작부터 확정되어있는 것은 적고, 개발을하고있는 동안에도 소프트웨어 에 대한 요구는 나날이 계속 변하고 있으며, 소프트웨어는 항상 사양 변경에 대응할 수있는 유연성이 요구된다. 또한 아무리 엄격하게 디자인해서 실제로 작동시키지 않으면 모르는 부분도 많고, 완벽한 설계를 실시하는 것은 불가능하다. 변경이 필요할 때 다시 손을 대지 못할 정도 복잡하게 된 소스 코드 를 수정하는 것은 곤란하고, 프로그래머 도 매우 용기가 요구되는 작업이다.

그래서 Smalltalk 프로그래머 등 사이에 평소부터 프로그램을 정리 사양 변경에도 대응할 수있는 정리 프로그램을 써 나갈 생각이 태어났다. 이 과정은 워드 커닝햄 , 켄트 벡 , 랄프 존슨 ( GoF 의 한 명) 등의 사람들이 큰 역할을했다. 이 기법을 리팩토링이라고있다. 또한 리팩토링은 프로그램의 전모를 파악하기 위해서도 효과적이다.버그를 발견했을 때도 소스 코드가 정리되고 있기 때문에 수정하다. 프로그래머로 평소 수정하는 코드에 다시 손을 넣는 것만 때문에 수정도 적극적으로 될 수있다. 또한 설계자는 설계 오류로 인한 아쉬움을 없앨 수있다. 디자인의 대체도된다고하는 의견도 사전 설계를 매우 단순화하는 역할도 가진다.

리팩토링은 객체 지향 디자인과 깊이 관련되어있다. 리팩토링의 대부분은 객체 지향의 성질에 따른 것이며, 객체 지향 코드 재사용 성을 극대화할 수있다. 객체 지향 프로그래밍을 할 수있는 언어라면 프로그래밍 언어 의 종류에 관계없이 리팩토링을 적용할 수있다.

리팩토링을 수행함으로써 개발이 정체되어 버리는 것은 아닌가하는 걱정을하는 경우도 많다. 리팩토링을 수행하는 동안 아무런 기능 추가도 행해지지 않는다. 그러나 대부분의 경우 디자인이 향상하는 것으로 기능 추가 및 버그 수정을하기 쉽고, 개발 속도는 안정뿐만 아니라, 빨리 될 수도있다. 또한 이미 작동하는 코드를 위태롭게한다 없다고하는 의견도 있지만, 절차를 준수 테스트를 많이 사용하면 어느 정도 위험을 줄일 수있다.

주요 리팩토링 [ 편집 ]

메서드 추출

너무 메서드는 재사용성이 낮다. 메서드를 추출, 분할함으로써 재사용성이 높아지고, 호출 메소드의 내용도 읽기 쉽게된다. 처리 중복도 줄어든다.

양방향 연관을 단 방향으로 변경

불필요한 참조 관리를위한 수고를 늘리고 개체 의 삭제를 실패한다. 필요없는 연관 지운다.

클래스 추출

너무 자라 클래스를 분할한다. 클래스를 작게하는 것으로 그 클래스의 역할을 명확하게있다.

switch 문장 을 다형성 으로 교체

switch 문을 다형성로 대체하여 새로운 조건이 추가되어도 분기 부분은 변경할 필요가 없어진다.

멤버 이동

필드 및 메서드가 잘못된 클래스의 경우, 다른 클래스와 불필요한 관련이 늘어난다. 멤버를 이동하여 클래스의 책임을 구성합니다.

상속 을 위임 으로 대체

상속에서는 기본 클래스의 모든 멤버를 하위 클래스로 용서해야한다. 기본 클래스의 부분 기능을 이용하면 상속 대신 위임을 사용한다.

다운 캐스트 를 캡슐 화 한다

다운 캐스팅은 호환되지 않는 형식으로 변환시킬 수 있지만, 그것을 컴파일시 감지 할 수 없다. 일반 유형 ( 템플릿 )이없는 언어는 캡슐화하고 클라이언트 다운 캐스트의 수고를 줄일 수 있도록한다. 컬렉션 클래스 등으로 특히 필요합니다.

생성자를 Factory Method 로 대체

생성자는 해당 클래스의 개체를 반환할 수 밖에 없다. Factory Method의 소개로 유연한 인스턴스 화가 가능하게된다.

인수 개체의 도입

종종 함께 전달되는 여러 값을 개체로 정리한 것이 알기 쉽다.

클래스 메소드 속성의 이름을 변경하려면

클래스 이름과 메서드 이름과 속성 이름은 해당 클래 스나 메소드의 역할을 정확하게 설명합니다 할 필요가있다. 명칭이 잘못된 것이거나, 애매한 것이다 때는 명칭의 변경이 행해진다. 종종 처음에는 제대로였다 명칭도 다른 리팩토링 실행 후 적절한 분실될 수있다. 이 때는 계속 이름 변경 리팩토링을 수행하는 (⇒ 명명 규칙 (프로그래밍) ).

마틴 파울러 같은 사람이 쓴 리팩토링 해설서, "리팩토링 프로그래밍의 체질 개선 기술"(이하 "리팩토링")에서는 70여 가지의 리팩토링을들 수있다.

리팩토링을 할 타이밍 [ 편집 ]

언제든지 뭐든지 리팩토링을하면된다는 것은 아니다. 납기가 빠듯한 다가온 경우에 리팩토링을하고있을 여유는없고, 리팩토링은 장래에 대비하여 실시하는 것으로 인해 그 리팩토링이 결실을 맺을 가능성은 적다. 또한 리팩토링이라고해도 역시 프로그래밍이기 때문에, 항상 오류를 위험은 지울 수 없다.

"리팩토링"에서는 기능을 추가하는 것과 리팩토링 때 명확하게 구별하는 것을 권장하고있다 (이 일을 비유하며 " 구현 모자를 리팩토링 모자 쓰고 다시 "이라한다). 리팩토링 만있어 개발은 진행하지 않으며, 어떤 리팩토링을해야할지 어느 정도 개발이 진행 않으면 모른다. 리팩토링을 시작하는 타이밍으로 코드 " 불길한 냄새 "를 느끼기 시작하면, 제안하고있다. 이것은 유사한 코드 중복과 너무 긴 메소드, 하나의 변경 때마다 여러 클래스가 영향을받는 등의 증상이 발견된 경우를 가리킨다. 또한 기능 추가 전 코드 검토 시 버그 수정 시에도 리팩토링을 권장하고있다.

테스트의 중요성 [ 편집 ]

프로그램의 모양을 변경해야하기 때문에 리팩토링에 대해서는 테스트 가 매우 중요하다. 수정 단계적이고 조금씩하고 약간의 변경 때마다 테스트를 실시하는 것으로 동작의 이상을 재빨리 감지한다. 테스트없이 한 번에 리팩토링하면 프로그램의 동작이 어느새 바뀌어 버리고도 원인이 부위를 알 수 어려워진다. 프로그래머 테스트를 빼먹지하지 않기 때문에 간단하게 테스트를 수행할 수있는 도구 ( xUnit / JUnit 등)도 필요하다. 또한 테스트를 중요시하는 것은 민첩한 소프트웨어 개발 의 일부 개발 방법 ( 익스 트림 프로그래밍 등)의 " 테스트 우선 "나" 테스트 주도 개발 "의 개념 과도 일치한다.

리팩토링의 과제 [ 편집 ]

리팩토링도 일부 문제가 존재한다. 예를 들어 데이터베이스 에서 변경하는 경우 데이터 마이 그 레이션을 할 필요가있다. 중간 계층을 사이에 두는 것으로 영향을 완화 수 있지만, 역시 시간이 걸리는 것은 부정할 수 없다. 또한 리팩토링은 종래와 같이 캡슐화된 클래스뿐만 아니라 인터페이스 도 변경할 수있다. 그것은 널리 공개된 인터페이 스인 경우 새 인터페이스와 이전 인터페이스를 모두 관리해야한다. 또한 수정하는 코드가 너무 심한 상태의 경우 새로 고쳐 쓴 것이 빠른 경우도있다. 아직 개발 기술을 위해 앞으로 여러 가지 문제가 발견될 가능성은있다.

통합 개발 환경의 리팩토링 기능 [ 편집 ]

최근 통합 개발 환경 에는 리팩토링 기능이있는 것이 많다. 리팩토링은 수정되는 메서드 또는 클래스가 어떤 클래스에서 이용되고 있는지 조사할 필요가 발생한다. 이것을 단순한 텍스트 편집기 에서 알아보자하면 꽤 귀찮은 작업이 될 위, 간과을 가능성도 높다.

관련 항목 [ 편집 ]

• 민첩한 소프트웨어 개발 - 익스 트림 프로그래밍 과 같은 몇 가지 개발 방법에서는 개발의 습관 중 하나는 리팩토링을 들고있다.
• xUnit / JUnit - 테스트 를위한 프레임 워크. JUnit은 Java 프로그램의 테스트 프레임 워크이다.
• Eclipse - 통합 개발 환경 . 수많은 리팩토링 기능이있다.
• 소프트웨어 유지 보수
• 코드 냄새

참고 문헌 [ 편집 ]

• 마틴 파울러 외 "리팩토링 : 프로그래밍의 체질 개선 기술"피어슨 에듀케이션, 2000 년 ISBN 4894712288