Whiteship's Note


객체지향 디자인 원칙

Design Pattern : 2006.12.11 15:46


바뀌는 부분은 캡슐화한다.

상속보다는 구성을 활용한다.

구현이 아닌 인터페이스에 맞춰서 프로그래밍 한다.

서로 상호작용을 하는 객체 사이에서는 가능하면 느슨하게 결합하는 디자인을 사용해야 한다.


클래스는 확장에 대해서는 열려있지만 변경에 대해서는 닫혀 있어야 한다.

추상화된 것에 의존하라. 구상 클래스에 의존하지 않도록 한다.

친한 친구들하고만 이야기한다.

먼저 연락하지 마세요. 저희가 연락드리겠습니다.

어떤 클래스가 바뀌게 되는 이유는 한 가지 뿐이어야 한다.


원칙은 원칙일뿐 목적이나 법칙은 아닙니다.

참조 : Head First Design Patterns


ps : 시험 끝~~~~~~~

'Design Pattern' 카테고리의 다른 글

프록시(Proxy) 패턴  (0) 2008.09.26
JUnit 공부하자.  (0) 2008.09.01
H.F.OOAD 5장 문제  (0) 2007.11.20
상위 클래스 보다는 인터페이스를...  (4) 2007.08.31
Singletons and lazy loading  (2) 2007.01.27
객체지향 디자인 원칙  (2) 2006.12.11
Losely Coupled를 활용하라.  (0) 2006.12.11
상속보다는 구성을 활용한다.  (0) 2006.12.11
바뀌는 부분을 캡슐화 한다.  (0) 2006.12.11
State Pattern 예제  (2) 2006.12.10
캡슐화  (0) 2006.12.09
top

  1. zerry82 2006.12.11 18:13 PERM. MOD/DEL REPLY

    니마 추카영 ㅋㅋ

    Favicon of http://whiteship.tistory.com/ BlogIcon 기선 2006.12.11 20:33 PERM MOD/DEL

    동규사마 감사영

Write a comment.


State Pattern 예제

Design Pattern : 2006.12.10 10:42


문제 : 2) [30점]  State pattern에서 공짜 알맹이 당첨 기능을 추가 하고 반응이 좋아 다른 한 가지 변경을 다하고자 한다. 현제의 기계에서는 한 번에 하나의 동전만 넣을 수 있다. 다른 뽑기 기계에서와 같이 한꺼번에 2개, 3개, 혹은 원하면 더 많은 동전을 넣을 수 있도록 하는 기능을 추가 해 달라는 요청이다.
   a. [10점] 확장된 state diagram을 그려라.
   b. [10점] State Pattern을 적용하지 않은 경우를 구현하라.
   c. [10점] State Pattern을 적용한 시스템을 구현하고, 패턴을 적용하지 않은경우와 비교해서 확장이 얼마나 쉬워 졌는지 설명하라.

A.
사용자 삽입 이미지

B. 각각의 상태를 flag로 두고 각 메소드 안에서 if-else문을 엄청나게 사용하여 구현을 해보라는 것인 것 같군요.

C. 새로운 상태(동전이 여러개인 상태)를 동전 있슴 State의 하위 클래스로 상속을 사용한 뒤 필요한 메소드를 오버라이딩 하면 될 것 같습니다.

자~ 이제 코딩하자 기선아.

'Design Pattern' 카테고리의 다른 글

Singletons and lazy loading  (2) 2007.01.27
객체지향 디자인 원칙  (2) 2006.12.11
Losely Coupled를 활용하라.  (0) 2006.12.11
상속보다는 구성을 활용한다.  (0) 2006.12.11
바뀌는 부분을 캡슐화 한다.  (0) 2006.12.11
State Pattern 예제  (2) 2006.12.10
캡슐화  (0) 2006.12.09
H.F. Design Pattern 트집잡기  (4) 2006.12.09
Design Pattern 기말고사  (0) 2006.12.08
Template Method Pattern을 사용하는 QuickSorting  (0) 2006.12.08
Simple Factory  (4) 2006.11.13
top

  1. zerry82 2006.12.10 12:54 PERM. MOD/DEL REPLY

    재밌는 시험이다..!!!

    Favicon of https://whiteship.tistory.com BlogIcon 기선 2006.12.10 22:57 신고 PERM MOD/DEL

    재밌긴 한데 시간을 많이 잡아먹는거~

Write a comment.


H.F. Design Pattern 트집잡기

Design Pattern : 2006.12.09 00:33


2장 p80쪽에 나오는 getter들과 p105쪽에 구현되어 있는 getter들이 일치 하지 않음.

3장 p129쪽에 나오는 다이어그램이 보여주고 있는 UML의 선이 나타내는 의미와 클래스안에 있는 표기된 멤버가 일치하지 않음.

5장 Lazy instantiation을 '게으른 초기화'로 번역하고 있슴.

7장 p286쪽 맨 아래에 보면 Enumerator 인터페이스를 사용하다가 전부 Iterator만 사용하도록 바꿀 것이라고 합니다. 그리고 다음 장 부터 Iterator 인터페이스를 어댑터 패턴을 이용해서 내부적으로는 Enumerator를 사용하도록 해주는 클래스를 만들기 시작합니다,.

8장 p338쪽 하단에 mergeSort() 메소드가 있는데 안에 보면 전혀 머지 소트가 아닙니다.

이 글을 참고 or 배낄지도 모를 저와 같은 학부 학생들에게...

'Design Pattern' 카테고리의 다른 글

