객체지향 설계 5원칙 - SOLID

9/28일 TIL에 정리했던 솔리드 5원칙

객체지향 설계 5원칙

SRP 단일 책임 원칙 (single responsibillity principle)

• 한 클래스는 하나의 책임만 가져야 한다.
• 하나의 책임은 클수도, 작을수도 있다.
• 문맥과 상황에 따라 다르다.
• 변경이 있을 때 파급 효과가 적으면 단일 책임 원칙을 잘 따른 것!

Ex) UI변경, 객체의 생성과 사용을 분리

OCP 개방 - 폐쇄 원칙 (Open/closed principle)

• 소프트웨어 요소는 확장에는 열려 있으나 변경에는 닫혀 있어야 한다.
• 인터페이스를 구현한 새로운 클래스를 하나 만들어서 새로운 기능을 구현
  단점
• 구현 객체를 변경하려면 클라이언트 코드를 변경해야한다. (다형성을 사용하지만 OCP 원칙 지킬 수 없음)
  → 객체를 생성하고 연관관계를 맺어주는 별도의 조립, 설정자가 필요해짐 → 이걸 스프링이 도와준다!
  

LSP 리스코프 치환 원칙

• 프로그램의 객체는 프로그램의 정확성을 깨뜨리지 않으면서 하위 타입의 인스턴스로 바꿀 수 있어야 한다.
• 다형성에서 하위 클래스는 인터페이스 규약을 다 지켜야한다. LSP는 이를 보장해야 한다는 원칙이다.
• 즉, 인터페이스를 구현한 구현체를 믿고 사용하기 위해서는 구현체는 꼭 인터페이스를 설계할 때 기대하는 기능에 대해서 정확히 구현해야 한다.

Ex) 자동차 인터페이스에 엑셀 - 앞으로가는 기능이 있다고 했을 때,
구현체에 엑셀 - 뒤로가는 기능으로 구현하면 LSP 원칙을 위반한 것이다.

ISP 인터페이스 분리 원칙

• 특정 클라이언트를 위한 인터페이스 여러개가 범용 인터페이스 하나보다 낫다. (코드가 짧다고 좋은게 절대 아님!)

• 인터페이스가 명확해지고 대체 가능성 또한 높아진다.

Ex) 인터페이스 AB가 A와 관련된 업무 aa와 B와 관련된 bb업무를 한다고 했을 때,

인터페이스 AB를 인터페이스 A와 인터페이스 B로 분리하고 각각 aa와 bb의 역할을 하도록 업무 또한 분리!

DIP 의존관계 역전 원칙 (Dependency inversion principle)

• 추상화에 의존하되며 구체화에 의존하면 안된다.
  → 클라이언트는 구현 클래스에 의존하지 말고 인터페이스에 의존해야 한다.
• 역할에 의존해야한다.
• 클라이언트가 인터페이스에 의존해야 유연한 변경 가능. (구현체에 의존하면 변경이 어려워짐)

객체지향의 핵심은 다형성이지만, 다형성 만으로는 SOLID를 지킬 수 없다. 스프링은 DI와 DI 컨테이너로 다형성과 SOLID(특히 OCP, DIP)를 가능하게 지원한다.

즉, 새로운 구현체를 생성할 때 클라이언트의 코드 변경 없이 기능을 추가할 수 있게 해줌으로 인해 쉽게 부품을 교체하듯이 개발할 수 있게 도와준다!