SRP
OCP(중요)
LSP
ISP
DIP
SRP 단일 책임 원칙
한 클래스는 하나의 책임만 가져야 함.
ex. UI 변경, 객체생성과 객체사용을 분리
중요한 기준은 변경했을 때이다.
변경했을 때 파급 효과가 적으면 단일 책임 원칙을 잘 따른 것.
OCP 개방-폐쇄 원칙
확장에는 열려 있고 변경에는 닫혀 있어야 한다.
역할과 구현은 분리된다는 다형성을 생각해보자.
새로운 클래스를 만드는 것과 기능을 바꾸는 것은 독립적이어야 한다는 것이다.
위의 코드는 OCP가 지켜지지 않은 코드이다.
객체가 바뀌면 인터페이스에 들어오는 서버가 바뀌어 코드 수정이 필요하기 때문이다.
LSP 리스코프 치환 원칙
"리스코프 치환 원칙"
단순히 컴파일 성공을 넘어서는 이야기로,
다형성을 위해 하위클래스는 인터페이스 규약을 다 지켜야 함.
ex. 자동차 인터페이스의 엑셀은 앞으로 가는 기능을 구현해야지, 뒤로 가게 구현하면 위반.
ISP 인터페이스 분리 원칙
특정 클라이언트를 위한 인터페이스 여러 개가 범용 인터페이스 하나보다 낫다.
ex. 자동차 인터페이스 -> 운전 인터페이스 / 정비 인터페이스 로 분리
사용자 클라이언트 -> 운전자 클라이언트 / 정비사 클라이언트 로 분리
=> 정비 인터페이스 자체가 변해도, 운전자 클라이언트에 영향을 주지 않음 ( 독립적 !! )
=> 인터페이스가 명확해지고, 대체 가능성도 높아짐
DIP 의존관계 역전 원칙
추상화 >>> 구체화
인터페이스 >>> 구현 클래스
역할 >>> 구현
결국.. 셋 다 같은 의미다.
구현보다 역할에 의존해야 변경이 용이해진다.
하지만 MemberService는 인터페이스와 구현클래스 모두에 의존한다.
MemberRepository m=new MemoryMemberRepository();
위의 코드는 DIP를 위반한다.
즉, 다형성 만으로는 OCP와 DIP를 지킬 수 없어 뭔가가 더 필요하다는 뜻이다.
'웹개발 > 스프링' 카테고리의 다른 글
[Inflearn] 회원 도메인 개발 (0) | 2025.01.29 |
---|---|
[Inflearn] 회원 도메인 설계 (0) | 2025.01.29 |
[Inflearn] 비즈니스 요구사항과 설계 (0) | 2025.01.29 |
[Inflearn] 좋은 객체 지향 프로그래밍이란? (0) | 2025.01.26 |
[Inflearn] 스프링 (0) | 2025.01.25 |