Losely Coupled를 활용하라.  (0) 2006.12.11
상속보다는 구성을 활용한다.  (0) 2006.12.11
바뀌는 부분을 캡슐화 한다.  (0) 2006.12.11
State Pattern 예제  (2) 2006.12.10
캡슐화  (0) 2006.12.09
H.F. Design Pattern 트집잡기  (4) 2006.12.09
Design Pattern 기말고사  (0) 2006.12.08
Template Method Pattern을 사용하는 QuickSorting  (0) 2006.12.08
Simple Factory  (4) 2006.11.13
Principle of Least Knowledge  (4) 2006.11.11
Adapter Pattern  (0) 2006.11.11
top

  1. Favicon of http://chanwook.tistory.com/ BlogIcon 찬욱 2006.12.09 01:04 PERM. MOD/DEL REPLY

    저는 가끔 무모한 짓을 시도하곤 하죠...ㅋ

    Favicon of https://whiteship.tistory.com BlogIcon 기선 2006.12.09 01:35 신고 PERM MOD/DEL

    --; 지울까 이미 늦었군 ㅠ.ㅠ

  2. 수봉 2006.12.09 13:13 PERM. MOD/DEL REPLY

    한가지 빠졌네요. 마지막에 나왔던 스테이트 패턴에서의 문제..

    Favicon of http://whiteship.tistory.com/ BlogIcon 기선 2006.12.09 14:52 PERM MOD/DEL

    엇 그건 뭐였죠 아 기억력 감퇴 ㅠ.ㅠ

Write a comment.


엔터프라이즈 컴퓨팅 1)-2

Design Pattern : 2006.10.23 21:18


 2. 2차 확장/변경(1년이 지난 후)

       다.[10점] 김치피자가 인기가 좋아서 뉴욕과 시카고에서도 치피자를 메뉴에 추가 하고자 한다. Dough는 밥 대신 시카고에서 사용하는 ThickCrustDough를 사용한다. 뉴욕에서는 된장이 쉽게 구할 수 있지만 시카고에서는 한국된장이 쉽게 구할 수 있는 재료가 아니라서 일본된장을 사용하기로했다.






top

Write a comment.


엔터프라이즈 컴퓨팅 중간고사 1)-1-나

Design Pattern : 2006.10.23 21:16


나.[10점] 서울분점에서는 메뉴에 김치피자를 추가 하고자 한다. 김치피자에서는 Dough를 밥으로 만들어야 하고, 치즈대신 된장을 사용한다.



top

Write a comment.


엔터프라이즈 컴퓨팅 중간고사 1)-1-가

Design Pattern : 2006.10.23 21:14


 1) [30점] 교과서 4장의 문제를 확장/변경 하고자 한다. 여러 가지 확장/변경의 가능성이 있다. 이번 문제에서는 2차에 걸쳐서 확장/변경 하고자 한다. 프로그램에서 고친 부분을 보여라. 디자인 패턴을 사용해서 어떤 부분이 확장/변경이 용이하도록 해 주었는지 설명하라.

 

1. 1차 확장/변경

     

  가.[10점] 서울에 분점을 내고자 한다. 일반적으로 뉴욕의 피자와 같지만 서울

          사람들은 치즈를 좋아하지 않아서 일반적인 경우의 1/2만 사용한다. 그리고

          페퍼로니 피자의 경우 짜지 않은 “야채페퍼로니”를 사용한다.




top

Write a comment.


Decorator Pattern 예제

Design Pattern : 2006.10.20 16:35


데코레이터 패턴 레포트 상세 내용

게임게발을하고 있습니다. 각 케릭터는 인간이라는 한 종족으로시작을 하게 되며

한 종족은 전사, 마법사, 도둑세 가지의 직업을 가지게 됩니다. 각 케릭터가 착용하게 되는 아이템은 무기, 방어구를 착용하게 됩니다. 그리고 모든 직업은 공통적으로 HP, MP라는 속성값을 가지게 됩니다.

케릭터를생성하여 전사, 마법사, 도둑 세가지의 직업으로 나누어서각 케릭이 어떠한 직업을 가지고 어떠한 이름을 가지고 있는지 보여줍니다. 그 후 아이템을 습득하여 무기및 방어구를 습득하여서 어떠한 아이템을 착용했는지 그리고 그 아이템은 어떠한 상세 내용을 가지고 있는지에 대한 메시지를 창에 보여주게 됩니다.

또한케릭터가 독에 걸리거나 상처를 입는 등 상태이상에 걸리게 되면 케릭터가 상태이상에 걸렸다는 메시지를 창에 보여주면 됩니다.

각 아이템은 다음 예제와 같은 상세한 세부내용이 있습니다.

무기 예제

단검                               데미지 1~10

롱소드                             데미지 10~20

바스타드 소드                      데미지 10~20

방어구 예제

가죽 갑옷                          방어 확률 10%

플레이트 아머                      방어 확률 20%

풀플레이트 아머                    방어 확률 30%

상태이상은 다음 예제와 같은 상세한 세부내용이 존재합니다.

가시독

이동속도가 느려집니다.

맹독

케릭터의 HP가 감소됩니다.

마나독

케릭터의 MP가 감소됩니다.

질병

질병

케릭터의 HP, MP가 감소됩니다.

상처

케릭터가 부상을 입어 활동을 할 수 없습니다.

오.. 지쟈스.. 클래스가 몇개인고.. 이것도 월요일까지 제출해야 한다는거~

오늘 일단 이것부터 해결해야겠군요..

top

Write a comment.


엔터프라이즈 컴퓨팅 중간고사

Design Pattern : 2006.10.18 14:11


