객체지향 개발 원칙

스프링이 개발자에게 제공하는 가치 = 객체지향과 테스트

 

 

※ 객체지향 개발의 원칙 (SOLID)

1. 단 하나의 책임 원칙 (SRP : Single Responsibility Principle)

- 어떤 클래스를 변경해야 하는 이유는 오직 하나뿐이어야 한다.

- 한 클래스에 너무 많은 기능을 담으면 안 된다.

- 비즈니스 객체가 다른 문제와 결합하면, 해당 비즈니스를 참조하는 모든 객체가 Non 비즈니스 문제로 인해 영향을 받을 수 있다.

 

2. 개방-폐쇄 원칙 (OCP : Open-Closed Principle)

- 소프트웨어 엔티티(클래스, 모듈, 함수)는 확장에 대해서는 개방되어야 하지만, 변경에 대해서는 폐쇄되어야 한다. 예를 들면, 모듈 자체를 변경하지 않고도, 그 모듈을 둘러싼 환경을 바꿀 수 있어야 한다.

- 테스트를 먼저 작성하는 방법은 해당 모듈의 변경 없이 환경을 테스트 환경으로 전환할 수 있기 때문에, 이 원칙을 지키는 데 도움이 된다.

- 비즈니스와 데이터베이스 관계, 모델과 뷰의 관계 등 실제 비즈니스 모듈과 환경 및 다른 모듈의 관계를 쉽게 테스트로 대체 가능 한지 살펴보자.

 

3. 리스코프 치환 원칙 (LSP : Liskov Substitution Principle)

- 서브타입은 언제나 자신의 기반 타입(base type)으로 교체할 수 있어야 한다.

- 사용자는 파생 클래스에 대해 알 필요가 없다. 존재 자체도.

- 파생 클래스에서 구현 함수가 호출되는 행위가 옮지 않은 경우 예 : 이 함수에 아무것도 정의하지 않거나, 예외를 던지게 만드는 것

 

4. 인터페이스 격리 원칙 (ISP : Interface Segregation Principle)

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

- 비대 클래스의 경우, 사용자가 자신이 사용하지 않는 메서드를 필연적으로 가지게 되는데 이것은 ISP를 위반한 것이다.

- 클라이언트는 호출하지 않는 메서드에 생긴 변화에도 영향을 받을 수 있다 > 재배포 등.

- 클라이언트가 관심 있는 인터페이스로 비대 클래스를 조각낼 수 있다.

 

5. 의존 관계 역전 법칙 (DIP : Dependency Inversion Principle)

- 고차원 모듈은 저차원 모듈에 의존하면 안 된다.

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

- 자주 변경되는 Concrete 클래스에 의존하지 마라 > 인터페이스나 추상화를 통해 의존 관계를 맺어라

 

※ 객체지향 개발의 원칙 적용

- 언제나 이 원칙을 따르게 노력하는 것은 현명하지 않다.

- OCP를 적용할 상이한 환경을 모두 상상하거나, SRP를 적용할 모든 변경 이유를 생각하려고 쓸데없는 시간을 낭비할 것이다.

- ISP를 지키기 위해 자잘한 인터페이스를 남발하게 될 것이다.

- DIP를 위해 쓸모없는 추상화를 무수히 만들게 될 것이다.

- 결국, 좋은 객체지향 설계란, 능동적으로 적극 적용하려고 노력하는 것이 아니라, 프로그램의 나쁜 냄새를 포착하였을 경우, 그 반응으로써 적용하는 것이다.

- 단위 테스트를 통해 초기에 나쁜 냄새를 포착하는 것이 좋은 방법 중 하나이다.

- 결국, 객체지향 설계란 고차원 정책을 추상 클래스로 분리해 내는 방식이다. 세부 내용은 유도 클래스로 정리해서, 고차원 정책이 세부 내용을 모르게 하는 것이다.