[참고 강의] 김영한님의 스프링 핵심 원리 - 기본편
💡 좋은 객체 지향 설계의 5가지 원칙
✏️ SOLID
클린코드로 유명한 로버트 마틴이 이 5가지 원칙을 정리하였다.
- SRP : 단일 책임 원칙
- OCP : 개방-폐쇄 원칙
- LSP : 리스코프 치환 원칙
- ISP : 인터페이스 분리 원칙
- DIP : 의존관계 역전 원칙
✏️ SRP 단일 책임 원칙
한 클래스는 하나의 책임만 가져야 한다.
하나의 책임이란 것은 모호하다, 그 책임의 크기도 다를 수 있고 상황에 따라서도 다르다. 그렇기에 강사님께서 중요한 기준은 "변경"이라고 말씀해 주셨다.
변경이 있을 때 미치는 영향이 적으면 단일 책임 원칙을 잘 지킨 것이다. 👍
✏️ OCP 개방-폐쇄 원칙
확장에는 열려있고 변경에는 폐쇄되어야 한다.
이 말이 참 모순이지만 다형성을 활용하면 가능하다.
인터페이스를 만들어서 이 인터페이스를 구현한 새로운 클래스들로 예시를 들 수 있다.
public class MemberService {
private MemberRepository memberRepository = new MemoryMemberRepository();
}public class MemberService {
private MemberRepository memberRepository = new JdbcMemberRepository();
}저번에도 다형성을 정리하며 사용한 예제 코드이다.
이 코드는 OCP 원칙의 입장에서 문제점이 있다.
구현 객체를 변경하려면 클라이언트 코드를 변경해야한다.
멤버 서비스가 생성자를 MemoryMemberRepository에서 JdbcMemberRepository로 변경하므로 다형성엔 성립되지만 OCP 원칙을 지킬 수 없다.
이 문제를 해결하려면 객체를 생성하고 연관관계를 맺어주는 무언가가 필요하다고 한다. 강사님께서 DI 컨테이너가 필요하다고 흘러가듯 말씀해주셨다. 😎
✏️ LSP 리스코프 치환 원칙
프로그램의 객체는 프로그램의 정확성을 깨뜨리지 않으면서 하위 타입의 인스턴스로 바꿀 수 있어야 한다.
말이 너무 어렵다 😱
그냥 인터페이스를 통해 구현된 객체는 인터페이스의 규약을 지키며 정확한 기능을 해야한다는 거 같다. 그래야 믿고 구현체를 쓸 수 있기 때문이다.
예시로 자동차의 엑셀을 밟으면 앞으로만 나아가야하지, 뒤로 나아가면 안된다
✏️ ISP 인터페이스 분리 원칙
범용 인터페이스 하나보다 인터페이스 여러 개가 낫다.
인터페이스 하나가 많은 기능을 가질 필요가 없다.
인터페이스 여러 개가 기능을 쪼개서 갖고 있는 게 낫다는 말이다. 😎
이렇게 하면 인터페이스가 명확해지고, 대체 가능성이 높아진다.
예시로 자동차 인터페이스를 운전과 정비 인터페이스로 각각 분리하면
클라이언트도 운전사 정비사 클라이언트로 분리가 가능해진다.
훨씬 명확해지며 왠지 유지보수도 하기 쉬워질 거 같다.
✏️ DIP 의존관계 역전 원칙
추상화에 의존해야하며 구체화에 의존하면 안된다.
쉽게 말해 구현 클래스 말고 인터페이스에 의존하라는 뜻이다.
예시로 배우는 그 상대 배우 역할에 의존해야지 상대 역의 배우가 바뀐다고 연기를 하지 못하면 안된다.
그렇지만 위에 예시로 든 코드에서 OCP 원칙 뿐 아니라 DIP도 위반한다.
MemberService 클라이언트가 구현 클래스를 직접 선택하므로 인터페이스와 구현 클래스를 동시에 의존하기 때문이다.
즉, 다형성만으로는 OCP, DIP를 지킬 수 없다
이 이야기에서부터 스프링이 왜 필요한지가 설명된다.
💡 객체 지향 설계와 스프링
✏️ 스프링과 객체 지향
스프링은 다음 기술로 다형성 + OCP, DIP를 가능하게 한다.
- DI(Dependency Injection) : 의존 관계, 의존성 주입
- DI 컨테이너 제공
DI를 이용하여 좋은 객체 지향 개발을 할 수 있기에 스프링이 등장했다.
의존 관계 주입은 어떤 객체가 의존 객체를 직접 구현해서 사용하는 게 아닌 주입 받아 사용하는 방법이라고 정리하면 될 거 같다 😊
다음강의부터 코드를 통해 위 원칙을 더 자세히 공부해보겠다.
