상세정보
미리보기
C++ 소프트웨어 디자인
- 저자
- 클라우스 이글베르거 저/이상주 역
- 출판사
- 위키북스
- 출판일
- 2024-07-31
- 등록일
- 2024-09-12
- 파일포맷
- PDF
- 파일크기
- 7MB
- 공급사
- YES24
- 지원기기
-
PC
PHONE
TABLET
웹뷰어
프로그램 수동설치
뷰어프로그램 설치 안내
책소개
좋은 소프트웨어 디자인은 프로젝트 성공에 필수지만, 소프트웨어를 디자인하기는 어렵다. 디자인 결정의 결과를 깊게 이해하고 사용 가능한 디자인 대안에 대해 잘 알고 있어야 한다. 이 책을 통해 숙련된 C++ 개발자는 최신 언어를 사용한 소프트웨어 디자인에 대해 철저하고 실용적이며 비교할 바 없는 훌륭한 개요을 얻게 될 것이다.C++ 강사이자 컨설턴트인 클라우스 이글베르거는 의존성과 추상화를 관리하고, 소프트웨어 개체의 변경 용이성과 기능 확장성을 향상시키며, 최신 기술과 흐름을 활용하기 위해 최신 디자인 패턴을 적용하고 구현하는 방법을 설명한다. 소프트웨어 디자인은 소프트웨어의 가장 중요한 특성인 유지 보수성, 변경 용이성, 기능 확장성에 영향을 미치므로 소프트웨어 프로젝트의 가장 중요한 측면이다.
저자소개
프리랜서 C++ 강사이자 컨설턴트다. 전 세계적으로 인기 있는 교육 과정을 통해 15년간 C++ 전문 지식을 공유하고 있으며 C++ 콘퍼런스에서 자주 발표하고 있다. 2010년 박사 학위를 취득한 이후 대규모 소프트웨어 디자인과 소프트웨어 유지 보수성 향상에 집중하고 있다.
목차
01장: 소프트웨어 디자인 기술 지침 1: 소프트웨어 디자인의 중요성을 이해하라 __기능은 소프트웨어 디자인이 아니다 __소프트웨어 디자인: 의존성과 추상화 관리 기술 __소프트웨어 개발의 세 가지 수준 __기능에 집중하기 __소프트웨어 디자인과 디자인 원칙에 집중하기 지침 2: 변경을 위한 디자인 __관심사 분리(separation of concerns) __인위적인 결합 예 __논리적 결합 대 물리적 결합 __반복하지 말 것 __너무 이른 관심사 분리를 피한다 지침 3: 인터페이스를 분리해 인위적인 결합을 피하라 __인터페이스를 분리해 관심사 분리하기 __템플릿 인자의 요구 사항 최소화하기 지침 4: 테스트 용이성을 위한 디자인 __비공개 멤버 함수 테스트 방법 __진정한 해결책: 관심사 분리 지침 5: 확장을 위한 디자인 __개방-폐쇄 원칙 __컴파일 시점의 기능 확장성 __너무 이른 기능 확장을 위한 디자인을 피한다 02장: 추상화 구축 기술 지침 6: 추상화로 기대하는 행위를 따르라 __기대를 어기는 예 __리스코프 치환 원칙 __리스코프 치환 원칙에 대한 비판 __좋고 의미 있는 추상화의 필요성 지침 7: 기초 클래스와 콘셉트 간 유사성을 이해하라 지침 8: 다중 정의 집합의 의미론적 요구 사항을 이해하라 __자유 함수의 힘: 컴파일 시점 추상화 메커니즘 __자유 함수의 문제: 행위에 대한 기대 지침 9: 추상화 소유권에 주의하라 __의존성 역전 원칙 __플러그인 아키텍처에서 의존성 역전 __템플릿을 통한 의존성 역전 __다중 정의 집합을 통한 의존성 역전 __의존성 역전 원칙 대 단일 책임 원칙 지침 10: 아키텍처 문서 작성을 고려하라 03장: 디자인 패턴의 목적 지침 11: 디자인 패턴의 목적을 이해하라 __디자인 패턴은 이름이 있다 __디자인 패턴은 의도를 전달한다 __디자인 패턴은 추상화를 도입한다 __디자인 패턴은 입증됐다 지침 12: 디자인 패턴에 대한 오해를 주의하라 __디자인 패턴은 목표가 아니다 __디자인 패턴은 구현 상세에 관한 것이 아니다 __디자인 패턴은 객체 지향 프로그래밍이나 동적 다형성에 국한하지 않는다 지침 13: 디자인 패턴은 어디에나 있다 지침 14: 디자인 패턴 이름을 사용해 의도를 전달하라 04장: 비지터 디자인 패턴 지침 15: 타입 또는 연산 추가를 위한 디자인 __절차적 해결책 __객체 지향 해결책 __동적 다형성에서 디자인 선택을 인식한다 지침 16: 비지터를 사용해 연산을 확장하라 __디자인 문제 분석 __비지터 디자인 패턴 해설 __비지터 디자인 패턴 단점 분석 지침 17: 비지터를 구현하는 데 std::variant를 고려하라 __std::variant 소개 __도형 그리기를 값 기반, 비간섭 해결책으로 리팩터링하기 __성능 벤치마크 __std::variant 해결책의 단점 분석 지침 18: 비순환 비지터의 성능에 주의하라 05장: 전략 디자인 패턴과 커맨드 디자인 패턴 지침 19: 전략을 사용해 작업 수행 방법을 분리하라 __디자인 문제 분석 __전략 디자인 패턴 해설 __순진한 해결책의 단점 분석 __비지터와 전략 비교 __전략 디자인 패턴 단점 분석 __단위 전략 기반 디자인 지침 20: 상속보다 구성을 선호하라 지침 21: 커맨드를 사용해 수행할 작업을 분리하라 __커맨드 디자인 패턴 해설 __커맨드 디자인 패턴 대 전략 디자인 패턴 __커맨드 디자인 패턴 단점 분석 지침 22: 참조 의미론보다 값 의미론을 선호하라 __GoF 형식의 단점: 참조 의미론 __참조 의미론: 두 번째 예 __모던 C++ 철학: 값 의미론 __값 의미론: 두 번째 예 __디자인 패턴을 구현하는 데 값 의미론 사용을 선호하라 지침 23: 전략과 커맨드는 값 기반 구현을 선호하라 __std::function 소개 __도형 그리기 리팩터링 __성능 벤치마크 __std::function 해결책 단점 분석 06장: 어댑터 디자인 패턴, 옵서버 디자인 패턴, CRTP 디자인 패턴 지침 24: 어댑터를 사용해 인터페이스를 표준화하라 __어댑터 디자인 패턴 해설 __객체 어댑터 대 클래스 어댑터 __표준 라이브러리의 예 __어댑터와 전략 비교 __함수 어댑터 __어댑터 디자인 패턴의 단점 분석 지침 25: 추상 통지 메커니즘으로 옵서버를 적용하라 __옵서버 디자인 패턴 해설 __전통적인 옵서버 구현 __값 의미론을 기반으로 한 옵서버 구현 __옵서버 디자인 패턴의 단점 분석 지침 26: CRTP를 사용해 정적 타입 범주를 도입하라 __CRTP에 대한 동기 __CRTP 디자인 패턴 해설 __CRTP 디자인 패턴 단점 분석 __CRTP의 미래: CRTP와 C++20 콘셉트 간 차이 지침 27: 정적 믹스인 클래스에 CRTP를 사용하라 __강타입(Strong type)의 동기 __구현 패턴으로 CRTP 사용 07장: 브리지 디자인 패턴, 프로토타입 디자인 패턴, 외부 다형성 디자인 패턴 지침 28: 브리지를 구축해 물리적 의존성을 제거하라 __동기 부여 사례 __브리지 디자인 패턴 해설 __핌플 관용구 __브리지와 전략의 비교 __브리지 디자인 패턴 단점 분석 지침 29: 브리지 성능 이득과 손실을 인식하라 __브리지 성능 영향 __부분 브리지로 성능 향상시키기 지침 30: 추상 복사 연산에는 프로토타입을 적용하라 __양을 이용한 예: 동물 복사 __프로토타입 디자인 패턴 해설 __프로토타입과 std::variant 비교 __프로토타입 디자인 패턴 단점 분석 지침 31: 비간섭 런타임 다형성에는 외부 다형성을 사용하라 __외부 다형성 디자인 패턴 해설 __도형 그리기 다시 보기 __외부 다형성과 어댑터 비교 __외부 다형성 디자인 패턴 단점 분석 08장: 타입 소거 디자인 패턴 지침 32: 상속 계통을 형 소거로 대체할 것을 고려하라 __타입 소거의 역사 __타입 소거 디자인 패턴 해설 __소유형 타입 소거 구현 __타입 소거 디자인 패턴 단점 분석 __두 타입 소거 래퍼 비교하기 __ 타입 소거 래퍼의 인터페이스 분리 __성능 벤치마크 __용어에 대한 한 마디 지침 33: 타입 소거의 최적화 잠재력을 인식하라 __소규모 버퍼 최적화 __함수 디스패치 직접 구현 지침 34: 소유형 타입 소거 래퍼의 설정 비용을 인식하라 __소유형 타입 소거 래퍼 설정 비용 __간단한 비소유형 타입 소거 구현 __더 강력한 비소유형 형 소거 구현 09장: 데코레이터 디자인 패턴 지침 35: 데코레이터를 사용해 사용자 __계통적으로 추가하라 __동료의 디자인 문제 __데코레이터 디자인 패턴 해설 __데코레이터 디자인 패턴의 고전적인 구현 __두 번째 데코레이터 예 __데코레이터, 어댑터, 전략 비교 __데코레이터 디자인 패턴 단점 분석 지침 36: 런타임과 컴파일 시점 추상__이율배반적 관계를 이해하라 __값 기반 컴파일 시점 데코레이터 __값 기반 런타임 데코레이터 10장: 싱글턴 패턴 지침 37: 싱글턴을 디자인 패턴이 아닌 구현 패턴으로 다루라 __싱글턴 패턴 해설 __싱글턴은 의존성을 관리하거나 줄이지 않는다 지침 38: 싱글턴을 변경과 테스트 용이성을 위해 디자인하라 __싱글턴은 전역 상태를 나타낸다 __싱글턴은 변경 용이성과 테스트 용이성을 저해한다 __싱글턴에 대한 의존성 뒤집기 __전략 디자인 패턴 적용 __지역 의존성 주입으로 전환 11장: 마지막 지침 지침 39: 디자인 패턴을 계속 배워라
