OOP, FP/디자인패턴 (20) 썸네일형 리스트형 헤드퍼스트 디자인 패턴: 1. 스트래티지 패턴 앞서 디자인 패턴의 원칙 9가지를 복습을 마쳤다. 이번에는 책에서 다룬 디자인 패턴에 대해서 복습하려고 한다.그 첫번째인 스트래티지 패턴(Strategy Pattern) 스트래티지 패턴알고리즘군을 정의하고 각각을 캡슐화하여 교환해서 사용할 수 있도록 만든다.이 패턴을 사용하면 알고리즘을 사용하는 클라이언트와는 독립적으로 알고리즘을 변경할 수 있다.(실행중에 동적으로 알고리즘을 변경할 수 있다.) 이번에도 역시 스타크래프트의 테란 종족의 등장이다. 테란의 유닛이 각각 스피드와 체력을 상태로 갖고 움직이는 메소드, 공격을 시작하는 메소드, 행동을 멈추는 메소드가 있다고 한다. 그런데 여기서 Scout에 문제가 생겼다. 얘는 움직일 때 move()가 아닌 fly()를 써야된다.스카우트만 날수있으면 상관없겠지,.. 헤드퍼스트 디자인 패턴: 디자인 원칙 7~9 7. 정말 친한 친구하고만 얘기하라.(최소 지식 원칙)(Principle of Least Knowledge) = (Law of Demeter) 일곱번째 원칙은 퍼사드 패턴에서 등장했다. 객체 사이의 상호작용, 즉 어떤 객체들이 다른 객체를 사용할 때는아주 가까운 "친구"사이에서만 허용하는 것이 좋다는 원칙이다. 클라이언트는 여러개의 벙커를 소유하고 있고,그 벙커는 다시 여러개의 마린과 파이어벳을 소유하고 있다. 이런 상황에서 클라이언트가 벙커의 모든 마린들이 공격하게 명령하는 callAttackMarines() 를 살펴보자. public void callAttackMarines() { Iterator bkIter = bunkerList.iterator(); while(bkIter.hasNext) { Bu.. 헤드퍼스트 디자인 패턴: 디자인 원칙 4~6 4. 서로 상호작용을 하는 객체 사이에서는 가능하면 느슨하게 결합하는 디자인을 사용해야 한다.(Loose Coupling) 네번째 원칙은 스트래티지패턴에 이어 등장한 옵저버 패턴에서 소개됐다.여기서 상호작용이란 일대일, 일대다, 다대다 관계에 속한 클래스간의 의존도를 말하는것 같다. A클래스가 B클래스에 강하게 의존하고 있다.B가 주제가 되는 입장인데, B에서 상태가 변경되거나 코드를 직접적으로 수정한다면A클래스의 상태도 같이 변화하거나 메소드 호출 결과가 달라진다거나 할 수 있다. 만약 B에서도 A의 기능을 사용해야한다면, 또 그런 B를 다른 클래스에서 사용한다면A나 B를 수정하는 것만으로 전체 프로그램에 악영향을 미칠 수 있다. 때문에 Loose Coupling(느슨한 결합)을 항상 고려해야 한다고 .. 헤드퍼스트 디자인 패턴: 디자인 원칙 1~3 1. 애플리케이션에서 달라지는 부분을 찾아 내고, 달라지지 않는 부분으로부터 분리시킨다.첫번째 원칙은 스트래티지 패턴에 해당하는 장에서 등장했다.새로운 요구사항이 추가로 들어왔다. 혹은 기존 화면의 요구사항이 변경됬다.이럴때 우리는 클래스의 메소드나 생성자를 고치고 추가하는 작업을 한다.그 다음에 해당 클래스를 사용하는 모든 코드를 고친다. 생각만해도 끔찍하다. 나중을 위해...코드에 바뀌는 부분이 있다면, 그 행동을 기존 코드에서 분리시켜야한다.* 바뀌는 부분을 따로 뽑아서 캡슐화한다.* 이를 지키면 나중에 바뀌지 않는 부분에 영향을 미치지 않을 채로 그 부분만 고치거나 확장할 수 있다.Ex)class A { public methodA() { 바뀌지 않는 부분바뀌는부분 -> 이 부분을 다른 클래스로 캡.. 이전 1 2 3 다음
