스프링 핵심 원리_객체 지향(2)

객체 지향 설계 5원칙

객체 지향 설계 5원칙 by 클린코드

• SRP(single responsibility principle) 단일 책임 원칙
  하나의 클래스는 하나의 책임만 가져야 한다.
  하나의 책임이란 것이 모호한데 기준은 변경
  만약 변경 시 파급효과가 적으면 단일 책임 원칙을 잘 따른 것

• OCP(open/closed p) 개방-폐쇄 원칙
  소프트웨어 요소는 확장에는 열려 있으나 변경엔 닫혀 있어야한다.(?)
  인터페이스를 구현한 새로운 클래스를 만드는 것은 기존 코드의 변경이 아님
  객체 a,b가 있을 때 a는 b에 의존한다고 하자.
  b는 인터페이스로 실제 구현된 b1,b2가 있다.
  이 때 a에서 b1을 바라보다가 b2로 변경할 경우 a 내부에서 코드 변경이 일어난다.
  => ocp 원칙이 지켜지지 않는 것.
  문제 해결을 위해 객체 생성과 연관관계를 맺어주는 별도의 무언가 필요
  동적 바인딩 ?

• LSP(liskov substitution p) 리스코프 치환 원칙
  역할에 해당하는 규약을 구현체에서 항상 만족해야함
  ex) 자동차 역할에서 엑셀은 앞으로 가는 기능이라고 정의할 경우, 구현에서
  뒤로 가게 구현하면 LSP 위반한 것.

• ISP(interface segregation p) 인터페이스 분리 원칙
  여러 기능을 모두 포함하는 인터페이스 하나보다 기능별로 나눠 인터페이스 묶음으로 설계하는 것이 바람직함
  ex) 자동차 인터페이스 -> 운전 인터페이스 + 정비 인터페이스의 묶음으로 구현
  이를 통해 운전 클라이언트는 정비에 영향을 받지 않고 반대도 마찬가지.
  즉 역할을 나눔으로 명확해지고 대체도 쉬워짐

• DIP(dependency inversion p) 의존관계 역전 원칙
  ex) A객체가 B객체(역할)를 의존한다고 할 때 A객체는 B의 구현체가 아닌 인터페이스를 바라봐야함.
  구현이 아닌 역할에 의존할 것

  어쨋든 인터페이스를 구현한 인스턴스가 필요한데 인터페이스가 구현체를 참조한 경우 dip를 지키지 못한 것이 된다..
  어떻게 해결하는지,,

스프링

• DI: 의존관계, 의존성 주입
• DI 컨테이너 제공
  이 두가지로 다형성 +OCP,DIP를 가능하게 지원함. 이를 통해 클라이언트 코드의 변경 없이 기능 확장이 가능

정리

• 모든 설계에 역할과 구현을 분리한다
• 이상적으로 모든 설계에 인터페이스를 부여한다
  • 그러나 인터페이스의 도입은 추상화라는 비용이 발생한다. 이 때 비용은
    따라서 기능의 확장 가능성이 적을 경우에는 바로 구체 클래스 사용 가능. 이후 기능 확장이 필요한 경우 인터페이스로 리펙토링