
서론 - 이전 포스트까지의 코드는 역할과 구현을 분리하여 설계하였다. - 하지만 새로운 기능의 확장을 위해 결국 OrderServiceImpl의 코드를 변경하였다. (OCP 위반) - 또한 인터페이스 뿐만 아니라 구현체에도 의존하고 있었다. (DIP 위반) - 이를 극복하기 위해 클라이언트인 OrderServiceImpl에 DiscountPolicy의 구현 객체를 대신 생성하고 주입해야 한다 는것을 알게되었다. - 이번 포스트에선 OCP와 DIP를 지키기위해 "구현 객체를 생성"하고, "연결"하는 책임을 가지는 별도의 설정 클래스 AppConfig를 만들것이다. AppConfig 생성 기존의 MemberServiceImpl은 사진과 같이 MemberRepository 인터페이스와 MemoryMemberR..

서론 - 이전 포스트에서 순수 Java만 사용하여 비즈니스 요구사항에 맞게 프로젝트를 설계하였다. - 이제 새로운 할인 정책을 개발하여 프로젝트를 확장해보자. - 이때, 객체 지향의 설계 원칙을 잘 준수했는지 확인해 보자. 1. 새로운 할인 정책 개발 - 상황 : 서비스 오픈 직전에 할인 정책에 대한 기획자의 요구사항이 변경되었다. 기획자 : 고정 할인 정책(1000원)이 아니라 정률 할인 정책(10%)으로 바꿉시다! 개발자 : ㅠㅠ RateDiscountPolicy 추가 새로운 할인 정책을 설계했으면 이제 OrderService에서 기존에 사용하던 FixDiscountPolicy대신 RateDiscountPolicy로 대체한다. 이때, 문제점이 발견된다. 분명히 역할과 구현을 충실하게 분리했다. 다형성..
- Total
- Today
- Yesterday
- 자바
- S2
- g4
- 문자열
- 구현
- 코딩새내기
- 다익스트라
- 리액트 네이티브
- map
- S3
- PriorityQueue
- Spring
- java
- 현꾸라지
- DFS
- G5
- react
- 백준
- 객체지향
- 백트래킹
- react native
- SWEA
- 그리디
- Spring Boot
- 리액트
- 시뮬레이션
- 우선순위큐
- laugh4mile
- BFS
- 알고리즘
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | ||||||
2 | 3 | 4 | 5 | 6 | 7 | 8 |
9 | 10 | 11 | 12 | 13 | 14 | 15 |
16 | 17 | 18 | 19 | 20 | 21 | 22 |
23 | 24 | 25 | 26 | 27 | 28 | 29 |
30 | 31 |