- INFCON 2024 조영호 님 강의 요약
- 데이터와 프로세스(로직)을 별도의 클래스로 설계하는 방식
- omw: 절차적 설계 == 데이터 그 자체와 그 데이터를 get해서 처리하는 로직이 다른 클래스에 존재
- 데이터가 있는 클래스에 프로세스(로직)도 함께 존재
- omw: 객체지향 설계 == 데이터를 처리하는 로직이 데이터가 존재하는 클래스에 함께 존재하고, 다른 클래스가 get을 통해 데이터를 가져와서 처리하지 않고 데이터 처리 자체를 데이터+로직이 있는 클래스에 위임
- 데이터가 바뀔 때(할인 조건이 단순히 '최대금액보다 작다'에서 '최소금액과 최대금액의 사이'로 바뀔 때)는 절차적 설계보다는 객체지향 설계가 변경 범위가 더 적다
- omw: 객체지향 설계는 데이터 처리를 데이터+로직이 있는 클래스에 위임하므로 클라이언트 쪽에는 변경이 발생하지 않는다
- 새로운 조건이 추가될 때(할인 조건에 금액 뿐 아니라 기간이 추가될 때)
- 절차적 설계는 유연성이 좋아지지는 않지만 국소적(데이터가 있는 클래스 + 클라이언트 클래스) 변경 필요
- 객체지향 설계는 유연성이 좋아지지만 개념적, 구조적 변경(인터페이스 정의 + 구현체 분리)이 절차적 설계에 비해 크다고 느껴짐
- 하지만 객체지향 설계는 클라이언트 코드를 수정하지 않고 데이터 변경과 타입 확장 가능
- 요구사항 변경에 따라 코드의 사이즈는 커질지라도 일관된 구조(설계)를 유지할 수 있다는 점이 객체지향의 장점
- 객체지향은 타입 확장에는 유리하지만, 타입별 오퍼레이션이 추가되면 모든 타입에 오퍼레이션을 추가해야 한다
- 절차적 방식은 타입 확장에는 불리하지만, 타입별 오퍼레이션이 추가되더라도 변경량(범위가 아닌 절대량)은 적다
- omw
- 뭔가 유형화 할 수 있을 정도의 공통점이 있으면서 그 유형이 계속 늘어난다면 객체지향이 유리
- 유형화 할 수 있을 정도의 공통점도 없는데 기능만 계속 늘어난다면 절차적 방식이 유리
- 도메인 레이어
- 규칙 기반(omw: 유형화 가능)의 상태 변경 담당 => 객체지향 설계가 유리
- 프리젠테이션 레이어
- 대부분 외부에서 요구하는 (omw: 유형화 할 수 없을 정도로 불확실한) 데이터 변환 담당 => 절차적 설계가 유리
- 서비스 레이어
- 말그대로 애플리케이션 로직에 따른 절차(omw: 상태 변경은 도메인 레이어에 위임하고 상태 변경에 따라 수행해야 하는 절차) 서술 담당 => 절차적 설계가 유리
- 퍼시스턴스 레이어
- 데이터 저장소에서 데이터에 접근해서 CRUD 절차 서술 담당 => 절차적 설계가 유리
- 결국 유형화 된 상태 변경을 처리할 때(도메인 레이어)만 객체지향이 유리, 그 외는 절차적 설계가 유리
- 상태 변경 없이 조회만 한다면 객체지향이 끼어들 여지가 별로 없으며 절차적 설계가 유리
- omw
- 통계 batch는 대부분 데이터 변경 없이 데이터를 읽고 집계해서 결과를 만들고 저장하므로 일반적으로 절차적 설계가 유리
- 하지만 통계 batch도 유형화 가능한 부분이 있고 유형이 추가될 가능성이 높다면(ex: 일간 통계만 있었는데 주간 통계, 월간 통계, 연간 통계로 유형이 확장된다면) 객체지향 설계가 유리
- 통계 batch는 대부분 데이터 변경 없이 데이터를 읽고 집계해서 결과를 만들고 저장하므로 일반적으로 절차적 설계가 유리
- omw
- 객체지향은
여전히유효한가요? 보다는 객체지향은언제유용한가요? 가 더 나은 질문- 교조적으로 상황과 무관하게 A는 좋고 B는 안좋다 라는 접근보다는
- 일단 A, B 모두 알고나서 어떤 상황에서 어느 것이 유용한지 생각해보자