목록Java/Spring (33)
재 현
OrderServiceImpl의 경우 DiscountPolicy(추상 클래스)뿐만 아니라 Rate 혹은 FixDiscountPolicy()를 의존하고 있다. *의존을 알고 있다라고 생각하면 편하다. => OCP 위반 그에 따라 fix -> rate로 구현체로 바뀔 때에도 클라이언트에서 수정을 해야한다. => DIP 위반 따라서, 위의 해결방법은 누군가가 OrderServiceImpl에 RateDiscountPolicy라는 구현 객체를 직접 생성하고 주입시켜줘야 한다. (DI의 탄생)
스프링은 다음 기술로 다형성 + OCP, DIP를 가능하게 지원 DI 의존관계, 의존성 주입 DI 컨테이너 제공 클라이언트 코드의 변경 없이 기능 확장 쉽게 부품 교체하듯이 개발 가능 스프링 없던 시절 어느 개발자가 OCP, DIP원칙을 지키면서 개발하다보니, 너무 할일이 많았다. 배보다 배꼽이 크다. 그래서 프레임워크로 만들어버림 순수하게 자바로 OCP, DIP원칙들을 지키면서 개발을 해보면, 결국 스프링 프레임워크를 만들게 된다. ( 더 정확하게는 DI 컨테이너) 1) 모든 설계에 역할과 구현을 분리하자 (자동차, 공연...) 애플리케이션 설계도 공연을 설계 하듯이 배역만 만들어두고, 배우는 언제든지 유연하게 변경할 수 있도록 만드는 것이 좋은 객체 지향 설계다. 이상적으로는 모든 설계에 인터페이스를..
SRP : 단일 책임 원칙 한 클래스는 하나의 책임만 가져야 한다 하나의 책임이라는 것은 모호하다. (클 수 있고, 작을 수 있으며 문맥에 따라 다름) 중요한 기준은 변경이다. 변경이 있을 때 파급 효과가 적으면 단일 책임 원칙을 잘 따른다 예) ui 변경, 객체의 생성과 사용을 분리 OCP : 개방-폐쇄 원칙(★) 소포트웨어 요소는 확장에는 열려 있으나 변경에는 닫혀 있어야 한다 다형성을 활용 인터페이스를 구현한 새로운 클래스를 하나 만들어서 새로운 기능을 구현 (문제점) MemberService 클라이언트가 구현 클래스를 직접 선택 MemberRepository m = new MemoryMemberRepository(); // 기존코드 MemberRepository m = new JdbcMemberR..