[epub3.0] 객체지향 시스템 디자인 원칙

마우리시오 아니체 저자, 오현석 번역 지음

길벗 2025년 07월 07일 출간 국내도서 : 2025년 06월 25일 출간

작품소개

책소개

객체지향은 복잡성을 합리적으로 다루기 위해 고안된 수단이다. 객체지향 시스템을 제대로 디자인하려면 수많은 경험과 훈련이 필요하고, 이를 다룬 두꺼운 책이 엄청나게 많다. 하지만 결국 객체지향 디자인은 객체들을 통해 작동하는 시스템에 질문하는 것이다. 복잡도를 낮추고, 코드 단위를 작게 유지하고, 객체 상태의 일관성을 유지하고, 의존성을 적절히 제어하며, 적절한 추상화를 통해 개발자의 인지 부하를 줄이는 동시에 시스템의 확장성을 높이고, 모듈화로 응집도는 높이고 결합도는 낮추는 방법에 대해 질문해야 한다. 이 질문들의 의미를 알고, 객체 시스템에 적용하는 방법을 알기 위해서는 복잡한 이론보다 간단한 예제를 통해 실질적인 코드를 보면서 이해를 늘려 나가는 것이 좋다고 생각한다. 이 책이 바로 그런 책이다. 좋은 객체지향 디자인을 위한 여러 조언을 제시하면서 각 개념을 쉽게 이해할 수 있는 코드 예제를 보여주고, 객체지향 시스템을 개발하는 과정에서 해야 할 일과 하지 말아야 할 일을 알려준다. 객체지향 디자인을 배우고 싶은 개발자는 예제를 통해 개념을 쉽게 잡아낼 수 있고, 이미 객체지향 디자인에 대해 잘 아는 개발자는 이 책의 조언들을 자신의 경험과 비교하면서 객체지향 디자인 개념을 더 잘 이해할 수 있을 것이다. (옮긴이의 말 중에서)

목차

1장 모든 게 복잡도 관리다
1.1 객체지향 디자인과 시간이 주는 시련
1.2 단순한 객체지향 시스템 디자인
__1.2.1 단순한 코드
__1.2.2 일관성 있는 객체
__1.2.3 적절한 의존성 관리
__1.2.4 좋은 추상화
__1.2.5 외부 의존성과 인프라 적절히 다루기
__1.2.6 좋은 모듈화
1.3 일상적인 활동으로서의 단순한 디자인
__1.3.1 복잡성 줄이기는 개인 위생과 비슷하다
__1.3.2 복잡성이 필요할 수도 있지만 영구적이어서는 안 된다
__1.3.3 지속적으로 복잡성을 해결하는 것이 비용 효율적이다
__1.3.4 고품질 코드는 좋은 실무 프랙티스를 촉진한다
__1.3.5 복잡성을 통제하는 것은 생각보다 어렵지 않다
__1.3.6 디자인을 단순하게 유지하는 것은 개발자의 책임이다
__1.3.7 이 정도면 충분히 좋은 디자인이다
1.4 정보 시스템의 아키텍처에 대해 간략히 살펴보기
1.5 예제: 피플그로우!
1.6 연습문제
1.7 요약

2장 코드를 작게 유지하기
2.1 코드 단위를 작게 만들라
__2.1.1 복잡한 메서드를 비공개 메서드로 나눠라
__2.1.2 복잡한 코드 단위를 다른 클래스로 옮겨라
__2.1.3 코드를 작은 단위로 나누지 말아야 할 때
__2.1.4 리팩터링하기 전에 전체적으로 살펴보라
__2.1.5 예제: 직원 데이터 임포트하기
2.2 코드를 읽기 쉽게 만들고 문서화하라
__2.2.1 좋은 이름을 계속 찾아라
__2.2.2 의사결정을 문서화하라
__2.2.3 코드에 주석을 추가하라
__2.2.4 예제: 오퍼링 내용 변경 안내 이메일을 언제 발송할지 결정하기
2.3 새로운 복잡성을 기존 클래스에서 분리하라
__2.3.1 복잡한 비즈니스 로직을 자체 클래스로 분리하라
__2.3.2 큰 비즈니스 흐름을 분해하라
__2.3.3 예제: 오퍼링에 대한 대기자 명단
2.4 연습문제
2.5 요약

