(Day 21) 디자인패턴 입문
21일
Open/Closed Principle?
기능 추가(확장)에는 열려있으나 코드 변경에는 막혀있어야 한다는 원칙이다.
GRASP: Low-Coupling?
클래스와 클래스간의 결합이 적어야 재사용이 가능한 클래스를 작성할 수 있다.
죽는 순간 까지 햇갈릴 것이다.
헷갈리다? 햇갈리다? 배게? 베게? 어차피 모든 지식은 다 헷갈리게 된다. 인간의 기억은 불완전하기 때문이다. 그런데 계쏙 반복하고 익숙해지면 헷갈리는 정도가 줄어든다. 혼동의 반경이 줄어든다는 것이다.
IED에 대한 생각
프로그래머의 두뇌가 만들어내고자 하는 코드를 생각의 흐름대로 만들게 해주는 강력한 힘이 있다. 제트브레인. 이름을 너무 잘 지었다!!
예를 들면 어떤 메서드를 호출하는 문장을 작성할 때, 일단 클래스가 다 준비되어 있지 않는 상황에서, 아래와 같은 구조를 상상하여 작성했다고 하면..
클래스1.메서드1(new 클래스2.메서드2(클래스3.메서드3()), 메서드4())
일단 작성하면 문제가 되는 부분에 대한 해결을 제시해주기에 클래스 1부터 메서드1을 포함하여 작성을 시작하고, 클래스2를 메서드2를 포함하여 작성하고, 클래스3을 메서드3을 포함하여 작성하고, 포함된 패키지내에 있는 메서드4를 작성하는 등… 생각의 흐름대로 프로그램을 작성하는 것을 아주 편하게 해준다.
여기에 반복적인, 혹은 당연한 작업을 아주 간단하게 해결해준다. 인터페이스가 사용된 경우라면 인터페이스에서 요구하는 메서드를 자동생성해주는 기능, 생성자에서 자주 사용되는, 인스턴스 필드들을 생성자의 파라미터로 대입하는 코드를 작성해주는 기능.. 이런 것들은 단축키로 해결이 가능하니 생각하는대로 작성하는 것에 가속도가 붙는다.
myapp의 문제점
컴포지트 패턴을 구현하면서 핸들러라는 개념을 도입했다. 메뉴 핸들러 인터페이스를 실제로 구현하는 클래스이다. 여러 클래스들이 공통으로 한 인스턴스(정보)를 다루므로 Repository 역할을 하는 하는 클래스를 만들었다. (Repository 클래스)
근데 문제! 정보는 Repository가 갖고 있는데 다른 클래스들이 그 정보를 사용한다. 그러면 안된다. 정보를 가진 클래스가 정보를 사용해야 한다. 그래서 다른 클래스들이 정보를 사용하는 메서드들을, 그 정보를 가진 클래스쪽으로 이동하는 리팩터링이 필요하다.
- 왜?
- 그렇지 않으면 정보를 사용하는 방법을 수정할 때, 그 정보를 사용하는 모든 클래스들을 각각 수정해줘야 한다!! 강하게 결합(High-Coupling)된 것이다.
강결합(High-Cohesion)의 단점
- 재사용이 어렵다.
- 코드 수정할 때 여러군데를 수정해야 한다.
비유: 빌트인 가구는 이사를 갈 때 가져가기 힘들다! 이래서 클래스다이어그램이 중요하군. 문제가 있고 없음을 알아내기 좋다.
패턴 = 자주 발생하는 상황의 패턴
자주 발생하는 상황에 대한 선배들의 비법이다.
Information Expert 적용하기
캡슐화 (Encapsulation)
- 캡슐화
- 내부의 구체적인 동작과정(Mechanism)을 감춘다.
왜 감추려고 해요!!
내부 구조가 변경되더라도 사용하는 측에는 영향을 주지 않으려고 하는 것이다. 차량을 운전하기 위해서는 차 내부를 다 알아야 하나? 그렇지 않다. 차는 핸들, 액셀, 브레이크, 기어라는 특정 인터페이스들을 알면 사용할 수 있다. 나머지 부분은 가려져 있다. 그게 더 안전하기 때문이다. 코드도 그렇다. 강하게 결합(high coulping)된 것은 하나의 기능을 수정하려고 할 때 결합된 클래스들 전부를 바꿔줘야 하기에 매우 불편하고 위험하다.
휴대폰 카메라나 배터리가 어떻게 칩과 연결되어 있는지 알면 좋을까? 드러난다는 건 그만큼 위험을 감수해야 하는 일이다.
myapp에 적용
- 캡슐화를 하여
BoardRepository을 다루는 방법을 감춘다. - boardRepository OOP’s Encapsulation: 목록을 다루는 방식을 감추고 대신 외부에 공개된 도구 서드를 통해 목록을 사용하도록 유도한다. 목록을 다루는 방식을 변경하더라도 외부에 영향을 주지 않는다.
다형성
다형적 변수
다양한 형태의 인스턴스를 받을 수 있는 레퍼런스 변수는 다형적 변수라고 불린다. Polymorphic Varaiables.
상속에서 클래스의 상속관게를 이야기할 때 자식클래스 = 서브클래스 부모클래스 = 슈퍼클래스