22일차 - OCP 적용하기

2023.08.24 THU

276p ~ 290p

 

21일차 내용 ⬇️

2023.08.23 - [개발 서적 기록/오브젝트_조영호] - 21일차 - 바람직한 의존성

21일차 - 바람직한 의존성

---

표준 클래스는 의존은 해롭지 않다

표준 클래스는 내부 코드가 수정될 확률이 매우 낮기 때문에 직접 인스턴스를 직접 생성하더라도 문제되지 않는다.

 

하지만 표준 클래스를 활용해서 인스턴스를 직접 생성할 때에도, 가능한 추상적인 타입을 사용하는 것이 좋다.

예를 들어, ArrayList 인스턴스를 생성할 것이라면 List 타입의 객체로 변수를 선언한 뒤에 ArrayList 인스턴스를 직접 생성하는 것이다.

이를 통해서 구현 표준 클래스를 유연하게 교체할 수 있도록 만들 수 있다.

 

OCP Open-Closed Principle 개방 폐쇄 원칙

확장 가능하고 변화에 유연하게 대응할 수 있는 설계를 만들어야한다.

클래스, 모듈 함수와 같은 소프트웨어 개체는 확장에 대해 열려 있어야하고, 수정에 대해서는 닫혀 있어야한다.

 

따라서 요구사항이 변경될 때에는 새로운 동작을 추가해서 기능을 확장하고, 이러한 동작을 추가하거나 변경할 때에는 기존의 코드를 수정하지 않아야한다.

 

OCP 적용 : 컴파일 타임 의존성을 고정시키고 런타임 의존성을 변경하라

런타임 의존성은 실행시에 협력에 참여하는 객체들 간의 관계를 나타낸다.

반면 컴파일 타임 의존성은 코드에서 드러나는 클래스들 사이의 관계를 나타낸다.

OCP를 적용하기 위해서는 컴파일 타임 의존성은 유지하면서 런타임 의존성의 가능성을 확장하고 수정할 수 있는 구조다.

 

OCP 적용 : 추상화에 의존하라

핵심적인 부분만 남기고 불필요한 부분은 생략함으로써 복잡성을 극복하자. 즉 추상화하라

OCP에 추상화를 적극적으로 적용하면, 공통적인 부분은 문맥이 바뀌더라도 변하지 않기 때문에 수정할 필요가 없어서 수정에 닫혀있게 된다.

 

OCP 적용 : 결합도를 낮춰라 - 생성과 사용을 분리하라

알아야하는 지식이 많으면 결합도가 높아진다. 

특히, 객체를 생성하는 부분에 많은 지식을 요구하면 결합도가 높아진다. 객체를 생성하기 위한 특정 컨텍스트에 강하게 결합된다.

 

그래서 객체에 대한 생성과 사용을 분리해야한다. ( Seperate use from creation )

이를 위해서는 객체를 생성하는 책임을 클라이언트로 옮겨야한다.

특정 컨텍스트를 위한 인스턴스를 생성하는 책임을 클라이언트에게 맡겨서, 구체적인 컨텍스트와 관련된 정보를 클라이언트로 옮기고 추상화된 인스턴스를 사용하게 된다.