3장 객체의 일관성 유지하기
3.1 항상 일관성을 유지하라
__3.1.1 클래스가 스스로 일관성을 책임지게 하라
__3.1.2 전체 작업과 복잡한 일관성 검사를 캡슐화하라
__3.1.3 예제: Employee 엔터티
3.2 효과적인 데이터 유효성 검사 메커니즘을 디자인하라
__3.2.1 사전 조건을 명시적으로 정의하라
__3.2.2 유효성 검증 컴포넌트를 만들라
__3.2.3 %00;은 신중하게 사용하고, 피할 수 있다면 피하라
__3.2.4 예제: 교육 과정에 직원 추가하기
3.3 상태 확인을 캡슐화하라
__3.3.1 명령하라, 질문하지 마라
__3.3.2 예제: 오퍼링의 빈 자리 확인
3.4 필요한 게터와 세터만 제공하라
__3.4.1 상태를 변경하지 않고 클라이언트에 너무 많은 정보를 노출하지 않는 게터
__3.4.2 세터는 객체를 설명하는 속성에만 사용한다
__3.4.3 예제: Offering 클래스의 게터와 세터
3.5 객체 집단의 불변 조건을 보장하도록 애그리게이트를 모델링하라
__3.5.1 애그리게이트 루트의 규칙을 깨지 마라
__3.5.2 예제: Offering 애그리게이트
3.6 연습문제
3.7 요약

4장 의존성 관리하기
4.1 고수준 코드와 저수준 코드를 분리하라
__4.1.1 안정적인 코드를 디자인하라
__4.1.2 인터페이스 발견 098
__4.1.3 고수준 코드와 저수준 코드를 분리하지 않아도 되는 경우
__4.1.4 예제: 메시지 처리 작업
4.2 불필요한 세부 사항이나 요소에 의존하는 것을 피하라
__4.2.1 여러분이 소유한 클래스만 요구하거나 반환하라
__4.2.2 예제: HTTP 봇을 채팅 SDK로 대체하기
__4.2.3 클라이언트에게 필요한 것 이상을 제공하지 마라
__4.2.4 예제: 오퍼링 목록
4.3 너무 많은 클래스에 의존하는 클래스를 분리하라
__4.3.1 예제: MessageSender 서비스 분리하기
4.4 의존성을 주입하라(의존성 주입을 사용하라)
__4.4.1 상태를 변경하는 작업에 정적 메서드를 사용하지 마라
__4.4.2 항상 협력자를 주입하라: 그 외에는 원하는 대로 하라
__4.4.3 클래스와 의존성을 함께 생성하는 전략
__4.4.4 예제: MessageSender와 협력자들의 의존성 주입
4.5 연습문제
4.6 요약

5장 추상화 잘 디자인하기
5.1 추상화와 확장 지점을 디자인하라
__5.1.1 추상화의 필요성 식별하기
__5.1.2 확장 지점 디자인하기
__5.1.3 좋은 추상화의 속성
__5.1.4 추상화에서 배워라
__5.1.5 추상화에 대해 배워라
__5.1.6 추상화와 결합
__5.1.7 예제: 직원에게 배지 수여하기
5.2 중요한 비즈니스 규칙을 일반화하라
__5.2.1 일반화된 비즈니스 규칙과 구체적인 데이터를 분리하라
__5.2.2 예제: 배지 규칙 일반화하기
5.3 단순한 추상화를 선호하라
__5.3.1 경험적 규칙
__5.3.2 단순한 것이 항상 더 낫다
__5.3.3 이쯤 되면 추상화를 고려해야 한다
__5.3.4 처음부터 추상화를 모델링하는 것을 두려워하지 마라
__5.3.5 예제: 배지 예제 다시 보기
5.4 연습문제
5.5 요약

