장바구니 담기 close

장바구니에 상품을 담았습니다.

객체지향 시스템 디자인 원칙

객체지향 시스템 디자인 원칙

  • 마우리시오 아니체
  • |
  • 길벗
  • |
  • 2025-06-25 출간
  • |
  • 192페이지
  • |
  • 183 X 235 X 10mm
  • |
  • ISBN 9791140713813
판매가

24,000원

즉시할인가

21,600

배송비

무료배송

(제주/도서산간 배송 추가비용:3,000원)

수량
+ -
총주문금액
21,600

※ 스프링제본 상품은 반품/교환/환불이 불가능하므로 신중하게 선택하여 주시기 바랍니다.

출판사서평

객체지향 시스템, 제대로 디자인하라!
6가지 원칙 & 실용적인 접근 방식을 배우자!

객체지향 디자인, 단순하게 유지하자!
개발자의 작업 대부분은 기존 시스템을 유지하고 발전시키는 것이다. 유지보수성이 높은 소프트웨어 시스템을 구축하려면 좋은 객체지향 디자인이 필요하며, 좋은 객체지향 디자인의 핵심 요소는 단순함이다. 처음에 시스템을 잘 디자인했다 하더라도 수정할 때마다 복잡성이 증가한다. 새로운 클래스, 메서드, 기능이 추가될 때마다 관리해야 할 상태와 추상화가 늘어난다. 자연스러운 복잡성 증가에 맞서 디자인을 단순하게 유지하는 건 어려운 일이지만, 복잡성 관리는 소프트웨어 시스템을 효과적으로 유지하고 발전시키는 데 필수적인 과정이다. 복잡성을 제어하고, 객체지향 디자인을 단순하게 유지할 수 있도록 도와주는 6가지 디자인 원칙에 대해 알아보자.

명확하고 실용적인 6가지 원칙을 깊이 탐구하자!
객체지향 코드베이스가 성장하고 변화하더라도 단순하게 유지할 수 있는 실용적인 설계 원칙이자, 모든 객체지향 언어에 적용할 수 있는 실용적인 기법을 모았다. 그 원칙을 다음 6가지 측면으로 나눠 하나씩 깊이 탐구할 것이다. 각 원리를 더욱 깊이 있게 이해할 수 있도록 쉬운 그림, 실제와 같은 시스템 예제, 생각해볼 수 있는 연습 문제를 준비했다.
• 코드를 작게 유지하는 방법
• 객체의 일관성을 유지하는 방법
• 의존성을 적절하게 관리하는 방법
• 추상화를 이해하고 잘 디자인하는 방법
• 인프라를 올바르게 처리하고 다루는 방법
• 잘 모듈화된 디자인을 달성하는 방법

실무적인 관점으로 백엔드 시스템 예제를 살펴보자!
각 원칙의 개념을 먼저 설명한 뒤 이 원칙을 어떻게 적용하는지 코드 예제를 통해 실무적인 관점에서 설명한다. 디자인 패턴을 설명하기 위해 이 책 전반에 걸쳐 피플그로우!라는 가상의 백엔드 시스템 예제를 사용할 것이다. 피플그로우!를 구축하는 팀은 현재 유지보수 문제에 직면해 있다. 버그가 발생하고, 간단한 변경이 시스템의 예기치 않은 영역에 영향을 미쳐 변경 사항을 완료하는 데 며칠씩 걸린다. 피플그로우!의 디자인 결정을 자세히 알아보고 이를 개선하면서 각 원칙의 맥락, 장단점, 원칙을 적용해야 할 때와 말아야 할 때도 함께 알아볼 것이다.

[베타테스터 후기]
객체지향 디자인이 왜 좋은가에 대한 이야기라기보다는 소프트웨어 개발 전반에 걸쳐 코드를 어떻게 작성하고 모듈을 어떻게 구현하는 것이 좋은가에 대해 다루고 있습니다. 중요한 내용을 간결하게 정리한 책입니다.
- 윤병조_소프트웨어 개발자_서버 개발자

서비스의 구조가 점점 복잡해지면서 어떤 점에 초점을 맞추어 모델링을 할지에 대해 다룹니다. 또한, 예시 코드로 설명하는 서비스 개발을 통해 객체지향에서 다루는 원칙의 각 이론을 쉽게 이해할 수 있습니다.
- 최인주_에스에스지닷컴_백엔드 개발자

