객체 지향 설계 5원칙 SOLID

객체 지향 설계 5원칙 SOLID

1. SRP(Single Responsibility Principle) - 단일 책임 원칙

한 클래스는 하나의 책임(역할)만 가져야 한다.

역할의 분리라고 생각하면 편하다!
변경이 있을 때 파급 효과가 적으면 단일 책임 원칙을 잘 따르는 것

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

확장 에는 열려 있으나 변경 에는 닫혀 있어야 한다.

  • 기존 코드에 대한 수정은 직접적으로 하지 않고 기능을 확장, 추가 할 수 있도록 해야 한다.
  • 인터페이스와 추상 클래스를 이용해 공통적인 작업에 대해 추상화 를 진행
  • 상속과 구현을 이용해 기존 코드(상위 클래스)에 대한 수정 없이 기능을 확장시킬 수 있다.
  • 이는 곧 다형성 을 이용한 기능 확장이다.

OCP 문제점

  • 구현 객체를 변경하기 위해서는 Client 코드를 변경해야 하는 문제점이 있다.
  • 코드 변경이 이뤄지기 때문에 OCP 원칙을 깨지게 된다.
  • 객체를 생성 하고 연관관계 를 맺어주는 별도의 조립, 설정자가 필요하다.
    • Spring 에서는 Spring Container 가 해당 역할을 한다.
class OwnerController {
// private OwnerRepository repository = new MemoryOwnerRepository();

// MemoryOwnerRepository 에서 JdbcOwnerRepository 로 변경하기 위해서는 코드에 대한 변경이 필요하다.
private OwnerRepository repository = new JdbcOwnerRepository();
}

3. LSP(The Liskov Substitution Principle) - 라스코프 치환 원칙

프로그램의 객체는 프로그램의 정확성을 깨뜨리지 않으면서 하위 타입의 인스턴스로 바꿀 수 있어야 한다.

인터페이스 규약을 잘 지켜야 한다.

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

하나의 범용 인터페이스보다 특정 클라이언트를 위한 여러 인터페이스가 좋다.

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

프로그래머는 추상화 에 의존해야지, 구체화 에 의존하면 안된다.

  • 구현 클래스에 의존하지 않고, 인터페이스에 의존하라는 뜻이다.
  • Client 가 인터페이스에 의존해야 유연하게 구현체를 변경할 수 있다.

스프링과 객체 지향 원칙

스프링은 DI(Dependency Injection)과 DI 컨테이너를 통해 OCPDIP를 가능하게 지원한다.

client의 코드 변경 없이 개발이 가능하다.

Share