장바구니에 할인 프로모션 적용
Cart 전체 금액 ≥ Promotion 기준 금액
시스템 Promotion — Cart (Cart에 PROMOTION을 연결)
절차적인 설계 vs 객체지향 설계
절차적인 설계
- data와 process가 따로 나뉘어져 있음
public class PromotionProcess { public void apply(Promotion promtoion, Cart cart) { if (isApplicableTo(promotion, cart) { promtoion.setCart(cart.getId()); } private boolean isApplicableTo(Promotion promotion, Cart cart) { } }
객체지향적인 설계
데이터와 프로세스가 같이 있음.
변경
요구사항이 변경될 때 각각의 코드가 어떻게 변경되는지를 보아야 함
할인 여부를 판단하는데 사용하는 데이터를 변경한다면?
Cart 전체 금액 ≥ Promotion 기준 금액 → P
절차적인 설계는 데이터와 프로세스가 별도 클래스에 구현되어 있기에, 데이터를 바꾸면 그 데이터를 사용하는 프로세스도 같이 바뀐다. 결합도가 높음
객체지향 설계는 데이터가 바뀌면서 데이터를 사용하는 로직이 같이 있어서 데이터 요구사항이 변경되어도 하나의 클래스만 바꾸면 됨. 결합도가 낮음
객체지향에서는 어떤 로직을 분리를 한다고 했을 때 그 데이터도 같이 분리가 된다.
타입이 확장되는 경우가 많은지, 기능이 추가되는 경우가 많은지에 따라 절차적 설계, 객체지향적 설계가 좋은지가 구분이 된다. 기능만 추가되는 경우는 절차지향적 설계가 괜찮음. 타입 확장은 안되고, 데이터 처리 로직만 있다면.
절차적인 설계
- 포맷 변경을 위한 데이터 변환
- 데이터 중심
- 데이터 노출
- 기능 추가에 유리
데이터를 가지고 가공해서 짜는 코드라면 절챠적 설계
객체지향 설계
- 규칙에 기반한 상태변경
- 행동 중심
- 데이터 캡슐화
- 타입 확장에 유리
유사하게 행동하는 여러개의 타입들. 메시지 관점에서 같지만, 구현방법이 달라진다면 객체지향이 훨씬 유리
레이어 기준으로 보면
- 프레젠테이션 레이어
- 데이터 변환. 절차적
- 서비스 레이어 : 말 그대로 절차. 애플리케이션 플로우 처리. 특정한 알고리즘에 따라 시퀀스를 정의
- 도메인 레이어
- 객체지향. 규칙 기반의 상태 변경
- 퍼시스턴스 레이어
- 절차적. 데이터 변환
절차적인 데이터 조회
- 프레젠테이션 레이어 → 서비스 레이어 → 퍼시스턴스 레이어 (데이터 조회)
모든 패러다임이 유용한 경우는 항상 있다.
모든 기술, 모든 설계에 대한 것들은 다 용도가 있다.
뭐가 좋은지 안좋은지를 이야기할 때 유용한 컨텍스트를 이야기하지 않고 나의 상황만 보면 오해가 생길 수 있다.
언제 유용한지를 보는 것이 중요하다. 도구하나 배운다는 생각.
코드의 목적과 변경의 방향성에 따라 언제 어떤 기술을 사용할지 결정하세요