저자의 경험에 바탕을 두고, 평소 현실에서 일반적으로 경험할 수 있는 케이스에 대해서 객체지향적으로 문제를 해결하는 방식이 이 책의 가장 큰 장점입니다. 책의 내용도 매우 쉽게 번역되었고, 객체지향적으로 좋은 코드를 어떻게 하면 개선해나갈 수 있는지 잘 설명되어 있습니다. 기존에 만들어진, 또는 잘 만들어진 코드를 지속적으로 잘 유지해나가야 하는지에 대해 충분히 고찰합니다. 코드를 분리할 때의 기준, 지속적으로 유지보수가 힘든 이유 등 좋은 디자인을 유지하기 위해서 무엇을 해야 하고, 원칙을 세워야 하는지 알게 해주는 책입니다.
- 박찬웅_롯데렌탈_개발팀

객체지향 디자인의 본질을 쉽고 깊이 있게 풀어낸 책입니다. 객체지향 개념을 처음 접하는 사람부터 실무 경험이 있는 개발자까지 모두에게 새로운 시각을 제공한다는 점에서 인상적이었습니다.
- 이기하_OPDC(Open Platform Developer Community)_클라우드 엔지니어

객체지향 디자인의 원칙을 통해 복잡성을 효과적으로 관리하고 억제하는 실용적인 첫걸음을 제시합니다. 개발자라면 반드시 읽어야 할, 명쾌하고 통찰력 있는 객체지향 입문서입니다.
- 서영원_컬리_소프트웨어 엔지니어

객체지향 디자인의 본질을 다시 생각하게 해주는 책입니다. 특히 원칙을 단순히 나열하는 데 그치지 않고, 원칙 간의 관계와 트레이드오프 상황에서의 균형점을 고민하게 만드는 부분이 개인적으로 인상적이었습니다. 객체지향 디자인에 대한 초심자부터, 어느 정도 경험을 쌓은 개발자, 시스템 아키텍처를 고민하는 리더까지 모두에게 유익한 책입니다.
- 최성욱_삼성전자 VD사업부 Security Lab_클라우드 보안 엔지니어

이미 개발 방법론에 대해 깊이 고민해본 경험이 있는 개발자라면, 이 책은 더욱 강력한 도구가 되어줄 것입니다. 이론과 실무를 넘나드는 탁월한 안내서로서, 자신만의 개발 철학을 정립하는 데 큰 도움이 될 것입니다.
- 박명철_오토플러스_20년차 자바 개발자

목차

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 요약

찾아보기

도서소개


 

교환 및 환불안내

도서교환 및 환불
  • ㆍ배송기간은 평일 기준 1~3일 정도 소요됩니다.(스프링 분철은 1일 정도 시간이 더 소요됩니다.)
  • ㆍ상품불량 및 오배송등의 이유로 반품하실 경우, 반품배송비는 무료입니다.
  • ㆍ고객님의 변심에 의한 반품,환불,교환시 택배비는 본인 부담입니다.
  • ㆍ상담원과의 상담없이 교환 및 반품으로 반송된 물품은 책임지지 않습니다.
  • ㆍ이미 발송된 상품의 취소 및 반품, 교환요청시 배송비가 발생할 수 있습니다.
  • ㆍ반품신청시 반송된 상품의 수령후 환불처리됩니다.(카드사 사정에 따라 카드취소는 시일이 3~5일이 소요될 수 있습니다.)
  • ㆍ주문하신 상품의 반품,교환은 상품수령일로 부터 7일이내에 신청하실 수 있습니다.
  • ㆍ상품이 훼손된 경우 반품 및 교환,환불이 불가능합니다.
  • ㆍ반품/교환시 고객님 귀책사유로 인해 수거가 지연될 경우에는 반품이 제한될 수 있습니다.
  • ㆍ스프링제본 상품은 교환 및 환불이 불가능 합니다.
  • ㆍ군부대(사서함) 및 해외배송은 불가능합니다.
  • ㆍ오후 3시 이후 상담원과 통화되지 않은 취소건에 대해서는 고객 반품비용이 발생할 수 있습니다.
반품안내
  • 마이페이지 > 나의상담 > 1 : 1 문의하기 게시판 또는 고객센터 1800-7327
교환/반품주소
  • 경기도 파주시 문발로 211 1층 / (주)북채널 / 전화 : 1800-7327
  • 택배안내 : CJ대한통운(1588-1255)
  • 고객님 변심으로 인한 교환 또는 반품시 왕복 배송비 5,000원을 부담하셔야 하며, 제품 불량 또는 오 배송시에는 전액을 당사에서부담 합니다.