이런 것이야 말로 진짜 시험 아닌가... 저는 그렇게 생각합니다.
5박 6일 짜리 taking home 시험 이랍니다. 하루에 하나씩 풀어야겠네요.


교수님 개그 센스가 쥑여 주십니다! (__)/
top

  1. Favicon of https://whiteship.tistory.com BlogIcon 기선 2006.10.18 14:21 신고 PERM. MOD/DEL REPLY

    일단 내일은 암기과목이 있기 때문에... 10점 짜리 중에 하나 풀어야겠네요.

  2. Favicon of https://springframework.tistory.com BlogIcon 영회 2006.10.18 14:47 신고 PERM. MOD/DEL REPLY

    내용은 읽어볼 엄두가 나지 않지만...
    taking home이라는 점이 재밌네.

    어차피 요즘은 대부분의 중요한 문제 해결을 위해서 다른 사람, 검색 등의 도움을 받아야 하니까 시험도 그렇게 치르는 것이 도움이 될 수도 있겠다.

    Favicon of https://whiteship.tistory.com BlogIcon 기선 2006.10.18 15:55 신고 PERM MOD/DEL

    네.. 딱 책만 외워서 치는 시험은 책 안에만 국한되고..사실 외울 필요도 없자나요. 그냥 찾아보면 나오는건데;;

    그런데 책 만가지고 풀지 못하는 문제들을 내주시고 당연히 모든 자료를 이용가능 하도록 하는 문제들은.. 문제 해결 방법을 찾아내는 연습을 할 수 있어서 너무 좋아요. ㅋㅋ

Write a comment.


3장. Decorator Pattern(계속)

Design Pattern : 2006.10.17 17:38


이 전 글을 보시면 새로운 첨가물이 추가 될 때마다 Beverage class가 변하게 됩니다. 구체적으로 cost() 메소드가 변하게 되는 거죠. 이 말은 다시 새로운 Class가 추가될 때 마다 기존 Class가 변하게 되고 따라서 다시 컴파일 -> 배포 과정을 거쳐야 한다는 것인데.. 이러면 상당히 불편합니다. 새로운 class를 추가하면서도 기존의 class가 변하지 않을 그런 방법 없을까요? 이것과 관련된 원칙이 하나 있습니다.

OCP(Open-Closed Principle)는 가장 중요한 디자인 원칙 중 하나라고 합니다.

디자인 원칙6
클래스는 확장에 대해서는 열려 있어야 하지만 코드 변경에 대해서는 닫혀 있어야 한다.

기존 코드는 변경에 닫혀 있어야 하고 새로운 행동을 마음 껏 추가할 수 있어야 한다는 말인데요. 자칫 모순 같아 보이지만 상황이나 문맥을 잘 살펴보시면 분명 모순되는 말은 아닙니다.

그리고 이것과 관련된 ZDnet의 글도 있는데요. 읽어봤는데 H.F보다 더 많은 내용(H.F.는 2페이지, 저 글은 13페이지)을 적어 놓은 듯하네요.

이제 OCP를 달성하게 해주는 디자인 패턴 들 중에 하나로 Decorator Pattern을 배워 봅시다. 이름에서도 벌써 어떤 패턴일지 대강 감이 오시지 않나요.

객체를 장식(실제로는 감싸는 wrapping(?)이라고 생각하시면 쉬울 듯 합니다.)하고 또 다시 그 객체를 장식하고..그러한 식으로 구성하는 것이 가능하도록 해주는 패턴입니다.

여기 DartRoast 객체가 있습니다. 이 객체는 Beverage를 상속 받은 음료 수 중 하나죠. 따라서 cost() 메소드를 가지고있을 것입니다. 이 객체에 Mocha(첨가물 중 하나입니다.)를 얻으면 가격이 추가되겠죠. 이 때 이 첨가물로 DarkRoast를 감싸는 것입니다.

이렇게 Mocha로 DarkRoast를 감싼 뒤 가격을 구하고 있다면 Mocha에 있는 cost()를 호출하는 거죠. 그러면 그 메소드 안에서는 Mocha가 가지고 있는 DarkRoast의 cost()를 호출 한 뒤에 거기에 자신의 가격(모카가격)을 더하면 되겠습니다. 즉 여기서 Mocha가 DarkRoast를 감싼 다는 것이 Mocha가 DarkRoast를 멤버로 가지고 있다고 생각하시면 되겠습니다.
이러한 순으로 가격 계산하는 과정이 진행됩니다.

이제 데코레이터 패턴의 정의를 살펴봅시다.

데코레이터 패턴에서는 객체에 추가적인 요건을 동적으로 첨가한다. 데코레이터는 서브클래스를 만드는 것을 통해서 기능을 유연하게 확장할 수 있는 방법을 제공한다.


하지만 단순이 상속을 통해서만 그렇게 자유로워 지는 것은 아니고 컴포지션도 한몫합니다. 결국 상속과 컴포지션의 합작품이지요.

클래스 다이어그램으로 살펴 봅시다.


wikipidia에 있는 그림입니다. 새로 그리기가 귀찮아서요 ^^;;. 저는 이 다이어그램을 보고 처음에 굉장히 놀랬었습니다. 왜냐면 상속과 컴포지션을 동시에 사용했기 때문이지요. 클래스를 재사용하는 방법 중에 가장 먼저 떠오르는 두가지 방법을 그것도 동시에 두 클래스 사이에 모두 사용한 것이 제 사고의 편협함을 꼬집어 주더군요. 상속하든가.. 컴포지션 하든가.. 이런 생각을 가지고 있던 저는 마치 흑백논리에 빠져있었던 사람 같은 기분이였습니다.

