[Spring] SOLID

단일 책임원칙_SRP (Single Responsibility Principle)

• 한 클래스는 하나의 책임만 가져야한다.
• 이에 대한 기준은 변경이다. 변경이 있을때 파급효과가 적으면 단일 책임원칙을 잘 따른것

클라이언트 객체는 직접 구현객체를 생성하고, 실행하는 다양한 책임을 가지고 있었음
SRP 단일 책임 원칙에 따라 관심사를 분리함
구현 객체를 생성하고 연결하는 책임은 AppConfig가 담당
클라이언트 객체는 실행하는 책임만 담당

개방-폐쇄의 원칙_OCP (Open Closed Principle)

• 소프트웨어 요소는 확장에는 열려 있으나 변경에는 닫혀 있어야 한다.
• 다형성을 활용하여 새로운 기능을 구현
• 구현 객체를 변경하려면 클라이언트 코드를 변경해야 한다. (다형성을 사용했지만 OCP 원칙을 지킬 수 없다)
  -> 객체를 생성하고, 연관관계를 맺어주는 별도의 조립, 설정자가 필요하다.

다형성을 사용하고 클라이언트가 DIP를 지킴으로써 애플리케이션을 사용영역과 구성영역으로 구분했다
AppConfig가 의존관계를 FixDiscountPolicy -> RateDiscountPolicy로 변경해서 클라이언트 코드에 주입함므로
클라이언트 코드는 변경하지 않아도된다.

리스코프 치환원칙_LSP (Liskov Substitution Principle)

• 프로그램의 객체는 프로그램의 정확성을 깨뜨리지 않으면서 하위 타입의 인스턴스로 바꿀수 있어야 한다.
• 다형성에서 하위 클래스는 인터페이스 규약을 다 지켜야 한다는 것, 다형성을 지원하기 위한 원칙, 인터페이스를 구현한 구현체는 믿고 사용하려면, 이 원칙이 필요하다.
• 기능적으로 보장이 필요하다. 즉, 인터페이스가 향하고자하는 기본 기능을 정확히 동작해야한다.

인터페이스 분리 원칙_ISP (Interface Segregation Principle)

• 특정 클라이언트를 위한 인터페이스 여러개가 범용 인터페이스 하나보다 낫다
• 큰 범위의 인터페이스 1개보다는 세부적인 기능을 가진 여러개의 인터페이스를 사용하는 것이 좋다.

의존관계 역전 원칙_DIP (Dipendency Inversion Principle)

• 프로그래머는 "추상화에 의존해야지, 구체화에 의존하면 안된다".
• 클라이언트 코드가 구현 클래스를 바라보는 것이 아닌 인터페이스를 바라보아야 한다.

• 객체 지향의 핵심은 다형성
• 다형성만으로는 쉽게 부품을 갈아 끼우듯이 개발할 수 없다.
• 다형성만으로는 구현 객체를 변경할 때 클라이언트 코드도 함께 변경된다.
• 다형성만으로는 OCP, DIP를 지킬 수 없다.

새로운 할인 정책을 개발하고, 적용하려고 하니 클라이언트 코드도 함께 변경해야 했다. 왜냐하면 기존 클라이언트 코드는 DIP를 지키며 DiscountPolicy 추상화 인터페이스에 의존하는것같았지만 FixDiscountPolicy 구체화 구현 클래스도 함께 의존했다.
AppConfig가 FixDiscountPolicy 인스턴스를 클라이언트 코드 대신 생성해서 클라이언트 코드에 의존관계를 주입함으로써 클라이언트 코드는 DiscountPolicy 추상화 인터페이스만 의존하는 형태로 완성된다.

---

스프링은 다음 기술로 다형성 + OCP, DIP를 가능하게 지원

• DI(Dependency Injection) : 의존관계, 의존성 주입
• DI 컨테이너 제공
• 클라이언트 코드의 변경 없이 기능 확장
• 쉽게 부품을 교체하듯이 개발

정리

• 모든 설계에 역할과 구현을 분리
• 애플리케이션 설계도 공연을 설계하듯이 배역만 만들어두고, 배우는 언제든지 유연하게 변경할 수 있도록 만드는 것이 좋은 객체 지향 설계다.
• 이상적으로는 모든 설계에 인터페이스를 부여하자.