강의를 듣고 중요 내용들을 이해한대로 정리하기.
서론
강의를 하다보면 객체지향은 여전히 유효한가요?라는 질문을 자주 받는다고 한다.
동일한 문제를 해결 할 때 절차 지향적인 설계 / 객체 지향적인 설계를 비교하면서 객체 지향의 필요성을 복습해보자.
강의에선 Promotion 과 Cart 로 이루어져 있는 간단한 할인 도메인을 예시로 들었다.
-
절차적인 설계
data, process 로 로직을 분리해서 로직을 실행 (Cart, Promotion / PromotionProcess) -
객체지향 설계
data, process 구분 없이 객체 (Promotion, Cart) 에 각 데이터와 필요한 로직도 가지고 있는 형태
여기서 어떤 코드가 좋은 코드인지, 여러 예제를 통해 좋은 코드에 대해 알아보자!
로직으로 상태를 변경하는 CASE
CASE 1. 할인 여부를 판단하는데 사용하는 데이터를 변경한다면?
- 기존 : 'Cart 전체 금액 >= Promotion 기준 금액'
- 변경 : 'Promotion 최소 금액 >= Cart 전체 금액 <= Promotion 최대 금액'
절차지향 설계 데이터가 바뀌면 해당 데이터에 의존하는 모든 프로세스가 같이 바뀐다.
객체지향 설계는 데이터와 로직이 한 곳에 모아져 있기 때문에(캡슐화), 데이터가 변경될 때 하나의 요구사항만 바뀌면 된다. 즉, 결합도가 낮다.
CASE 2. 전체 금액 말고, ‘수량’ 이라는 새로운 타입이 할인 여부에 포함된다면?
- 기존 : 'Cart 전체 금액 >= Promotion 기준 금액'
- 변경 : 'Cart 전체 금액 >= Promotion 기준 금액' AND 'Cart 총 수량 >= Promotion 총 수량'
절차지향 설계는 기존 코드에 비즈니스 로직을 추가/수정하는 형태로 대응
객체지향 설계는 로직 자체를 분리해서, 기존 로직은 건드리지 않고 interface/implements 형태로 분리하여,이후 데이터 변경과 타입 확장 기능을 지원, 일관성 있는 설계로 발전할 수 있도록 강제됨
그러면 객체지향이 항상 더 좋은가?!
-> NO. 반드시 그렇진 않다. 다음 케이스를 보자
CASE 3. 장바구니 항목을 이용해서 할인 여부를 판단하는 기능 추가
- 기존 : 카트에 있는 모든 금액이나 수량의 합으로 할인을 적용
- 변경 : 장바구니 내에 있는 특정 항목의 존재 여부로 할인을 적용
절차지향 설계는 promotionProcess 의 메서드만 CASE 문 같은걸로 로직 수정하면 됨
객체지향 설계는 다형성을 사용하여 클래스의 계층 구조를 구현해놨을 때,
타입의 확장에는 굉장히 용이하지만, 타입에 새로운 operation 이 추가된다면 ( interface 레벨 ) 모든 구현 클래스에 전체적인 수정이 필요함
Type 은 고정이고 기능이 변경되는게 많을 때는 절차 지향 설계가 적절
기능은 고정이고 Type 이 추가되는 경우는 객체 지향 설계가 적절
데이터를 변환하는 CASE
지금까지 주제는 시스템 상태 변경.
만약 데이터 변환 도메인이라면?
CASE 4. Cart, Promotion 을 CarWithPromotion 으로 변경해야 하는 요구사항
절차지향 설계는 이미 데이터가 존재하고, promotionProcess 에서 result.setXX 으로 CarWithPromotion 으로 하나씩 넣어줘서 반환하면됨 (우리가 보통 하는 방식)
객체지향 설계는 각각의 데이터들이 개별적인 클래스로 분배가 되어있는 탓에
내가 다루고 있는 클래스가 어떤 타입인지 instanceof 으로 확인하고 typecasting 해서 끄집어 내줘야 함.
정리해보면
절차적인 설계는 포맷 변경을 위한 데이터 변환, 데이터 중심, 데이터 노출, 기능 추가에 유리(타입은 고정되고 기능 변경되는 경우)
객체지향 설계는 규칙에 기반한 상태 변경, 행동 중심, 데이터 캡슐화, 타입 확장(할인 조건이 다양해지는 경우)에 유리
내가 데이터를 다루는데(어떤 데이터를 가지고 있고 어떻게 가공할 것이다), 객체 지향적으로 다루면 어색하다.
따라서 절차지향은 데이터의 객체지향은 행위의 응집도로 묶이기 때문에 내가 다루는 도메인, 요구사항이 무엇에 가까운지 판단하자.
이걸 Layered Architecture 에 적용해본다면
- 프레젠테이션 레이어 ( 데이터의 변환, 데이터 중심이므로 절차 지향이 적절함 )
- 서비스 레이어 ( 애플리케이션 플로우 처리를 하기 때문에 절차 지향이 적절 )
- 도메인 레이어 ( 특별한 규칙을 기반으로 시스템의 상태를 변경할 목적. 따라서 객체 지향이 적절함 )
- 퍼시스턴스 레이어 ( DB 데이터의 객체 변환, 저장, 업데이트 등 데이터 중심이므로 절차 지향이 적절함 )
이미 특정한 목적에 맞게 절차/객체지향 적인 설계를 혼합해서 사용해야 함
극단적으로 도메인 관련 로직이 없는 경우에는 객체지향이 아예 필요 없을 수도 있음
결론
객체지향은 여전히 유용한가요?
-> 객체지향은 언제 유용한가요? 라는 질문이 더 적절하다.
그리고 유용하다. 모든 분야에 유용하지는 않지만 애초에 모든 기술이 적합한 컨텍스트에 맞게 사용해야 하기 때문에 하나의 기술과 패러다임으로 모든 곳에 적용할 순 없다.
어떤 설계와 어떤 기법도 모든 상황에 적용할 수 없다.
코드의 목적과 변경의 방향성에 따라 언제 어떤 기술을 사용할지 결정하자!
객체지향도 마찬가지이다.
강의 링크
https://www.inflearn.com/conf/infcon-2024/session-detail/881/