위 다이어그램을 보시면 Decorator가 Component를 상속하면서 동시에 컴포지션으로 상위 클래스 타입의 멤버를 가지고 있습니다. 이 말은 상위 클래스의 모든 하위 클래스들을 Decorator에서 멤버 변수로 가지고 있을 수 있다는 뜻인데요. Decorator 자신도 또한 Component의 하위 클래스 이므로.. 자기 자신을 멤버 변수로 가지고 있을 수 있다는 것입니다. 물론 ConcreteComponent들도 Decorator의 들이 멤버 변수로 가지고 있을 수 있겠죠.

이 놀라움을 감상하며 잠시 시간을 보낸 뒤 다음에는 스타버즈 커피숍의 문제에 적용해보도록 하겠습니다.


ps : 여기서 궁금한 것은 데코레이터 패턴이 확장에 열려있게 된 것은 알 수 있었습니다. 하지만 변화에는 어떻게 닫혀 있다는 것일까요.. 이 패턴을 사용함으로 써 더이상 cost() 메소드에 변화가 가지 않게 되어 변화에 닫히게 되었다는 것일까요?.. ZDnet의 글을 보신 분들은 interface를 사용하여 변화에 닫히고 확장에 열리는 설계를 보셨을것입니다. 여기서는 interface가 보이지 않는데.. 어떻게 된 일일까요.. 좀더 생각히 필요하네요..

top

  1. Favicon of https://whiteship.tistory.com BlogIcon 기선 2006.10.22 21:08 신고 PERM. MOD/DEL REPLY

    변화에 닫혀있다는 말은 새로운 클래스를 추가하여도 기존의 코드가 변경되지 않거나 변하는 부분이 최소화 되어있다는 말을 의미하니까.. 데코레이터 패턴은 새로운 데코레이터 클래스들이 추가 되더라도 기존의 코드에 영향을 주지 않기 때문에.. 변화에 닫혀 있다는 것 같군요.

Write a comment.


3장 Decorator Pattern

Design Pattern : 2006.10.17 16:39



이번에는 스타버즈의 메뉴를 class diagram으로 그린 것입니다.
기본적인 Beverage class를 상속 받는 방식으로 새로운 메뉴를 생성하고 있습니다.
만약..커피를 주문할 때 우유,  두유, 모카, 크림과 같은 첨가물을 추가하는 경우 각각이 다른 class로 생성하여 상속 받게 됩니다. 즉, 모카 커피 class, 두유 커피 class, 우유 커피 class, 크림 커피 class, 우유 모카 커피 class..... 이런 식으로 하위 class가 무지막지하게 늘어나게 됩니다. 만약에 새로운 첨가물 하나가 추가 된다면 추가되는 class는 하나가 아닐 것입니다.
이런 방법은 별로 좋치 않겠군요.. 그래서 Beverage class에 첨가물들이 들어 있는지에 대한 boolean 변수(플래그-flag)를 만들어 두고 cost() 메소드 안에서는 첨가물이 들어있는지 확인하고 첨가되어있는 첨가물의 가격을 전부 더하는 내용을 넣어 둡니다.
그리고 이것을 상속받는 하위 클래스에서는 cost() 메소드를 상속받은 후 자기 자신의 가격(커피, 에스프레소..등의 자체 가격)에 super.coast()를 호출하여 첨가물의 가격을 구해서 더하면 될 것입니다.
따라서 Beverage class가 다음과 같이 달라집니다.

Beverage class에 있는 cost() 메소드는 다음과 같습니다.
public class Berverage{
  public double cost(){
   if(hasMilk())
      cost += milkCost;
   if(hasSoy())
      cost += soyCost;
   ...
   return cost;
  }
}
이렇게 첨가되어 있는(hasXXX) 첨가물의 가격을 더해서 return합니다.
그러면 하위 class들의 cost에서는
public class HouseBlend{
  public double cost(){
   cost += super.cost();
   return cost;
  }
}
이렇게 해서 자기 자신(houseBlend의 가격)에 첨가물의 가격(super.cost())을 더해서 return하면 됩니다.
일단은 이 방법이 맨 처음에 사용했던 방법보다 간단해 보입니다.
적어도 class가 기하급수적으로 늘어나진 않으니깐요..
하지만 새로운 첨가물이 추가 될 때 마다 Beverage에 새로운 변수가 두개(첨가물의 가격, 첨가물의 첨가 여부를 나타내는 boolean변수)와 메소드 두개(setter와 hasXXX())가 생기며 cost() 메소드에 if문이 추가 되겠네요.
그리고 만약에 녹차가 새로 추가 됐는데 녹차에 크림을 얹는 일이 발생할 수도 있겠네요.
1장에서 장난감 오리가 날수 있던 것과 마찬가지 문제입니다.
앗 그리고 첨가물을 한번밖에 추가를 못하는 군요..
흠... 이런 문제를 해결하기 위해서든 뭔가 근본적인 디자인을 바꿔야 할 것 같군요..
다음에 계속 살펴보겠습니다.
top

Write a comment.


Observe Pattern 예제(끝)

Design Pattern : 2006.10.08 13:49




Auctioneer는 Subjct를 대신했고 Bidder는 Observer 인터페이스를 대신하도록 만들었다. 그리고 각각 ConcereAuctioneer와 ConcreteBidder 클래스를 작성하여 인터페이스를 통해 접근하도록 했다.

그리고 test 클래스를 작성하기 시작했다.

