ocp 개방 -폐쇄 원칙

- MemberService 클라이언트가 구현 클래스를 직접 선택 

- MemberRepository m = new MemoryMemberRepository(); // 기존코드 

- MemberRepository m = new JdbcMemberRepository(); // 변경코드 

 

메모리 멤버 리포지토리를 jdbc멤버 리포지토리로 변경하였다 .

 

 

- 구현 객체를 변경하려면 클라이언트 코드를 변경해야 한다. 

- 분명 다형성을 사용했지만 OCP 원칙을 지킬수 없다. 

 

- 이 문제를 어떻게 해결해야하나? 

 

== 객체를 생성하고 , 연관관계를 맺어주는 별도의 조립, 설정자가 필요하다

 

 

Open / Closed / Principle

 

- 소프트 웨어 요소는 확장에는 열려있으나 변경에는 닫혀있어야 한다. 

 

- 이런 거짓말같은 말이 ? 확장을 하려면, 당연히 기존 코드를 변경 ? 

 

- 다형성을 활요해보자 

- 인터페이스를 구현한 새로운 클래스를 하나 만들어서 새로운기능을 구현한다.

 

- 지금까지 배운역할과 구현의 분리를 생각해보자 

 

 

---

 

OCP 개방 - 폐쇄 원칙 

 

문제점 

- 멤버서비스 클라이언트가 구현클래스를 직접 선택한다는 문제점이있다. 

- MemberRepository m = new MemoryMemberRepository(); // 기존코드

- MemberRepository m = new JdbcMemberRepository(); // 변경코드 

 

- 구현 객체를 변경하려면 클라이언트 코드를 변경해야 한다. 

- 분명 다형성을 사용했지만 OCP 원칙을 지킬수 없다. 

 

이 문제를 어떻게 해결해야 할까  ?

 

객체를 생성하고 연관관계를 맺어주는 별도의 조립, 설정자가 필요하다

 

 

---

SRP 단일 책임 원칙 

 

- 한 클래스는 하나의 책임만 가져야한다. 

 - 하나의 책임이라는 것은 모호하다. 

- 클수 있다 / 작을수 있다. 

- 문맥과 상황에 따라 다르다

 

-- 중요한 기준은 변경이다. 변경이 있을때 파급효과가 적으면 단일책임원칙을 잘 따른것

- UI 변경, 객체의 생성과 사용을 분리 

 

---

 

스프링 핵심원리 이해1 - 예제만들기