1장 오브젝트와 의존관계 (2)

다음의 내용은 아래의 내용을 읽은 후 책에서 언급되는 구문을 기반으로 생각 정리한 글 입니다.

 

1.3 DAO의 확장

1.3.1 클래스의 분리

1.3.2 인터페이스의 도입

1.3.3 관계설정 책임의 분리

1.3.4 원칙과 패턴 (개방 폐쇄 원칙 | 높은 응집도와 낮은 결합도 | 전략 패턴)

 

 

1. 객체는 유연하게 변할 수 있으며 관심사에 따라 성격(본질)이 달라진다.
여기서 말하는 성격은 변화의 이유, 시기, 주기(기간)등이 모두 포함된다.

2. 개방 폐쇄 원칙 (Open-Closed Principle) 은 단어의 뜻 그대로 보면 확장엔 열려 있어야하고 변경에는 닫혀 있어야 한다 이며, 조금 풀어쓰자면 나의 객체 A에 대해 코드를 변경하지 않아도 상대방은 객체 A를 본질 그대로 사용하면서
기능을 추가하거나 개선 할 수 있어야 한다는 뜻이다.

3. 도서 예시코드에서는 DAO <-> DConnectionMarker 의 구조를 개선하기위해
인터페이스를 추가하여 DAO -> <Interface> ConnectionMarker <- DConnectionMarker를 예로 설명하였다.
상호간에 직접적인 의존성이 부여 될 경우 코드간 결합도가 높아지므로 둘중한곳에서 수정이 발생하면
다른 한곳도 수정을 해야하는 불가피한 상황이 벌어진다.
이를 중간다리 역할인 <Interface>를 추가하여 직접적인 호출을 하지 않도록 바꾸어주었다.

 

4. RDBMS의 관점에서 보면 마치 mapping table과 얼핏 개념적으로 비슷하다.
그러나 DB mapping-table은 물리적 연결 관계로 데이터를 적재하지만
interface는 논리적 연결 관계로 상호작용만을 나타낸다.
즉, 인터페이스에선 로직 구현이란 것이 전혀 없다.

5.객체지향 설계 원칙(S.O.L.I.D)는 객체지향 프로그래밍이 다채롭게 패러다임의 변화가 오더라도
보편적으로 남아있는 분명한 특징들의 각 앞 이니셜을 따서 부르는 5가지 원칙이다.
명칭은 원칙이지만 무조건 지켜야 한다 라기보단 지킬수록 좋다 라는 가이드라인의 개념을 가진다.
이 설계 원칙은 디자인 패턴과는 다르게 보다 일반적이고 흔한 상황, 즉 평소에 지키면 좋은 것들을 말한다.

ㆍ단일 책임 원칙 (Single Responsibility Princ)
ㆍ개방 폐쇄 원칙 (Open-Closed Principle)
ㆍ리스코프 치환 원칙 (Liskov Substitution Principle)
ㆍ인터페이스 분리 원칙 (Interface Segregalition Principle)
ㆍ의존관계 역전 원칙 (Dependency Inversion Principle)

이 중 개방 폐쇄 원칙은 높은 응집도와 낮은 결합도라는 소프트웨어 개발의 고전적 원리로도 설명이 가능하다.

6. '높은 응집도'란 객체 하나에 같은 목적을 지닌 모든 것들이 똘똘 뭉친 것을 뜻하며
높은 응집도를 지닌 객체 또는 모듈의 코드가 한 곳에서 수정이 발생 할 경우
전체 흐름에서 어느 부분이 얼만큼 바뀌게되고 다른 부분들은 영향이 없는지 신경써야 한다.
응집도가 높으면 성격이 뚜렷하여 기능 또는 목적을 위한 불필요한 코드가 존재하지 않는다.
이를 동일 책임, 같은 관심사 라고도 표현한다.

7. '낮은 결합도'는 객체간 느슨한 연결을 유지하는데 필요한 최소한의 형태만을 남겨놓는 것을 의미하며
객체 A라는 것 하나가 바뀌어도 다른 B,C,D 등에게 영향이 없거나 최소화 되어야 한다는 뜻이다.

결론은 응집도가 높고 상호 결합도가 낮으면 각자 맡은바의 책임만을 수행하므로
개발자 입장에서 이곳 저곳 폭넓게 살펴보지 않아도 되기 때문에 각 모듈 또는 객체의 관리가 보다 수월해진다.

서로가 뒤엉키는 스파게티코드의 형태가 되지 않게 되어 결과적으로 클린코드의 모태가 된다.

8. 전략패턴은 자신의 기능중에서 필요에 따라 변경이 필요한 부분을 인터페이스를 추가하여 통째로 드러내 외부로 분리시켜 개발자의 의도대로 알고리즘 또는 로직 클래스를 별개로 구현 및 관리하는 패턴이다.