먼저 경매 물품이 나오고 (경매 시작 가격이 있을 것이라 생각했다.) 그다음 경매자들이 그 물품의 구독자(observer)로 등록이 되며(여기서는 구독자 List를 등록하도록 했으며 한명의 구독자를 등록하는 것도 가능하다.) 경매가 시작되면 경매 초기 가격을 모든 구독자들에게 알려 주도록 하였다.

작성된 실제 코드와 초기에 모델링 했던 클래스 다이어그램과는 차이가 있었다.

Auctioneer 인터페이스에서 Bidder를 List로 갖는것이 아니라 ConcereteAuctioneer에서 List로 갖도록 하였다. 인터페이스에 있는 필드에게는  public 만 허용이 되는데 public으로 List를 가지고 상속해서 사용한다면 언제든 List에 바로 접근하여 변경이 가능하다는 것인데 그렇게 되면 ConcreteAuctioneer에 있는 addBidder나 deleteBidder는 무용지물이 된다.

그리고 addBIdders에서 List를 통째로 추가하는 메소드를 추가하였는데 List로 추가를 하면 deleteBidder를 하기가 복잡해 진다. List를 통째로 추가하는 경우 해당 그룹에 있는 원소는 구독을 포기하기가 어렵게 되는데 그렇다면 그룹(List)으로 구독을 등록(add)하는 방법은 제거하고 개인별로(addBIdder) 구독하도록 하는 것이 상황에 맞을 듯하다.


위와 같이 test코드를 수정하고 JUnit을 실행시킨 콘솔 창의 결과물 입니다.


'Design Pattern' 카테고리의 다른 글

Decorator Pattern 예제  (0) 2006.10.20
엔터프라이즈 컴퓨팅 중간고사  (3) 2006.10.18
3장. Decorator Pattern(계속)  (1) 2006.10.17
3장 Decorator Pattern  (0) 2006.10.17
헤드 퍼스트 새책이 나왔었네요  (2) 2006.10.17
Observe Pattern 예제(끝)  (0) 2006.10.08
Observer Pattern 예제  (0) 2006.10.08
Strategy Pattern 예제(끝)  (0) 2006.10.08
Strategy Pattern 예제(계속)  (0) 2006.10.08
Strategy Pattern 예제(계속)  (0) 2006.10.08
Strategy Pattern 예제  (0) 2006.10.08
top

Write a comment.


Observer Pattern 예제

Design Pattern : 2006.10.08 12:02



Obsever Pattern은 1대 다 관계를 정의합니다. 따라서 한 객체의 상태가 바뀌면 다른 것들이 자동적으로 정보를 업데이트 받습니다.

Participant Correspondence:

  • auctioneer가 Subject에 해당합니다. Observer들은 그에게 등록을 해야하기 떄문에 당연히 그는 observer들을 알고 있습니다.
  • 현재 경매가(current bid)는 ConcreteSubject에 해당합니다. Observer들은 이것의 상태에 관심이 있습니다.
  • 경매 참가자(bidder)들은 Observer에 해당합니다. 그들은 현재 경매가가 어떻게 변하는지 알고 싶어합니다.
  • 각 개개인의 경매 참가자들은 ConcreteObservers에 해당하며 서로 다른 tolerance(한계)를 가지고 있습니다.

Consequences:

  • subject와 observer는 추상적으로 묶여 있습니다. actioneer가 아는 것은 경매 참여자(bidder)들이 단지 경매(bid)를 할 것이라는 것 뿐입니다. 개개인의 경매 참여자들이 돈을 얼마나 가지고 있는지는 모릅니다.
  • 의사소통을 위한 방송을 지원합니다. actioneer가 현재 물품가격을 발표하면 이 정보에 관심이 있는 모든 경매 참여자들에게 알려질 것입니다.
  • 경매 참여자들은 또한 예측 불가능한 가격 상승을 겪을 수 있습니다. subject의 상한가를 모르기 때문입니다. 따라서 50$까지만 가격을 불러보고 그만 둘 수도 있습니다.

top

Write a comment.


Strategy Pattern 예제(끝)

Design Pattern : 2006.10.08 11:32


Worker List Manager의 class diagram에 추가 사항.
위에서 생각해 보았던 문제가 들어맞았다...
필요없이 모양에 끼워 맞추려다가 오히려 복잡해지기만 했다.
그래서 과감히 필요없는 부분은 제거했다.

보라색 부분에 있던 sub class들을 몽땅 없애버렸다.
WorkerListManager를 사용해서도 충분히 지시된 사항들이 가능하기 때문이다.
나중에 필요하게 되면 다시 상속을 하여 사용하도록 하면 될 듯하다.
유지보수 측면을 따지자면.. 새로운 종류의 Worker들이 나타나면 소스코드가 상당히 바뀌게 된다는 문제점도 있다.. 그쪽도 어떻게든 해결을 해야 될 것 같은데.. 일단은 이상태로 제출을 해도 무관할 듯하다. 설마 교수님께서 이 글을 보시진 않으시겠지?? ㅋㅋ;;

'Design Pattern' 카테고리의 다른 글

3장. Decorator Pattern(계속)  (1) 2006.10.17
3장 Decorator Pattern  (0) 2006.10.17
헤드 퍼스트 새책이 나왔었네요  (2) 2006.10.17
Observe Pattern 예제(끝)  (0) 2006.10.08
Observer Pattern 예제  (0) 2006.10.08
Strategy Pattern 예제(끝)  (0) 2006.10.08
Strategy Pattern 예제(계속)  (0) 2006.10.08
Strategy Pattern 예제(계속)  (0) 2006.10.08
Strategy Pattern 예제  (0) 2006.10.08
Head First Degisn Patterns 소스코드 다운받기.  (0) 2006.10.08
2장 Observer Pattern(끝)  (0) 2006.10.05
top

