↩뒤로가기

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

• SRP : 단일 책임 원칙(single responsibility principle)
• OCP : 개발-폐쇄 원칙(Open/closed principle)
• LSP : 리스코프 치환 원칙(Liskov substitution principle)
• ISP : 인터페이스 분리 원칙(Interface segregation principle)
• DIP : 의존관계 역전 원칙(Dependency inversion principle)

SRP 단일 책임 원칙

<aside> 💡 각 클래스나 모듈은 단 하나의 책임만 가져야 한다는 원칙이다. 즉, 클래스나 모듈이 다수의 책임을 가지면 코드의 유지보수가 어려워지고 버그가 발생할 확률이 높아진다.

</aside>

• 한 클래스는 하나의 책임만 가져야 한다.
• 하나의 책임이라는 것은 모호하다. (클 수도 있고 작을 수도 있다. 문맥과 상황에 따라 다르다.)
• 중요한 기준은 변경이다. 변경이 있을 때 파급 효과가 적으면 단일 책임 원칙을 잘 따른 것
• 예) UI 변경, 객체의 생성과 사용을 분리

OCP 개발-폐쇄 원칙★

<aside> 💡 프로그램은 확장에는 열려있어야 하지만, 수정에는 닫혀있어야 한다는 원칙이다. 즉, 기존의 코드는 수정하지 않고 새로운 기능을 추가할 수 있도록 구조를 설계해야 한다.

</aside>

• 소프트웨어 요소는 확장에는 열려 있으나, 변경에는 닫혀 있어야 한다.
• 근데 java만 가지고 확장하려면, 당연히 기존 코드를 변경해야 하지 않나?
• (일단 지금까지 배운)다형성을 활용한다고 하더라도?

문제점

MemberRepository m = new memoryMemberRepoitory();// 기존 코드
MemberRepository m = new JdbcMemberRepoitory();// 변경 코드
/*
* 구현 객체를 변경하려면 클라이언트 코드를 변경하지 않을 수가 없음
* 분명 다형성을 사용했지만 어쨌든 변경은 해야 하니까 OCP 원칙은 안지켜짐.
* 객체를 생성하고 연관관계를 맺어주는 **별도의 조립, 설정자**가 필요하다.
* **스프링 컨테이너**로 이 문제를 해결