6장 - OOD(객체지향 개발)의 원칙

설계의 품질

 

 

• 잘 설계 된 시스템은 이해하기 쉽고, 바꾸기도 쉽고, 재사용하기도 쉽다.
• 개발하는데 특별히 어렵지도 않고, 단순하고 간결하며 경제적이다.
• 잘 설계 시스템을 개발하는 일은 즐겁다.

나쁜 설계의 냄새

1. 경직성: 무엇이든 하나를 바꿀 때마다 반드시 다른 것도 바꿩야 하며, 그러고 나면 또 다른 것도 바꿔야 하는 변화의 사슬이 끊이지 않기 때문에 시스템을 변경하기 힘들다.
2. 부서지기 쉬움: 시스템의 한 부분을 변경하고 나면 그것과 전혀 상관없는 다른 부분이 작동을 멈춘다.
3. 부동성: 여러 컴포넌트로 분리해서 재상요하기 힘들다.
4. 끈끈함: 편집-컴파일-테스트 순환을 한 번 도는 시간이 엄청길다.
5. 쓸데없이 복잡함: 필요없는 반복: copy - paste 같다.
6. 투명함: 코드를 만든 의도에 대한 설명을 볼 때 그 설명에 "표현이 꼬인다"라는 말이 어울림

의존 관계 관리하기

단 하나의 책임 원칙(The Single Responsibilty Principle - SRP)

• 어떤 클래스를 변경해야 하는 이유는 오직 하나뿐이어야 한다.
• 클래스는 오직 하나만 알아야 한다.
• 오직 하나의 책임만 져야 한다.
• 더 핵심적인 말로 바꿔보면, 어떤 클래스를 변경해야 하는 이유는 오직 하나뿐이어야 한다.

개방-폐쇄 원칙(The Open-Closed Principle - OCP)

• 소프트웨어 엔티티(클래스, 모듈, 함수 등등)는 확장에 대해서는 개발되어야 하지만, 변경에 대해서는 폐쇄되어야 한다.

 

리스코프 교체 원칙(Liskov Substitution Principle - LSP)

 

• LSP를 지키지 않았다는 말은 곧 OCP도 지키지 않았다는 말이다.

의존 관계 역전 원칙(Dependency Inversion Principle - DIP) 

 

• 고차원 모듈은 저차원 모듈에 의존하면 안 된다. 이 두 모듈 모두 다른 추상화된 것에 의존해야 한다.

• 추상화된 것은 구체적인 것에 의존하면 안 된다. 구체적인 것이 추상화된 것에 의존해야 한다.

  • 자주 변경되는 컨크리트 클래스에 의존하지 마라
  • 어떤 클래스를 상속받아야 한다면, 기반 클래스를 추상 클래스로 만들어라
  • 어떠 클래스 참조를 가져야 한다면, 참조 대상이 되는 클래스르르 추상 클래스로 만들어라.
  • 만약 어떤 함수를 호출해야 한다면, 호출되는 함수를 추상 함수로 만들어라

인터페이스 격리 원칙(Interface Segregation Principle - ISP)

 

• 클라이언트는 자신이 사용하지 않는 메소드에 의존 관계를 맺으면 안 된다.

결론