Write a comment.


Strategy Pattern 예제(계속)

Design Pattern : 2006.10.08 11:31


Worker List Manager의 class diagram 에서는 Id로 list를 관리하는 class밖에 없었기 때문에..
기본적으로 setter에서 id를 가지고 sorting을 하는 QuicjSorting이나 InsertionSorting을 사용하였습니다.
하지만 이번에는 Name으로 list를 관리하는 class가 추가 되었습니다.
이렇게 추가 되면서 이제는 setter에서 id를 가지고 Sorting을 하는 알고리즘을 injection하는 것이 아니라.. name을 가지고 Sorting하는 알고리즘을 injection해야합니다.
따라서 다음과 같이 다이어 그램이 바뀌게 됩니다.

SoringBehavior에는 기존의 Sorting들이 Id를 가지고 Sorting하였기에 ById라고 좀더 명확하게 이름을 바꿨으며 ByName의 class두개를 추가하였습니다. 그리고 NameListManager의 setSotringBehavior()에서는 InsertoinSortingByName으로 injection할 것입니다.

'Design Pattern' 카테고리의 다른 글

3장 Decorator Pattern  (0) 2006.10.17
헤드 퍼스트 새책이 나왔었네요  (2) 2006.10.17
Observe Pattern 예제(끝)  (0) 2006.10.08
Observer Pattern 예제  (0) 2006.10.08
Strategy Pattern 예제(끝)  (0) 2006.10.08
Strategy Pattern 예제(계속)  (0) 2006.10.08
Strategy Pattern 예제(계속)  (0) 2006.10.08
Strategy Pattern 예제  (0) 2006.10.08
Head First Degisn Patterns 소스코드 다운받기.  (0) 2006.10.08
2장 Observer Pattern(끝)  (0) 2006.10.05
2장 Observer Pattern(계속)  (2) 2006.10.05
top

Write a comment.


Strategy Pattern 예제(계속)

Design Pattern : 2006.10.08 11:30




먼저 Worker들을 세 종류로 나누었고 바뀌는 getSalary와 display를 각각의 class에서 구현하도록 Worker class를 abstract로 선언했습니다.
그리고 녹색 부분이 Strategy Pattern 을 적용한 부분입니다.
마지막으로 최종적으로 WorkerListManager를 상속 받은 IdListManager에서 Id를 가지고 정렬하도록 sortingBehavior를 때에 따라 바꿔가며 사용할 것입니다.

'Design Pattern' 카테고리의 다른 글

헤드 퍼스트 새책이 나왔었네요  (2) 2006.10.17
Observe Pattern 예제(끝)  (0) 2006.10.08
Observer Pattern 예제  (0) 2006.10.08
Strategy Pattern 예제(끝)  (0) 2006.10.08
Strategy Pattern 예제(계속)  (0) 2006.10.08
Strategy Pattern 예제(계속)  (0) 2006.10.08
Strategy Pattern 예제  (0) 2006.10.08
Head First Degisn Patterns 소스코드 다운받기.  (0) 2006.10.08
2장 Observer Pattern(끝)  (0) 2006.10.05
2장 Observer Pattern(계속)  (2) 2006.10.05
2장 Observer Pattern(계속)  (0) 2006.10.05
top

Write a comment.


Strategy Pattern 예제

Design Pattern : 2006.10.08 11:22


Strategy Pattern을 이용한 사원 List 관리

사원의 List를 관리하는 프로그램을 작성합니다.
기존의 legacy system에서 사용하던 사원의 data는 txt파일 형태로 존재 합니다. 예를 들어 모든 data는 id, name, salary, commission, hourOfWorked, payPerHour 순으로 입력이 되어 있으며 사원의 종류에 따라 어떤 직원은 salary만 기입되어 있는 data도 있으며 salary와 commission만 기입되어 있는 data도 있고 hourOfWorked와 payPerHour만 기입되어 있는 사원이 있습니다. 즉 어떤 사원은 월급을 계산할 때 salary만 주면 되는 것이고 어떤 사원은 salary +commission을 주고 어떤 사원은 시급 * 일한 시간을 계산하여 월급을 계산합니다. 그리고 직원들은 현재 무작위순입니다.
위 txt파일로부터 직원들의 정보를 읽어 들여서 새로운 웹기반의 시스템에서 사용하려고 합니다. 이 직원들의 List를 관리하는 프로그램을 사용하여 직원들을 id또는 이름순으로 정렬하고자 합니다. 정렬 할 때 맨 처음 무작위 순으로 되어 있는 경우는 Quick Sorting이나 Merge Sorting을 사용하는 것이 효율적입니다. 하지만 새로운 직원이 List에 추가 되거나 삭제 될 때는 Insertion Sorting을 사용하는 것도 효율적입니다. 여기서 다시 이름순으로 정렬을 할 때는 기존의 data들이 id순으로 정렬되어 있기 때문에 이름순으로 따진다면 무작위순으로 되어 있는 것과 마찬가지입니다. 따라서 다시 Quick Sorting이나 Merge Sorting을 사용하여 Sorting을 하고 다시 새로운 직원을 추가하거나 삭제 할 때는 Insertion Sorting을 사용할 수 있습니다.

위 상황에 적합하도록 Class들을 구현하여(Design이 보통 선행 될 것입니다.) test class를 작성하여 test해 봅시다.

요약


