Tagged

design pattern

A collection of 19 posts

design pattern

객체지향 디자인 원칙

바뀌는 부분은 캡슐화한다. 상속보다는 구성을 활용한다. 구현이 아닌 인터페이스에 맞춰서 프로그래밍 한다.서로 상호작용을 하는 객체 사이에서는 가능하면 느슨하게 결합하는 디자인을 사용해야 한다. 클래스는 확장에 대해서는 열려있지만 변경에 대해서는 닫혀 있어야 한다. 추상화된 것에 의존하라. 구상 클래스에 의존하지 않도록 한다. 친한 친구들하고만 이야기한다. 먼저 연락하지 마세요. 저희가 연락드리겠습니다. 어떤 클래스가

design pattern

H.F. Design Pattern 트집잡기

2장 p80쪽에 나오는 getter들과 p105쪽에 구현되어 있는 getter들이 일치 하지 않음.[#M_ more.. | less.. | => 80쪽에 나오는 getter들은 외부 기계로 부터 값을 읽어오는 getter들인데 105쪽에 있는 getter들은 자신의 data를 호출하는 쪽으로 넘겨주는 일반적인 게터, 세터의 모양을 하고 있습니다._M#]3장 p129쪽에 나오는 다이어그램이 보여주고 있는 UML의 선이 나타내는 의미와 클래스안에

design pattern

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

 2. 2차 확장/변경(1년이 지난 후)        다.[10점] 김치피자가 인기가 좋아서 뉴욕과 시카고에서도 치피자를 메뉴에 추가 하고자 한다. Dough는 밥 대신 시카고에서 사용하는 ThickCrustDough를 사용한다. 뉴욕에서는 된장이 쉽게 구할 수 있지만 시카고에서는 한국된장이 쉽게 구할 수 있는 재료가 아니라서 일본된장을 사용하기로했다. [#M_답 보기|

design pattern

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

나.[10점] 서울분점에서는 메뉴에 김치피자를 추가 하고자 한다. 김치피자에서는 Dough를 밥으로 만들어야 하고, 치즈대신 된장을 사용한다. [#M_ more.. | less.. | 1. SeoulStore 클래스에 KimchiPizza 주문을 할 수 있도록 수정합니다. 2. Pizza를 상속받는 KimchiPizza 클래스를 구현합니다. 3. RiceDough 클래스와 Doenjang 클래스를 구현합니다. 먼저 test 코드를 작성합니다. 1-(1) 번 문제를 풀 때

design pattern

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

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

Decorator Pattern

Decorator Pattern 예제

데코레이터 패턴 레포트 상세 내용 게임게발을하고 있습니다. 각 케릭터는 ‘인간’이라는 한 종족으로시작을 하게 되며 한 종족은 ‘전사’, ‘마법사’, ‘도둑’세 가지의 직업을 가지게 됩니다. 각 케릭터가 착용하게 되는 아이템은 ‘무기’, ‘방어구’를 착용하게 됩니다. 그리고 모든 직업은 공통적으로 HP, MP라는 속성값을 가지게 됩니다. 케릭터를생성하여 전사, 마법사, 도둑 세가지의 직업으로

Decorator Pattern

3장. Decorator Pattern(계속)

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

Decorator Pattern

3장 Decorator Pattern

이번에는 스타버즈의 메뉴를 class diagram으로 그린 것입니다. 기본적인 Beverage class를 상속 받는 방식으로 새로운 메뉴를 생성하고 있습니다. 만약..커피를 주문할 때 우유,  두유, 모카, 크림과 같은 첨가물을 추가하는 경우 각각이 다른 class로 생성하여 상속 받게 됩니다. 즉, 모카 커피 class, 두유 커피 class, 우유 커피 class, 크림 커피 class,

design pattern

Observe Pattern 예제(끝)

Auctioneer는 Subjct를 대신했고 Bidder는 Observer 인터페이스를 대신하도록 만들었다. 그리고 각각 ConcereAuctioneer와 ConcreteBidder 클래스를 작성하여 인터페이스를 통해 접근하도록 했다. 그리고 test 클래스를 작성하기 시작했다. 먼저 경매 물품이 나오고 (경매 시작 가격이 있을 것이라 생각했다.) 그다음 경매자들이 그 물품의 구독자(observer)로 등록이 되며(여기서는 구독자 List를 등록하도록 했으며 한명의 구독자를 등록하는

design pattern

Observer Pattern 예제

Obsever Pattern은 1대 다 관계를 정의합니다. 따라서 한 객체의 상태가 바뀌면 다른 것들이 자동적으로 정보를 업데이트 받습니다. Participant Correspondence: auctioneer가 Subject에 해당합니다. Observer들은 그에게 등록을 해야하기 떄문에 당연히 그는 observer들을 알고 있습니다. 현재 경매가(current bid)는 ConcreteSubject에 해당합니다. Observer들은 이것의 상태에 관심이 있습니다. 경매 참가자(bidder)들은 Observer에 해당합니다.

design pattern

Strategy Pattern 예제(끝)

Worker List Manager의 class diagram에 추가 사항. 위에서 생각해 보았던 문제가 들어맞았다… 필요없이 모양에 끼워 맞추려다가 오히려 복잡해지기만 했다. 그래서 과감히 필요없는 부분은 제거했다. 보라색 부분에 있던 sub class들을 몽땅 없애버렸다. WorkerListManager를 사용해서도 충분히 지시된 사항들이 가능하기 때문이다. 나중에 필요하게 되면 다시 상속을 하여 사용하도록 하면 될 듯하다. 유지보수

design pattern

Strategy Pattern 예제(계속)

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

design pattern

Strategy Pattern 예제(계속)

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

design pattern

Strategy Pattern 예제

Strategy Pattern을 이용한 사원 List 관리 사원의 List를 관리하는 프로그램을 작성합니다. 기존의 legacy system에서 사용하던 사원의 data는 txt파일 형태로 존재 합니다. 예를 들어 모든 data는 id, name, salary, commission, hourOfWorked, payPerHour 순으로 입력이 되어 있으며 사원의 종류에 따라 어떤 직원은 salary만 기입되어 있는 data도 있으며 salary와 commission만 기입되어 있는 data도

design pattern

1장 Strategy Pattern (끝)

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

design pattern

1장 Strategy Pattern(계속)

이전 글에서 발생했던 문제를 해결하기 위해서 interface를 사용하여 날아다닐 수 있는 오리와 소리낼 수 있는 오리로 구분하였습니다. 날아 다니거나 소리 낼 수 있는 오리들은 해당 interface를 구현해야 하며 따라서 fly나 quack과 같은 method들을 구현해 주어야 합니다. 만약에 이런 상황에서 오리의 소리가 공통적으로 바뀐다면 어떻게 해야할까요? 아마 Quackable을 구현한 모든 class들을

design pattern

1장 Strategy Pattern

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