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쪽에 나오는 다이어그램이 보여주고

design pattern

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

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

Decorator Pattern

Decorator Pattern 예제

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

design pattern

Observe Pattern 예제(끝)

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

design pattern

Observer Pattern 예제

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

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도

design pattern

1장 Strategy Pattern (끝)

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

design pattern

1장 Strategy Pattern(계속)

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

You've successfully subscribed to Whiteship!
Could not sign up! Invalid sign up link.