김영한님의 스프링 핵심 원리 - 기본편을 보고 공부한 내용입니다.
정의 : 확장에는 열려있고, 변경에는 닫혀있어야
다형성의 활용
→ 인터페이스를 구현한 새로운 클래스를 하나 만들어서 새로운 기능 구현
e.g. MemoryMemberRepository → JdbcMemberRepository
→ 구현 객체를 변경하려면 클라이언트 코드를 변경해야함
→ OCP가 깨짐
객체 생성, 연관관계를 맺어주는 별도의 조립, 설정자가 필요
→ 스프링 컨테이너의 역할
e.g. 자동차의 악셀을 뒤로 가게 구현하면 LSP 위반
e.g. 자동차 인터페이스 → 운전 인터페이스, 정비 인터페이스
사용자 인터페이스 → 운전자 인터페이스, 정비사 인터페이스
정의 : 추상화에 의존해야지 구체화에 의존하면 안된다.
→ 클라이언트 코드가 구현 클래스를 바라보는 것이 아닌 인터페이스를 바라보도록!
역활에 의존하게 한다는 뜻과 같음
→ 인터페이스에 의존해야 유연한 변경이 가능
e.g. MemberService
는 MemoryRepository
도 의존하지만, MemoryMemberRepository
도 의존함
→ MemoryService가 구현 클래스를 선택
→ DIP 위반 !!
→ 클라이언트 코드 변경없이 기능 확장 가능
모든 설계에서 역할과 구현을 분리
좋은 객체 지향 설계 : 언제든지 유연하게 변경할 수 있도록 만들기
이상적으로는 모든 설계에 인터페이스 부여
: 어떤 db를 사용할지 정해지지 않은 경우
→ 인터페이스의 도입에는 추상화 비용이 발생 : 개발자 코드를 한번 더 열어봐야
→ 기능 확장의 가능성이 없으면 일단 구체 클래스를 사용하고, 향후에 리팩토링해서 인터페이스 도입도 가능
김영한님의 스프링 핵심 원리 - 기본편을 보고 공부한 내용입니다.