Code 46

[오브젝트] 4. 설계 품질과 트레이드오프

조영호 님의 "오브젝트" 책을 정리한 글입니다.1. 데이터 중심의 영화 예매 시스템데이터를 준비하자데이터 중심의 설계객체 내부에 저장되는 데이터를 기반으로 시스템을 분할하는 방법객체 내부에 저장해야 하는 "데이터가 무엇인가"를 묻는 것으로 시작됨 예제더보기public class Movie { private String title; private Duration runningTime; private Money fee; private List discountConditions; private MovieType movieType; private Money discountAmount; private double discountPercent; pub..

Code/OOP 2025.04.03

[오브젝트] 3. 역할, 책임, 협력

조영호 님의 "오브젝트" 책을 정리한 글입니다.1. 협력영화 예매 시스템 돌아보기기능을 완성하기 위해 다앙한 객체들이 메시지를 주고받으면서 상호작용함 협력애플리케이션이 기능을 구현하기 위해 객체 간의 상호작용을 수행하는 과정요소설명메시지 전송객체 간 협력을 위한 커뮤니케이션 수단메서드객체가 메시지를 수신하면 실행하여 요청에 응답캡슐화객체가 자율적으로 작업을 수행하기 위해 내부 구현을 숨김 객체의 역할개념설명책임객체가 협력에 참여하기 위해 수행하는 행동역할객체들이 협력 안에서 수행하는 책임들의 집합 협력이 설계를 위한 문맥을 결정한다객체의 상태와 행동을 어떤 기준으로 결정해야 하는가?요소설명행동객체가 참여하는 협력에 의해 결정됨 (객체가 필요한 이유와 행동의 동기를 제공)상태객체의 행동 수행에 필요한 정보..

Code/OOP 2025.04.03

[오브젝트] 2. 객체지향 프로그래밍

조영호 님의 "오브젝트" 책을 정리한 글입니다.1. 영화 예매 시스템요구사항 살펴보기사용자에게 예매 서비스 제공할인 조건을 만족할 경우 할인 정책에 따른 금액을 할인받을 수 있음예매 완료 시, 예매 정보 생성 정보구분설명영화 정보영화의 기본 정보상영 정보요일, 시작 시간, 종료 시간예매 정보제목, 상영 정보, 인원, 정가, 결제 금액 할인 적용 방식구분설명할인 조건 (영화별로 여러 개 적용 가능) 🔹 순서 조건특정 상영 순번에 따라 할인 적용🔹 기간 조건특정 상영 시간에 따라 할인 적용할인 정책 (영화별로 1개만 적용 가능) 🔹 금액 할인 정책일정 금액 할인🔹 비율 할인 정책정가에서 일정 비율 할인  2. 객체지향 프로그래밍을 향해협력, 객체, 클래스객체지향 패러다임으로의 전환은 클래스가 아닌 객..

Code/OOP 2025.04.02

[객체지향의 사실과 오해] 2. 이상한 나라의 객체

조영호 님의 "객체지향의 사실과 오해" 책을 정리한 글입니다. 1. 객체지향과 인지 능력객체특성설명형태물리적 또는 개념적인 것인지 가능추상적인 사물을 포함하여 인식할 수 있음구별 가능식별 가능한 경계를 가짐크기작게 분해됨 (복잡성을 극복하기 위함) 객체지향현실 세계를 기반으로 새로운 세계를 창조하는 것 예시세계전등의 동작 방식현실 세계사람의 손길 없이는 전원을 켜거나 끌 수 없음소프트웨어 세계전등이 스스로 전원을 켜거나 끌 수 있음 2. 객체, 그리고 이상한 나라앨리스 객체개념설명행동이 상태를 결정행동의 결과에 따라 객체의 상태가 변화함ex) 앨리스의 키는 행동을 통해 변화됨상태 의존성행동의 성공 여부는 이전 상태에 따라 달라짐즉, 행동의 순서가 중요함 3. 객체, 그리고 소프트웨어 나라상태행동의 과정과..

Code/OOP 2025.04.02

[객체지향의 사실과 오해] 1. 협력하는 객체들의 공동체

조영호 님의 "객체지향의 사실과 오해" 책을 정리한 글입니다. 1. 객체현실 세계의 사물을 추상화한 개념상태(State)와 행동(Behavior)을 함께 지닌 자율적인 실체 2. 객체지향현실 세계를 직관적으로 모델링할 수 있는 패러다임 목표요구사항을 만족하는 시스템을 구현하는 것문제 해결을 위한 효과적인 구조를 설계하는 것 (단순히 현실 세계를 모방하는 것이 목표가 아님) 핵심 개념개념정의 및 설명주요 특징협력복잡한 문제를 해결하기 위해 객체들이 서로 요청-응답하는 과정- 객체 간 메시지 교환이 핵심 - 협력의 성공 여부는 객체의 응답 품질에 달려 있음역할협력 속에서 각 객체가 맡은 책임- 다형성 지원: 동일한 역할을 여러 객체가 수행 가능 - 대체 가능성: 요청자는 역할을 수행하는 특정 객체에 관심 없..