1. txt 파일로부터 data를 읽어 들여 월급 정보에 따라 직원들의 type에 맞는 객체를 생성하여 List에 추가할 것.
2. List를 Id 순 또는 Name 순으로 최초 정렬을 할 것.(이 때는 Quick Sorting or Merge Sorting사용.)
3. 새로운 직원을 생성하여 List에 추가할 할 것.(이 때는 Insertion Sorting을 사용할 것.)
4. 2번에서 Id로 정렬하였다면 이번에는 Name으로 정렬하도록 합시다.(Name으로 정렬하는 List 관리자로 대체 하면 될 것입니다.)
5. 다시 최초 정렬을 하고.
6. 새로운 직원을 생성하여 추가합니다.

'Design Pattern' 카테고리의 다른 글

Observe Pattern 예제(끝)  (0) 2006.10.08
Observer Pattern 예제  (0) 2006.10.08
Strategy Pattern 예제(끝)  (0) 2006.10.08
Strategy Pattern 예제(계속)  (0) 2006.10.08
Strategy Pattern 예제(계속)  (0) 2006.10.08
Strategy Pattern 예제  (0) 2006.10.08
Head First Degisn Patterns 소스코드 다운받기.  (0) 2006.10.08
2장 Observer Pattern(끝)  (0) 2006.10.05
2장 Observer Pattern(계속)  (2) 2006.10.05
2장 Observer Pattern(계속)  (0) 2006.10.05
2장 Observer Pattern  (0) 2006.10.05
top

Write a comment.


1장 Strategy Pattern (끝)

Design Pattern : 2006.09.26 00:23


최종적으로 위와 같은 다이어그램이 완성됩니다.
상속으로 시작했던 디자인이 composition(구성)을 사용함으로써 결말이 났군요.
이로써 다음과 같은 디자인 원칙을 배울 수 있습니다.
디자인 원칙3
상속보다는 구성을 활용한다.
위에서 했던 행동들이 하나의 디자인 패턴으로 정립되어 있었습니다.
바로 Strategy pattern 이라는 것으로 써 정의는 다음과 같습니다.
Strategy Pattern에서는 알고리즘군을 정의하고 각각을 캡슐화하여 교환해서 사용할 수 있돌고 만든다. 이것을 사용하면 알고리즘을 사용하는 클라이언트와는 독립적으로 알고리즘을 변경할 수 있다.
위키피디아 에서 정의한 내용은 다음과 같습니다.

Strategy pattern

From Wikipedia, the free encyclopedia

Jump to: navigation, search
In computer programming, the strategy pattern is a particular software design pattern, whereby algorithms can be selected on-the-fly at runtime.
In some programming languages, such as those without polymorphism, the issues addressed by this pattern are handled through forms of reflection, such as the native function pointer or function delegate syntax.
The strategy pattern is useful for situations where it is necessary to dynamically swap the algorithms used in an application. The strategy pattern is intended to provide a means to define a family of algorithms, encapsulate each one as an object, and make them interchangeable. The strategy pattern lets the algorithms vary independently from clients that use them.
runtime시에 알고리즘을 선택할 수 있는 특징이 있고 다형성이 지원되지 않는 언어의 경우 포인터와 delegate syntax와 같은 reflection의 형태로 다뤄집며 유용한 상황으로는 동적으로 알고리즘을 바꾸고 싶을 경우라고 간략히 요약할 수 있습니다.
원문은 위의 링크와 같으며 예제로 여러가지 sorting 알고리즘을 동적으로 바꿔가며 사용해보는 예제가 C++언어로 나와있습니다.
더 구체적인 내용은 이곳에서 볼 수 있습니다.
decoupling에 관한 내용과 여러 장점에 대해 설명이 되어 있습니다.
다음은 기본 Strategy Pattern의 기본 UML입니다.
마지막으로 실생활에 Strategy Pattren을 적용한 예를 살펴보겠습니다.

'Design Pattern' 카테고리의 다른 글

Strategy Pattern 예제(계속)  (0) 2006.10.08
Strategy Pattern 예제(계속)  (0) 2006.10.08
Strategy Pattern 예제  (0) 2006.10.08
Head First Degisn Patterns 소스코드 다운받기.  (0) 2006.10.08
2장 Observer Pattern(끝)  (0) 2006.10.05
2장 Observer Pattern(계속)  (2) 2006.10.05
2장 Observer Pattern(계속)  (0) 2006.10.05
2장 Observer Pattern  (0) 2006.10.05
1장 Strategy Pattern (끝)  (0) 2006.09.26
1장 Strategy Pattern(계속)  (2) 2006.09.26
1장 Strategy Pattern  (0) 2006.09.26
top

Write a comment.


1장 Strategy Pattern(계속)

Design Pattern : 2006.09.26 00:20


