Tagged

Strategy Pattern

A collection of 8 posts

effective java 2nd edition

EJ2E Item 21. 전략을 표현할 때는 함수 객체를 사용하라

참조: Effective Java 2nd Edition. Item 20: Use function objects to represent strategies 자바는 함수 포인터를 제공하지 않는다. 하지만 객체 레퍼러스를 함수 객체와 비슷하게 사용할 수 있다.  메서드를 호출하면 해당 객체에 대한 기능을 수행하는 것이고 함수 객체는 다른 객체들에서 해당 기능을 수행하게 해준다. (사족. 메서드는 특정 객체에 종속적인 것이고,

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들에 일일히 추가할 필요가 없기때문에 편리해 보입니다. 하지만… 날지 못하는