클린코드 강의중 Function Structure를 공부하면서 DIP에 대한 설명을 듣는데 이해가 잘 되지않아서 다시 위의 내용을 번역 + DIP강의를 듣고 정리한 문서이다.
DIP 개요
High Level Policy should not depend on Low Level Details
상위 레벨의 정책은 하위 레벨의 상세함에 의존하지 않아야만 한다.
Copy 라는 상위 레벨의 로직은 하위 레벨의 IO Driver에 의존하면 안된다. 상위레벨의 모듈이 하위 레벨에 모듈에 의존하는 걸 막기 위해서 중간에 Abstract Interface를 만든다. 상위 레벨의 로직이나 하위 레벨의 로직 모두 Abstract Interface에 의존하게 된다.
OO의 핵심
- 상속, 캡슐화, 다형성, 재사용
- 매커니즘이 될순 있지만 핵심이 아니다.
- 재사용: 부모 클래스의구현부를 상속 받는 재사용은 객체지향의 핵심이 아니라 수단이다. 내가 생각했을땐 재사용은 - 핵심 : IoC를 통해 상위 레벨의 모듈을 하위레벨의 모듈로 부터 보호하는것
- 하위레벨은 빈번하게 변경이 될텐데 변경 될때마다 상위레벨까지 영향을 미치게 되면 상위 레벨까지 변경을 해야만 한다.
- DIP가 준수된다면 하위 레벨의 모듈은 OCP를 준수하면서 계속 추가될수 있다. OCP를 통해 새로운 요구사항을 반영할 수 있음 - OO 설계는 의존성 관리이다.
Structured Design
DIP를 설명하는 방법 중 하나
구조적 설계를 하다보면 Top-down 방법대로 설계하게 된다.
Top-down 방법론 : 소스코드(컴파일 타임) 의존성의 방향이 런타임 의존성의 방향과 같다. 런타임의 의존성은 위에서 아래로 갈수 밖에 없다. 하지만 소스코드의 의존성 까지 위에서 아래로 가면 맨 밑에 소스코드가 변경이 되면 그 소스를 사용하는 위에 코드까지 변경에 영향을 미치게 되서 위험하다.
이런 변경에 영향을 없애기 위해서 소스코드의 의존성이 역전(Dependency Inversion)되야 한다.
Dependency Inversion
A가 B에 의존성한 부분에서 인터페이스를 추가하여 A가 B에 의존하지 않고 Interface에 의존하고 B도 Interface에 의존하는 구조로 변경.
Interface가 변경되지 않는다면 B의 변경으로부터 A는 자유로운 구조이다.
객체지향 : 구체적인 로직의 변경으로부터 상위레벨의 로직을 보호하는것
Plugins
System에서는 어떤 Plugin을 호출할지 모른다.
Main은 Application에 Plugin이 된다. App Partition은 POJO,
- OCP에서는 변경이 되는 포인트가 추상화가 되야한다.
- DIP에서는 하위레벨에 의존하고 있는 경우 추상화가 되야한다.
Factory == Repository
Main Partition에서 App에 있는 로직들이 동작하도록 Plugin을 시켜주는 일을 한다. App에서는 객체(Factory)를 사용할때 정의된대로 동작할거라고 생각하며 로직을 수행시킨다. Main에서는 정의된대로 구현되어있는 Factory Impl이 존재하는데 Factory를 사용하는 객체에다가 Factory Impl을 주입해줘야 되는 일이 필요하다. 그리고 주입하는 일을 하는게 Main Partition이고 스프링프레임 워크이다.
화면에 뿌려지는 데이터를 만드는건 Presenter의 역할이고 화면에 데이터를 뿌리는건 View의 역할이다.
— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —
