SOLID 법칙과 스프링

SOLID

클린코드로 유명한 로버트 마틴이 좋은 객체지향 설계의 5가지 원칙을 정리함

• SRP : 단일 책임의 원칙
• OCP : 개방 - 폐쇄 원칙
• LSP : 리스코프 치환 원칙
• ISP : 인터페이스 분리 원칙
• DIP : 의존관계 역전 원칙

  SRP 단일 책임 원칙

  한 클래스는 하나의 책임만 가져야 한다

조금 애매한 부분이다. 책임이라는 것이 클수도 있고 작을 수도 있기 때문이다. 하지만 중요한 기준은 변경이다. 뭔가 변경을 하려고 할때 바꿔야할 부분이 적다면 단일 책임 원칙을 잘 따른 것.

OCP 개방-폐쇄 원칙

소프트 웨어는 확장에는 열려 있으니 변경에는 닫혀 있어야 한다.

[[객체 지향 설계와 스프링]]
여기서 배운 다형성과 굉장히 연관이 있다.
예를 들자면
내연차인 k3을 전기차인 테슬라로 바꾼다고 해서 운전하는 법 자체가 바뀌지는 않는다. 내연차인 k3을 전기차인 테슬라로 바꾸는건 확장이다 운전하는 법이 바뀌지 않는 다는 것은 변경에는 닫혀 있다는 것이다.
일반적인 java 환경에서 이것은 거의 지켜지지 않는다

public class MemberService {
    private MemberRepository m = new MemoryMemeberRepository();
}

이 코드를 보면 MemberService(클라이언트) 는 인터페이스인 MemberRepository 와 MemoryMemeberRepository를 모두 알고 있다 사실 클라이언트는 인터페이스인 MemberRepository만 알고 있어야한다. 이 코드는 분명 다형성을 사용했지만 OCP원칙을 지킬수는 없다. 이것을 해결해주는 것이 스프링 컨테이너이다

LSP 리스코프 치환원칙

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

굉장히 간단한 원칙이다 예를 들자면 자동차 interface는 액셀이라는 메소드를 가지고 있고 일반적으로 액셀은 앞으로 가는 기능이다. 하지만 어떤사람이 액셀이라는 메소드의 구현을 뒤로가기로 설정하면..?(혼난다)
즉 다형성에서 하위 클래스는 인터페이스 규약을 다 지켜야 한다는 것. 물론 컴파일은 잘 되겠지만 컴파일을 넘어선 이야기이다.

ISP 인터페이스 분리 원칙

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

자동차 인터페이스 안에 운전에 관한 내용과 정비에 관한 내용을 전부 둘것이 아니라
운전 인터페이스, 정비 인터페이스로 분리하라는 것. (자바스크립트의 함수와 비슷한듯 하다) 관심사의 분리를 해야한다. 이렇게 인터페이스를 두개로 나누면 사용자 클라이언트를 운전자 클라이언트, 정비사 클라이언트로 바꿀 수 있다. 이렇게 되면 정비 인터페이스가 변해도 운전자 클라이언트에 영향을 주지 않는다. 코드가 많으면 보기도 힘들다..

DIP 의존관계 역전 원칙

프로그래머는 추상화에 의존하고 구체화에 의존해선 안된다

구현클래스에 의존하지 말고 인터페이스에 의존하라는 뜻이다.

public class MemberService {
    private MemberRepository m = new MemoryMemeberRepository();
}

위 코드와 같다. 위 코드에서 클라이언트가 구현 클래스를 직접 선택 해버리는 경우다. 이 경우는 구현 클래스를 수정하는 경우 클라이언트 까지 수정이 들어가야 한다. 클라이언트는 인터페이스 만!!! 알고 있어야한다.

스프링

아래의 기술로 다형성 + OCP, DIP를 가능하게 지원한다!!

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

  스프링 장점 예시

1. 아직 RDB를 쓸지 NoSQL을 쓸지 정하지 않았을 때 더미 데이터 구현 클래스를 만들고 교체만하면된다
2. 할인정책이 정해지지 않았을 경우 정책이 정해지면 교체하면 된다.