1) 개방 폐쇄 원칙 개방폐쇄의 원칙의 정의는 다음과 같다. "소프트웨어 개체(클래스, 모듈, 함수,등등)는 확장에 대해 열려 있어야 하고, 수정에 대해서는 닫혀 있어야 한다." 여기서 말하는 수정과 확장에 대한 얘기는 런타임의존성, 컴파일의존성에 대한 이야기이다. 단순히 해당클래스의 메서드명, 필드명등에 대한 이야기가 아니라. 컴파일시점에 추상화 클래스에 의존해서 런타임 의존성에 의해 확장에 대한 유연성을 높이자는 이야기이다. 변하지 않는 부분과, 변하는부분을 나누고 변하는 부분을 추상화하는 것이 개방폐쇄 원칙을 지키는 핵심이 된다. 2) 생성 사용 분리 생성하는 클래스와 사용하는 클래스를 분리하자. 객체를 직접 생성하는 것은 결합도가 높아질 수 있지만, 객체 생성을 피할 수는 없다. 객체 생성을 클라..
1) 의존성 이해하기 어떤 객체가 협력하기 위해 다른 객체를 필요로 할 때 두 객체 사이에 의존성이 존재하게 된다. 의존성은 단방향성으로 되어있다. 의존하고 있는 클래스가 변경된다면 주체도 내부 속성도 같이 변경되어야한다. UML의 의존관계와 의존성은 다르다. UML은 두 요소 사이에 존재할 수 있는 다양한 관계의 하나로 의존 관계를 정의한다. 의존성은 두 요소 사이에 변경에 의해 영향을 주고 받는 힘의 역학관계가 존재한다는 사실에 초점을 맞춘다. 의존성 전이 Movie라는 클래스를 Customer가 의존할 경우, 자연적으로 Movie가 의존하는 대상에 대해서 Customer도 의존한다는 것을 의미한다. 모든 의존성이 전이되지는 않으며, 이는 캡슐화 정도에 따라 달라진다. 런타임과 컴파일 타임 런타임은 ..
1) 프로시저 추상화와 데이터 추상화 프로시저 추상화: 알고리즘, 기능을 중심으로 시스템을 추상화 데이터 추상화: 데이터 중심으로 타입을 추상화 - 추상 데이터 타입 데이터를 중심으로 프로시저를 추상화 - 객체지향 객체지향을 바라보는 일반적인 관점은 데이터 추상화와 프로시저 추상화를 함께 포함한 클래스를 이용해 시스템을 분해하는 것 2) 프로시저 추상화와 기능 분해 기능과 데이터에서 처음은 기능의 우위였다. 기능 분해를 통해 시스템을 분해를 하였으며, 이 프로시저 단위로 분해된 것은 인터페이스를 통해 사용할 수 있었다. (프로시저는 반복적으로 실행 혹은 유사하게 실행되는 작업들을 하나의 장소에 모아놓은 추상화 방법이다.) 전통적으로 기능 분해 방법은 하향식 접근법(최상위 기능 정의 후 작은 단위의 하위 ..
'오브젝트' 책 보고 공부하기 - ⑥ 메시지와 인터페이스
1) 협력과 메시지 협력안에서 메시지를 전송하는 클라이언트, 메시지를 수신하는 객체를 서버라고 표현하는 클라이언트 - 서버 모델이있다. Switch는 클라이언트고 Hitter는 서버이다. Swtich가 Hitter에 온도를 높이라고 요청하면 Hitter는 열에너지를 주게 된다. 이 같은 경우는 우리가 Rest API 통신을 통해 많이 겪게 되는 상황인데, 프론트와 백엔드가 분리된 서버에서 자주 마주칠 수 있는 상황이다. Hitter는 또 다른 객체에게 클라이언트 입장으로 존재할 수 있다. 가령 전기에너지를 얻기 위해 다른 객체를 찾을 수 있을 것이다. 조금 더 깊이 알기 위해 용어 정리를 하자. 메시지: 객체들이 협력하기 위해 사용할 수 있는 의사소통 수단 다른 객체에게 도움 요청하는 것을 메시지 전송 ..
1) 책임 주도 설계를 향해 객체가 수행해야할 책임은 무엇인가로 시작해서 객체가 수행하는데 필요한 데이터는 무엇인가로 설계하자. 책임 중심의 설계가 될 수 있다. 협력의 문맥 아래서 책임을 결정하자. 책임이 어색하더라도 협력에 적합하면 해당 책임은 좋은 것이다. 메시지를 먼저 선택하고나서 메시지를 처리할 객체를 선택하여 적합한 객체를 사용 할 수 있게 노력하자. 2) 책임 할당을 위한 GRASP 패턴 설계를 시작하기전 도메인에 대한 개략적인 모습을 그려보는것이 유용하다. 필자도 머리속으로 정리하기가 어려울 때는 PPT를 사용하든 다른 툴을 사용하든 데이터의 흐름을 그려보는데, 그리다보면 고쳐야될 점도 보이고, 파악하기도 쉽다는게 좋다. (물론, 틀렸을때 다시 그리기도 조금 벅차지만 말이다.) 올바른 도메..
1) 데이터 중심의 영화 예매 시스템 객체의 상태 변경은 인터페이스 변경이 일어나며, 의존하는 모든 객체에 영향이 끼친다. 이전 기억을 떠올려 보니 객체의 상태변경시 마다 바꾸어야 될 코드가 많았던게 기억이난다. 데이터 중심의 영화예매 시스템은 '할인정책', '할인조건' 이 모두 Movie객체에서 처리한다. Enum Type으로 정책구분을 하는데, 내가 짜왔던 코드와 많이 비슷해서 흠짓했다. 후에는 회사 팀원분들의 조언으로 Enum Type으로 맞는 인터페이스의 구현체를 호출하는 방법도 많이 해보았는데, 확실히 가독성이 뛰어났다. 객체의 상태를 호출해와서 해당 상태로 또다른 상태를 호출하는 이런방식의 코드도 많이 닮아있다. 즉, 캡슐화 & 추상화가 되어있지 않은 코드가 생겼다. 2) 설계 트레이드오프 캡..
1) 협력 객체지향 원칙을 따르는 애플리케이션의 제어 흐름은 어떤 하나의 객체에 의해 통제되지 않고 다양한 객체들 사이에 균형 있게 분배되는 것이 일반적이다. 객체들이 애플리케이션의 기능을 구현하기 위해 수행하는 상호작용을 협력 이라고 한다. 객체는 메시지 전송을 통해 객체사이의 협력을 커뮤니케이션을 한다. 예를들어 Screening ------- calcuateMovieFee(Screening) ---> Movie Screening 객체가 Movie에게 calculateMovieFee 메시지를 전송함 으로써 Movie에게 요금 계산을 요청한다. 이는 Movie가 요금 계산을 하는데 필요한 정책, 요금등을 잘 알고 있기때문에 처리를 위임한 것이다. 이렇게 자신이 할 수 없는 일을 다른 객체에게 위임하면 ..
'오브젝트' 책 보고 공부하기 - ② 객체지향 프로그래밍
1) 영화 예매 시스템 일반적인 영화 예매시스템을 따르며, 할인조건, 할인정책 구분하여 설계한다. 2) 객체 지향 프로그래밍을 향해 협력, 객체, 클래스 생각의 전환이 필요하다. 객체지향 언어에 익숙하면 설계를 시작할때 어떤클래스가 필요하지? 어떤 메서드가 필요하지? 어떤 필드가 필요하지? 가 먼저 떠오르게된다. 객체에 초점을 맞추자 첫째, 클래스가 아닌 어떤 객체들이 필요한지 고민해라. 클래스는 공통적인 상태와 행동을 공유하는 객체들을 추상화한 것이다. 둘째, 객체를 독립적인 존재가아니라 기능을 구현하기 위한 공동체의 일원이라 보자. 서로 다른 객체에게 도움을 주거나, 의존하면서 살아가는 협력적인 존재다. 도메인의 구조를 따르는 프로그램 구조 알고가기. 문제를 해결하기위해 사용자가 프로그램을 사용하는 ..