Code/OOP 2025.04.02

[오브젝트] 1. 객체, 설계

조영호 님의 "오브젝트" 책을 정리한 글입니다. 1. 티켓 판매 애플리케이션 구현하기관람객구분입장 조건필요한 절차이벤트 당첨자초대장을 티켓으로 교환한 후 입장초대장 → 티켓 교환 → 입장이벤트 미당첨자티켓을 구매한 후 입장티켓 구매 → 입장 극장관람객 입장 담당 (이벤트 당첨자/미당첨자에 따른 입장) 더보기코드public class Invitation { private LocalDateTime when;}public class Ticket { private Long fee; public Long getFee() { return fee; }}public class Bag { // 관람객의 가방 (초대장, 현금, 티켓) private Long amount; private I..

Code/OOP 2025.04.02

[단위 테스트] 8-2. 통합 테스트를 하는 이유: 인터페이스

블라디미르 코리코프 님의 "단위 테스트" 책을 정리한 포스팅입니다. 4. 의존성 추상화를 위한 인터페이스 사용인터페이스와 느슨한 결합인터페이스 사용의 잘못된 인식프로세스 외부 의존성을 추상화하는 목적은 느슨한 결합을 달성하기 위함단일 구현일 경우, 추상화가 아니게 됨진정한 추상화는 발견하는 것이지 발명하는 것이 아님 (적어도 구현이 두가지 이상 있어야 함)YAGNI 위반 프로세스 외부 의존성에 인터페이스를 사용하는 이유는?목을 사용하기 위함인터페이스가 없으면 테스트 대역을 만들 수 없음즉, 비관리 의존성만 인터페이스를 두기 5. 통합 테스트 모범 사례항목장점권장 사항도메인 모델 경계 명시단위 테스트와 통합 테스트 구분 쉬움 계층 수 줄이기단순화, 탐색 쉬움도메인 모델, 애플리케이션 서비스, 인프라 계층만..

Code/Test 2025.03.01

[단위 테스트] 5-2. 목과 테스트 취약성: 통신

블라디미르 코리코프 님의 "단위 테스트" 책을 정리한 포스팅입니다.3. 목과 테스트 취약성 간의 관계육각형 아키텍처도메인을 중심으로, 포트(Port)와 어댑터(Adapter)를 통해 외부와의 상호작용을 처리하는 구조구성 요소설명Domain핵심 비즈니스 로직. 의존성 없음 (순수 계층)Port (Interface)외부와 상호작용하기 위한 입출력 인터페이스Adapter외부 시스템 구현체 (DB, Email, API 등)Application Service도메인 호출 + 외부 시스템과의 조율 담당 예제) Order더보기도메인public class Order { private String orderId; private String customerId; private List items; pr..

Code/Test 2025.01.24

[단위 테스트] 5-1. 목과 테스트 취약성: 목

블라디미르 코리코프 님의 "단위 테스트" 책을 정리한 포스팅입니다. 1. Mock vs Stub테스트 대상 시스템과 그 협력자 사이의 상호 작용을 검사할 수 있는 테스트 대역구분Mock (목)Stub (스텁)역할외부와의 상호 작용을 모방하고 검증내부로 들어오는 입력/행위를 모방목적협력 객체가 정확히 호출되었는지협력 객체에서 예상 데이터 제공방향Out-boundIn-bound검증 여부✅ 상호작용 검증 (호출 횟수, 순서, 인자 등)❌ 결과 검증만적합한 상황부작용 발생 확인 (Command)데이터 주입 (Query)주의사항과도하면 구현에 종속됨상호작용 검증은 하지 말 것테스트 위험과잉 명세구현 세부사항 노출예시이메일 전송 여부, 결제 API 호출 여부 등DB에서 회원 조회 결과 반환, 외부 API에서 응답 ..

Code/Test 2025.01.24

[단위 테스트] 4-2. 좋은 단위 테스트의 4대 요소: 이상적인 테스트

블라디미르 코리코프 님의 "단위 테스트" 책을 정리한 포스팅입니다.3. 이상적인 테스트를 찾아서테스트의 가치좋은 단위 테스트의 4대 특성을 곱하여 얻은 결과 (추정치)소수의 가치있는 테스트가 평범한 테스트보다 프로젝트 성장에 훨씬 더 효과적테스트 스위트에 테스트를 계속 둘지 여부를 결정할 수 있음임계치를 충족하는 테스트만 두어, 책임을 적절하게 맡도록 해야 함 이상적인 테스트를 만들 수 있는가?이상적인 테스트는 네 가지 특성 모두에서 최대 점수를 받는 테스트실제로는 세 가지 특성(회귀 방지, 리팩터링 내성, 빠른 피드백)이 서로 충돌함 모두를 동시에 만족하는 것은 불가능함 핵심 전략항목설명하나의 특성을 완전히 버릴 수 없다하나를 버리면 곱셈 규칙(가치의 곱)에 의해 전체 테스트의 유용성이 0에 가까워짐리..

Code/Test 2025.01.24