13일차 - 다형성을 고려하자. 메서드를 분해하자.

2023.08.14 FRI

153p ~ 171p

 

12일차 내용 ⬇️

2023.08.13 - [개발 서적 기록/오브젝트_조영호] - 12일차 - 변경될 가능성이 있는 클래스를 찾아라

12일차 - 변경될 가능성이 있는 클래스를 찾아라

---

다형성을 생각하라

객체의 암시적인 타입에 따라서 행동을 분기해야할 때, 다형성을 이용하라.

암시적인 타입을 명시적인 클래스로 정의하고, 행동을 나워서 응집도를 높일 수 있다.

 

객체의 타입에 따라서 변하는 행동은 타입으로 분리하고, 변화하는 행동은 분리한 타입의 책임으로 맡겨서 다형성을 실천한다.

( 이것이 다형성 패턴이다. )

 

조건에 따라서 로직이 분기가 생긴다면 기본적으로 if, else / switch, case를 사용할 수 있지만, 변경에 취약하다.

그래서 다형성을 사용해서, 변경에 취약하지 않게 확장성있는 코드를 작성해야한다.

 

변경될 수 있는 것을 캡슐화하라

하나의 변경이 다른 요소에 영향을 미치지 않도록 방지해야한다.

그래서 변경될 가능성이 높은 개념을 찾아 안정된 인터페이스를 형성해 책임을 지게해야함으로써 캡슐화해야한다.

( 이것이 변경 보호 패턴이다. )

 

이를 통해 예측 가능한 변경으로 여러 클래스가 불안정해지는 것을, 안정적인 인터페이스를 통해 캡슐화시킬 수 있고, 유연한 변경을 실천할 수 있다.

 

구현을 가이드할 수 있는 도메인 모델을 선택하라

도메인 모델은 설계에 필요한 용어를 제공하고, 데이터가 될 뿐만 아니라, 코드의 구조에도 영향을 미친다.

객체지향은 도메인의 개념과 구조를 반영한 코드를 가능하게 만든다. 그래서 도메인의 구조가 코드의 구조에 영향을 끼치게되므로, 이를 고려해서 도메인 모델을 구성해야한다.

 

그렇기에, 코드의 구조가 바뀌면, 도메인의 관점이 함께 바뀐다.

도메인 모델은 도메인에 포함된 개념과 도메인이 요구하는 유연성까지도 반영한다.

그리고, 도메인 모델은 구현과 미르접한 관계를 맺고 있기에, 코드의 변화에 따라 함꼐 변경될 수 있다.

 

메서드의 응집도를 높이자

메서드의 내부 로직, 코드가 매우 길다면 가독성이 떨어지고 유지보수도 어렵고, 재사용도 어렵다.

( 이런 메서드를 몬스터 메서드라고도 부른다. )

 

더 구체적으로는 아래와 같은 문제점이 있다.

• 어떤 일을 수행하는지 한눈에 파악하기 어렵다. 그래서 이해하는데 오랜 시간이 소요된다.
• 하나의 메서드 안에서 많은 작업을 처리한다는 것이므로, 변경이 필요할 때 어떤 부분에 변경해야할지 파악하기 어렵다.
• 메서드 내부의 아주 작은 부분을 수정하게 되더라도, 다른 부분에게 영향을 미쳐서 문제가 커져 버그가 발생하기 좋다.
• 로직의 일부만 재사용할 수 없다. 재사용하려면, 복붙해야하므로 코드의 중복이 발생한다.

이러한 메서드는 이해를 돕기 위해서 주석이 가득 들어있다.

 

어떤 메서드가 명령문의 그룹으로 구성되어 있고, 그 그룹마다 주석을 달아야한다면 그 메서드의 응집도는 낮은 것이다.

따라서, 내부를 메서드로 작게 분해해서 각 메서드의 응집도를 높여야한다.

이를 통해서 분해된 각 메서드는 목적이 명확해지고, 응집도가 높아지고, 변경이 필요할 때 변경이 필요한 지점을 더 쉽게 파악하고,, 재사용하기도 좋고, 이해하기 쉽다.