1. SRP(Single Responsibility Principle)
- 단일 책임 원칙 (한 클래스는 하나의 책임만 가져야 한다. )
- 하나의 책임이라는 것은 클 수도 있고 작을 수도 있다. 문맥과 상황에 따라 다르다. 책임은 기능이라고 해석할 수도 있다.
- 중요한 것은, 클래스가 변경되는 이유가 한 가지여야 한다는 것이다. 클래스를 변경했을 때, 파급 효과가 크다면 SRP를 지키지 않은 설계이다.
**책임.. 이라 하면, AppConfig라는 클래스가 있을 때, 이 클래스는 구현 객체를 생성하고 연결하는 책임을 갖고있다. 라고 말할 수 있다.
2. OCP(Open/Closed Principle)*
- 개방-폐쇄 원칙 (확장에는 열려 있어야 하고 변경에는 닫혀 있어야 한다.)
- 다형성을 활용하여 인터페이스를 구현한 클래스를 만들어서 새로운 기능을 구현한다.(확장) 이제 변경을 적용할 때, OCP 원칙이 깨진다. 예제를 보면,
기능을 확장하기 위해서 MemberRepository 인터페이스를 JdbcMemberRepository로 구현하였다. 이제, MemberService 클라이언트가 구현 클래스를 직접 선택해야 하는 변경이 발생한다. 이 문제를 해결하기 위해 스프링이 등장하였다.
3. LSP(Liskov Substitution Principle)
- 리스코프 치환 원칙 (상위 타입 객체를 하위 타입 객체로 치환해도 정상적으로 동작해야 한다.)
- 다형성을 지원하기 위한 원칙으로, 인터페이스를 구현한 클래스들은 해당 인터페이스의 규약을 지켜야 함을 의미한다. 단순히 문법적인 것을 넘어서, 기능의 일관성을 의미한다.
- 예를 들면, 자동차 인터페이스에서 엑셀을 밟으면 앞으로 나아간다는 규약이 있는데, 자동차를 구현한 K5에서 엑셀을 밟으면 뒤로 간다면, 물론 컴파일에는 문제가 없지만, LSP를 위배한 것이다.
- 단순히 컴파일을 넘어서 기능과 규약에 관련된 원칙
4. ISP(Interface Segregation principle)
- 인터페이스 분리 원칙 (하나의 범용 인터페이스 보다 여러 개의 구체적인 인터페이스가 좋다)
- 목적이 다른 클라이언트를 위해서 해당 목적에 따른 인터페이스를 분리해야 한다.
- 예를 들면, 휴대폰이라는 인터페이스가 있을 때, 전화, 웹 서핑, 카메라 등의 인터페이스로 분리시키면 클라이언트는 목적에 맞는 인터페이스를 통해 객체에 접근할 수 있다.
5. DIP(Dependency Inversion Principle)*
- 의존 관계 역전 원칙 (상위 수준 모듈이 하위 수준 모듈에 의존하면 안되고, 하위 수준 모듈이 상위 수준 모듈에 의존해야 한다.)
- 구현 클래스에 의존하지 말고 인터페이스에 의존해야 한다는 뜻이다. 구현체에 의존하게 되면 변경이 매우 힘들어진다.
- 예를 들어, 운전자(클라이언트)가 자동차(인터페이스)에 대해서만 알고 운전 방법만 습득하고 있으면, 자동차가 K5(구현 클래스)든, 지바겐(구현 클래스)이든 운전할 수 있다.
- 하지만
Record What I Learned