이전 글에서 발생했던 문제를 해결하기 위해서 interface를 사용하여 날아다닐 수 있는 오리와 소리낼 수 있는 오리로 구분하였습니다.
날아 다니거나 소리 낼 수 있는 오리들은 해당 interface를 구현해야 하며 따라서 fly나 quack과 같은 method들을 구현해 주어야 합니다.
만약에 이런 상황에서 오리의 소리가 공통적으로 바뀐다면 어떻게 해야할까요? 아마 Quackable을 구현한 모든 class들을 수정해야 할 것입니다.
(현재는 class들의 수가 몇개 안되지만 50개 라고 하면 50번을 수정해야 합니다.)
좀더 좋은 방법이 필요할 듯합니다.
지금까지 계속 변화를 가정하여 class들이 보다 유연하게 구성되도록 진행되가고 있습니다.(그만큼 변화가 빈번히 일어난다는 것이겠죠.)
이러한 변화 속에서 살아남으려면 다음과 같은 디자인 원칙에 유의해야합니다.
디자인원칙1
애플리케이션에서 달라지는 부분을 찾아 내고, 달라지지 않는 부분으로부터 분리시킨다.
즉 fly()와 quack()은 Duck class에서 오리마다 달라지는 부분입니다.
이 두 메소드를 Duck에서 뽑아 내어 새로운 class집합으로 만들 것입니다.
이 class집합들은 다음의 디자인 원칙에 따라 구현합니다.
디자인원칙2
구현이 아닌 인터페이스에 맞춰서 프로그래밍한다.
이 말은 선뜻 이해가 되지 않습니다.
여기서 구현이라고 하는 것은 특정 class에 있는 method를 말하는 것이고 인터페이스는 상위 classl에 있는 method들을 말한다고 생각합니다.
즉.. Animal a = new Dog(); or new Cat();
a.eat();
을 실행했을 때 개도 먹일 수 있고 고양이도 먹일 수 있도록 프로그래밍 하라는 뜻으로 이해가 됩니다.
(저 방법 보다 Animal a = getAnimal(); 이런 방법으로 new 키워드를 없애는 것이 보다 더 디자인원칙2를 잘 지키는 것이라고 나와있습니다.)
따라서 다음과 같은 다이어 그램으로 class집합을 구현할 수 있습니다.

이제 Duck class에서는 위 두 집합의 상위Type의 변수를 가진다면 a.eat()과 같은 장점(다형성)을 누릴 수 있습니다.
위와 같이 FlyBehavior와 QuackBehavior type의 변수를 가지고 있고
performFly()와 performQuack()에서는
flyBehavior.fly()와 quackBehavior.quack()를 실행하기만 하면 됩니다.
이렇게 해두면 각각의 오리( sub class )들은 dispaly()만 구현하면 되고 자기 자신의 quack이나 fly의 Behavior가 어떤 것인지 설정해 줌에 따라 결과가 달라지게 됩니다.
자신의 Behavior를 설정하는 방법은 객체 생성시에 생성자에서 하는 방법과
나중에 setter메소드를 사용하는 방법이 있습니다.
setter메소드를 이용하여 Behavior를 지정해 줄 경우 날수 없던 오리(FlyNoWay Behavior로 setting했던 오리)가 갑자기 날개를 가지고 날아갈 수있게(FlyWithWings Behavior로 오리의 Behavior를 프로그램 실행도중 setter method를 사용하여 setting하면 됩니다.) 마술을 부릴 수도 있습니다.

'Design Pattern' 카테고리의 다른 글

Strategy Pattern 예제(계속)  (0) 2006.10.08
Strategy Pattern 예제(계속)  (0) 2006.10.08
Strategy Pattern 예제  (0) 2006.10.08
Head First Degisn Patterns 소스코드 다운받기.  (0) 2006.10.08
2장 Observer Pattern(끝)  (0) 2006.10.05
2장 Observer Pattern(계속)  (2) 2006.10.05
2장 Observer Pattern(계속)  (0) 2006.10.05
2장 Observer Pattern  (0) 2006.10.05
1장 Strategy Pattern (끝)  (0) 2006.09.26
1장 Strategy Pattern(계속)  (2) 2006.09.26
1장 Strategy Pattern  (0) 2006.09.26
top

  1. thank you 2007.04.02 13:57 PERM. MOD/DEL REPLY

    좋은글 감사합니다.

    Favicon of https://whiteship.tistory.com BlogIcon 기선 2007.04.02 14:50 신고 PERM MOD/DEL

    넵 방문 감사합니다. :)

Write a comment.


1장 Strategy Pattern

Design Pattern : 2006.09.26 00:17




위 다이어그램을 보면 Duck class를 상속을 이용하여 재사용 하고 있습니다.
필요한 부분( 여기서는 display() )만 overriding 해주면 되기 때문에 상당히 편리해 보입니다.
기본 기능으로 오리가 날수 있도록 하고 싶을 때...



위와 같이 상위 class에 추가하기만 하면 모든 하위 class들에 일일히 추가할 필요가 없기때문에 편리해 보입니다.
하지만...
날지 못하는 오리(고무 인형 오리)의 경우라면 상속 받지 말아야 할텐데.
특정 method를 제외하고 상속하는 방법 같은 것은 배운적이 없네요 :)
상속을 못하게 하는 방법은 있지만 그렇게 하면 다른 자식 class들은 어떻게 하나요? 하핫;
method하나가지고 뭘 그러나.. 그냥 method를 overring해서 안에서 아무것도 안하면 되지 않을까...라는 생각을 처음엔 했었습니다.
그러나...
그러한 method가 무진장 많다고 했을 때를 생각해 보면 코드 낭비에 시간 낭비라는 생각이 안들 수가 없습니다. 무언가 뾰족한 수가 필요합니다.

'Design Pattern' 카테고리의 다른 글

Strategy Pattern 예제(계속)  (0) 2006.10.08
Strategy Pattern 예제(계속)  (0) 2006.10.08
Strategy Pattern 예제  (0) 2006.10.08
Head First Degisn Patterns 소스코드 다운받기.  (0) 2006.10.08
2장 Observer Pattern(끝)  (0) 2006.10.05
2장 Observer Pattern(계속)  (2) 2006.10.05
2장 Observer Pattern(계속)  (0) 2006.10.05
2장 Observer Pattern  (0) 2006.10.05
1장 Strategy Pattern (끝)  (0) 2006.09.26
1장 Strategy Pattern(계속)  (2) 2006.09.26
1장 Strategy Pattern  (0) 2006.09.26
top

Write a comment.