Skip to content
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
31 changes: 31 additions & 0 deletions vol01/[1주차]_1장_오브젝트와_의존관계_이규원.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,31 @@
```DAO : DB를 사용해 데이터를 조회하거나 조작하는 기능을 전담하도록 만든 오브젝트를 말한다. ```

객체지향 설계에서의 좋은 설게란 변화에 용이한 설계이다. 요구사항이란 언제든 변할 수 있고 이를 구현한 코드는 언제든 변한다.
그렇다면 미래의 변화 대비하여 어떻게 설계하고 개발을 할 것인가? 변경이 일어났을 때 필요한 작업을 최소화하고, 그 변경이 다른 곳에 문제를 일으키지 않으려면 **분리와 확장**을 고려한 설계가 있어야한다.
관심이 같은 것끼리 모으고, 다른 것은 따로 떨어져 있게 **관심사를 분리**해야한다.

앞에서 `DAO`의 정의를 썼는데 DAO는 데이터를 조회하거나 조작하는 기능을 전담하도록 만든 오브젝트이다. 그렇다면 DAO의 관심사는 `데이터를 조회하거나 조작하는 기능`인 것이다.
DAO는 DB 접속 정보가 궁금하지 않다. 이를 분리해야한다.

템플릿 메소드 패턴 또는 팩토리 메소드 패턴으로 관심사항이 다른 코드를 분리해내고, 서로 독립적으로 변경 또는 확장할 수 있지만 **상속**을 사용했다는 단점이 있다.
**상속**은 간단하고 편리하지만 한계점들이 있다. 상속관계는 두 가지 다른 관심사에 대해 긴밀한 결합을 허용한다. 두 클래스가 서로 긴밀하게 연결되어 있지 않도록 중간에 추상적인 연결고리(인터페이스)를 만들어준다.
**인터페이스**는 어떤 일을 하겠다는 기능만 정의해놓고 자신을 구현한 구체적인 정보는 모두 감춰버린다. 그냥 **연결고리**이다. 인터페이스를 통해 접근하게 하면 실제 구현 클래스를 바꿔도 접근하는 쪽에서는 신경 쓸 일이 없다. 런타임시 클라이언트가 구체적인 정보를 설정한다.

### 개방 패쇄 원칙 (Open-Closed Principle)
객체지향 설계의 원칙 중 하나이다. `클래스나 모듈은 확장에는 열려 있어야 하고 변경에는 닫혀 있어야 한다.`
인터페이스를 통해 제공되는 확장 포인트는 확장을 위해 활짝 개방되어 있다. 반면 인터페이스를 이용하는 클래스는 자신의 변화가 불필요하게 일어나지 않도록 굳게 패쇄되어 있다.
잘 설계된 객체지향 클래스의 구조는 개방 패쇄 원칙을 아주 잘 지키고 있다.

개방 패쇄 원칙은 높은 응집도와 낮은 결합도로도 설명이 가능하다.
응집도가 높다는 것은 하나의 모듈, 클래스가 하나의 책임 또는 관심사에만 집중되어 있다는 뜻이다. 즉 변경이 일어날 때 모듈의 많은 부분이 **함께** 바뀐다.
낮은 결합도는 높은 응집도보다 민감한 원칙이다. 책임과 관심사가 다른 모듈과는 느슨하게 연결된 상태를 유지해야한다. 꼭 필요한 최소한의 방법만 알도록하고 나머지는 알 필요가 없게 만들어야 한다.
결합도가 낮아야 변화에 대응하는 속도가 높아지고, 구성이 깔끔해진다.

### 전략 패턴(Strategy Pattern)
> 자신의 기능 맥락에서, 필요에 따라 변경이 필요한 알고리즘을 인터페이스를 통해 통째로 외부로 분리시키고, 이를 구현한 구체적인 알고리즘 클래스를 필요에 따라 바꿔서 사용할 수 있게 하는 디자인 패턴

개방 패쇄 원칙의 실현에 가장 잘 맞는 패턴이다.

### 제어의 역전 (IoC)
프로그램의 제어 흐름 구조가 뒤바뀌는 것이다. 모든 제어 권한을 자신이 아닌 다른 대상에게 위임해 오브젝트가 자신이 사용할 오브젝트에 대해 모른다.
모든 오브젝트는 위임받은 제어 권한을 갖는 특별한 오브젝트에 의해 결정되고 만들어진다.