6장 외부 의존성과 인프라 다루기
6.1 도메인 코드와 인프라를 분리하라
__6.1.1 인터페이스가 필요한가?
__6.1.2 코드에서는 세부 사항을 숨기고, 개발자에게는 숨기지 마라
__6.1.3 인프라 변경하기: 괜한 걱정일까, 실제로 일어날까?
__6.1.4 예제: 데이터베이스 접근과 메시지 봇
6.2 인프라를 최대한 활용하라
__6.2.1 디자인을 망가뜨리지 않도록 최선을 다하라
__6.2.2 예제: 등록 취소하기
6.3 자신이 소유한 것에만 의존하라
__6.3.1 프레임워크와 싸우지 마라
__6.3.2 간접 누출에 주의하라
__6.3.3 예제: 메시지 봇
6.4 저수준 인프라 오류를 고수준 도메인 오류로 캡슐화하라
__6.4.1 예제: SDKBot의 예외 처리
6.5 연습문제
6.6 요약

7장 모듈화 달성하기
7.1 깊이 있는 모듈을 구축하라
__7.1.1 변경의 영향을 줄이는 방법을 찾아라
__7.1.2 도메인 경계를 지속적으로 다듬어라
__7.1.3 관련된 항목을 가까이 유지하라
__7.1.4 우발적인 결합을 피하되, 불가피하다면 문서로 남겨라
7.2 인터페이스를 명확히 디자인하라
__7.2.1 모듈의 인터페이스를 단순하게 유지하라
__7.2.2 하위 호환성을 갖춘 모듈
__7.2.3 깔끔한 확장 지점을 제공하라
__7.2.4 다른 요구 사항을 가진 사람들이 모듈을 사용하는 것처럼 코딩하라
__7.2.5 모듈은 명확한 소유권과 참여 규칙이 있어야 한다
7.3 모듈 간의 친밀성을 피하라
__7.3.1 모듈과 클라이언트가 친밀성을 없애는 것을 책임지게 하라
__7.3.2 내부 클래스에 의존하지 마라
__7.3.3 의존성의 거미줄을 모니터링하라
__7.3.4 모놀리스인가, 마이크로서비스인가?
__7.3.5 모듈을 분리하는 방법으로 이벤트를 고려하라
__7.3.6 예제: 알림 시스템
7.4 연습문제
7.5 요약

8장 실용적인 접근법
8.1 실용적으로 접근하되, 딱 필요한 만큼만
8.2 과감하게 리팩터링하되, 단 작은 단위로 나눠서
8.3 코드가 완벽하지 않다는 사실을 받아들여라
8.4 재디자인을 고려하라
8.5 여러분은 주니어 개발자들에 대한 책임이 있다
8.6 참고 문헌
8.7 연습문제
8.8 요약

찾아보기

작가정보

저자(글) 마우리시오 아니체 저자, 오현석 번역

현재 아디옌(Adyen, 네덜란드 기술 기업)에서 테크 리드로 근무하며, 아디옌의 테크 아카데미를 포함해 엔지니어를 위한 추가 교육과 훈련에 중점을 둔 엔지니어링 지원 이니셔티브 팀을 이끌고 있다. 또한 네덜란드 델프트 공과대학교(Delft University of Technology)에서 소프트웨어 공학 조교수로 재직 중이다. 소프트웨어 테스트 교육에 대한 노력으로 2021년 올해의 컴퓨터 과학 교사 상을 받았고, 혁신적인 강사에게 수여되는 명예로운 TU 델프트 교육 펠로우십(Delft Education Fellowship)을 받았다. 2022년에는 『Effective Software Testing: A Developer's Guide』(Manning)를 출간했다. 소프트웨어 엔지니어들이 더 나은, 더 생산적인 엔지니어가 될 수 있도록 돕는 것을 목표로 하고 있다./모빌리티42 이사로 일하면서 매일 고객의 요청에 따라 코드를 만드는 현업 개발자다. 『코틀린 함수형 프로그래밍』(에이콘, 2023) 등 코틀린 서적을 여러 권 번역했고, 코틀린 외에도 『실전 파이썬 핸즈온 프로젝트』(책만, 2022), 『읽고 나면 진짜 쉬워지는 자료 구조』(길벗, 2024) 등 다양한 프로그래밍 언어와 프로그래밍 기술에 대한 책을 번역했으며, 『핵심 코틀린 프로그래밍』(에이콘, 2023) 책을 쓴 저자이기도 하다.