[오브젝트] 유연한 설계

skayjays·2021년 12월 20일
0

오브젝트

목록 보기
2/4

개방-폐쇄 원칙

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

  • 확장에 대해 열려 있다. 애플리케이션의 요구사항이 변경될 때 이 변경에 맞게 새로운 '동작'을 추가해서 애플리케이션의 기능을 확장할 수 있다.
  • 수정에 대해 닫혀 있다. 기존의 '코드'를 수정하지 않고도 애플리케이션의 동작을 추가하거나 변경할 수 있다.

컴파일타임의 의존성을 고정시키고 런타임 의존성을 변경하라.

  • 개방-폐쇄 원칙을 수용하는 코드는 컴퍼일타임 의존성을 수정하지 않고도 런타임 의존성을 쉽게 변경 할 수 있다.

추상화가 핵심이다

  • 개방-폐쇄 원칙의 핵심은 추상화에 의존하는 것이다.
  • 추상화란 핵심적인 부분만 남기고 불필요한 부분은 생략함으로써 복잡성을 극복하는 기법이다.
  • 개방-폐쇄 원칙을 가능하게 하는것은 의존성 방향이다.
  • 변경되지 않을 부분을 신중하게 결정하고 올바른 추상화를 주의 깊게 선택 해야한다.

생성 사용 분리

  • 유연하고 재사용 가능한 설계를 원한다면 객체와 관련된 두 가지 책임을 서로 다른 객체로 분리해야 한다. 객체생성, 객체사용
  • 객체생성 책임을 Factory 클래스에 할당한다.

순수한 가공물에게 책임 할당하기

  • 시스템을 객체로 분해하는 데는 크게 두가지 방식이 존재한다.
    • 표현적 분해: 도메인에 존재하는 사물 또는 개념을 표현하는 객체들을 이용해 시스템을 분해하는 것.
    • 행위적 분해: 어떤 행동을 책임질 마땅한 도메인 개념이 존재하지 않는다면 PURE FABRICATION을 추가하고 이객체에게 책임을 할당하는것.

도메인의 본질적인 개념을 표현하는 추상화를 이용해 애플리케이션을 구축하기 시작하라.

의존성 주입

  • 생성자 주입
  • setter 주입
  • 메서드 주입
  • 숨겨진 의존성은 나쁘다.

의존성 역전 원칙

  • 상위 수준의 모듈은 하위 수준의 모듈에 의존해서는 안된다. 둘 모두 추상화에 의존해야 한다.
  • 추상화는 구체적인 사항에 의존해서는 안 된다. 구체적인 사항은 추상화에 의존해야 한다.

훌륭한 객체 지향 설계를 위해서는 의존성을 역전시켜야 한다. 그리고 의존성을 역전시켜야만 유연하고 재사용 가능한 설계를 얻을 수 있다.

유연성에 대한 조언

  • 유연한 설계는 유연성이 필요할 때만 옳다.
  • 협력과 책임이 중요하다.

의존성을 관리해야 하는 이유는 역할, 책임, 협력의 관점에서 설계가 유연하고 재사용 가능해야 하기 때문이다. 따라서 역할, 책임, 협력에 먼저 집중하라.

정리

이번 장에서는 유연한 설계에 관해 공부하였다. 실제 개발을 진행할 때 많이 고려하는 개방-폐쇄원칙과 의존성 역전에 대해 정리가 잘되어 있어서 이해가 쉽게 되었다. 그리고 마지막에 조언 부분에 공감이 되었던 부분은 역할, 책임, 협력에 먼저 집중하라는 저자의 말이었다. 의존성 관리하는 것도 중요하지만 해당 객체가 어떤 책임을 갖는지에 더 집중하고 그에 맞는 상위 하위를 잘 구분해서 의존성 관계를 설정한다면 좋은 품질의 소프트웨어를 만들 수 있지 않을까 생각해본다.

profile
기초를 탄탄하게

0개의 댓글