본문 바로가기

Design Patterns

(28)
Strategy Pattern ③ 정리 책에서는 세가지의 디자인 원칙을 내세우면서 궁극적으로 Strategy Pattern으로 가기 위한 로드맵을 제공합니다. ① 애플리케이션에서 달라지는 부분을 찾아내고, 달라지지 않는 부분으로부터 분리시킨다. ② 구현이 아닌 인터페이스에 맞춰서 프로그래밍한다. ③ 상속보다는 구성을 활용한다. ① 애플리케이션에서 달라지는 부분을 찾아내고, 달라지지 않는 부분으로부터 분리시킨다. attack(), move(), stop().. 등의 바뀌는 부분을 분리시켜서 따로 만들어 준것 기억하시죠? 그것들을 행동 별로 나누어서 또 세분화 시켜준 것을 의미합니다. ② 구현이 아닌 인터페이스에 맞춰서 프로그래밍한다. 이전에 있던 Attackable과 같은 인터페이스는 Terran을 상속받는 구체적인 유닛 클래스가 구체적으로 구..
Strategy Pattern ② Encapsulation(캡슐화) 와 Composition(구성)을 활용한 리팩토링 말은 그럴싸 합니다만.. -_-;; 그럼 실제로 슬슬 고쳐보도록 하겠습니다. (텍스트 보다는 비주얼하게!!) 이렇게 한번 바까 줘 봤습니다. 유닛들의 행동을 구현하는데요.. 사실 이전에 있던 인터페이스로 행동을 구현하도록 했던 다이어 그램에 보면, SCV랑 메딕이랑 고치는 메소드도 사실은 모호했지요.. 이렇게 나눈 덕분에 사람을 고치는지 건물을 고치는지 명확해 졌구요.. 공격을 하는 경우와 공격을 하지 않는 경우, 이동을 하고, 이동을 못하는 경우의 클래스를 만들어서 해당 인터페이스의 메소드를 구현해 주면 되겠죠!! (공격 못하는 메딕에게 공격 명령을 내렸을때, 아무 것도 안하게 말이죠!!) 여기서 끝인가 했는데 아닙니다 -_-;; 이제 Terran이라는 클래스도 변경을 해줘야합니다. 그리고 유닛별 메소..
Strategy Pattern ① 상속과 구현의 문제점 먼저 스타크래프트를 활용하여 Strategy Pattern 으로 가는 예제를 만들어 볼까 합니다. 일단 참고하고 있는 책은 Head First, Design Pattern 이며, 앞으로도 이 책으로 공부를 해 나가려고 합니다. 위와 같이 상속을 사용하여 만들어 보았습니다. 테란 종족은 보여지거나, 움직이거나, 공격하거나, 멈추는 4가지의 공통적인 메소드들이 존재하고 각 유닛별로 보여지는게 틀리기 때문에 Display() 메소드를 오버라이드 하여 각각 고유의 형태를 보여지게 하였습니다. 하지만 문제가 발생했습니다 -_-;; 메딕은 공격을 못해야 정상인데 공격을 하게 되고, 더 문제가 되는건 SupplyDepot은 건물이기 때문에 움직이거나 공격하거나, 멈추거나 할 수 없는데 말이죠.. 따라서 상속을 하는것..
패턴 중독 패턴 중독에 관해 풍자 해 놓은 글이 있어서 읽어 보았다. (출처 : http://developers.slashdot.org) Of course those GoF patterns can make life hell for the maintenance developer or app framework user, when people turn it into a contest to see how many design patterns they can fit into a single project. The overall "Design Patterns" philosophy is really "how can I defer as many decisions as possible from compile time to run ..