• 컴퓨터/IT > 컴퓨터공학 > UML/객체지향

2020/7 컴퓨터/IT 9위 | 현재 컴퓨터/IT 9위 |

출판사 리뷰

필자는 객체지향 프로그래밍과 구조적 프로그래밍은 서로 경쟁하는 관계에 있는 게 아니라고 생각했기 때문에 늘 그러한 패러다임이 이상하다고 생각했다. 객체들은 구조적 코드와 잘 통합되므로 보완적이다. 지금도 종종 필자는 ‘구조적 프로그래밍을 하는가, 아니면 객체지향 프로그래밍을 하는가?’라는 질문을 받는다. 망설임 없이 필자는 양쪽 방식을 다 쓴다고 대답할 것이다.
_3페이지

다중 상속이라는 말을 통해서 알 수 있듯이, 다중 상속을 통해, 어떤 한 가지 클래스는 자기 자신이 아닌 그 밖의 클래스들 중 두 개 이상으로부터 상속을 받을 수 있다. 실제로도 다중 상속이 좋은 방안인 것처럼 보인다. 객체로 실제 세계를 본떠야 하는가, 아니면 그러지 않아도 되는가? 그리고 많은 다중 상속 사례들이 현실 세계에도 존재한다. 부모는 다중 상속의 좋은 예다. 각 어린이에게는 부모가 두 명 있다. 따라서 다중 상속을 사용해 클래스를 설계할 수 있다고 보는 게 합리적이다. C++와 같은 일부 객체지향 언어에서는 다중 상속이 가능하다.
_77페이지

객체지향 프로그래밍의 주요 목표 중 하나는 사람들이 실제로 생각하는 방식과 비슷한 방식으로 현실 세계의 시스템을 모델링하는 것이다. 클래스 설계라는 것은 이러한 모델을 작성하기 위해 동원하는 객체지향적인 방법이다. 객체지향 방식은, 데이터와 행위가 논리적으로 별개의 객체가 되게 하는 구조적 방식이나 하향식(top-down) 방식을 사용하는 대신에, 데이터와 행위가 서로 상호 작용할 수 있게 한 객체 안에 두어 캡슐화한다.
_95페이지

합성(composition)이란 다른 클래스를 사용해 더 복잡한 클래스, 즉 일종의 어셈블리(assemblies, 즉 ‘조립체’)를 구축하는 작업이 포함된다. 이 경우에 부모/자식 관계가 없다. 기본적으로 복합객체(complex objects)는 그 밖의 객체들을 가지고 합성한 것이다. 합성은 has-a 관계를 나타낸다. 예를 들어, 자동차에는 엔진이 있다(has-a 관계). 엔진과 자동차는 모두 서로 분리된 객체, 즉 잠재적으로 각기 독립 객체인 것이다. 그러나 자동차는 엔진 객체가 포함된 복합 객체다. 실제로 자식 객체 자체는 다른 객체로 합성될 수 있다. 예를 들어, 엔진에 실린더가 포함될 수 있다. 이 경우에 엔진에는 실제로 실린더가 있다(has-a 관계).
_132페이지

상속을 적절하게 사용하는 방법에 대해 토론할 때 알 수 있었듯이, 최근 개발 환경에서는 이 목록에 합성이 꼭 들어가야 한다. 상속을 꺼리는 일은 예전부터 있어 왔다. 그리고 지난 몇 년에 걸쳐서 이 논쟁이 격화되었다. 필자가 대화해 본 많은 개발자들은 상속보다는 합성을 사용하는 게 좋다고 말한다(가끔은 합성이 상속보다 우위에 있다고도 말한다). 실제로도 어떤 프로그래머는 상속을 전혀 사용하지 않거나 상속 사용을 단일 계층 수준으로 제한해 최소화한다.
_221~222페이지

CHAPTER 1 객체지향 개념 소개 1
기본 개념 2
객체와 레거시 시스템 3
객체지향 프로그래밍과 절차적 프로그래밍 4
절차적 개발에서 객체지향적 개발로 옮겨 타기 9
객체란 정확히 무엇일까? 10
클래스란 정확히 무엇을 일컫는 말인가? 16
시각화 도구로 클래스 다이어그램 사용하기 20
캡슐화 및 데이터 은닉 20
상속 25
다형성 29
합성 33
결론 35

CHAPTER 2 객체라는 관점에서 생각하는 방법 37
인터페이스와 구현부의 차이점 이해 39
인터페이스 설계 시 추상적으로 생각해 보기 47
가능한 한 사용자 인터페이스를 적게 제공하기 49
결론 54
참고 문헌 54

CHAPTER 3 그 밖의 객체지향 개념들 55
생성자에 관하여 55
오류 처리 64
범위의 중요성 69
연산자 오버로딩 75
다중 상속 77
객체 연산 78
결론 80
참고문헌 80

CHAPTER 4 클래스 해부하기 81
클래스의 이름 82
속성 84
생성자 86
접근자 88
공개 인터페이스 메서드 91
비공개 구현부 메서드 92
결론 93
참고문헌 93

CHAPTER 5 클래스 설계 지침 95
현실 세계 시스템 모델링 95
공개 인터페이스 식별 97
튼튼한 생성자나 소멸자가 되게 설계하기 99
클래스에 대한 오류 처리 설계 100
재사용을 고려한 설계 102
확장성을 고려한 설계 102
유지보수를 고려한 설계 106
객체 지속성 사용 110
결론 111
참고문헌 112

CHAPTER 6 객체를 사용해 설계하기 113
설계 지침 114
객체 래퍼 121
결론 128
참고문헌 129

CHAPTER 7 상속과 합성에 익숙해지기 131
객체 재사용 132
상속 133
캡슐화가 객체지향의 기본이 되는 이유 143
결론 153
참고문헌 154

CHAPTER 8 프레임워크 및 재사용: 인터페이스와 추상 클래스를 사용해 설계하기 155
코드: 재사용할 것인가, 사용하지 않을 것인가? 155
프레임워크란? 156
계약이란? 158
전자상거래 사례 173
결론 182
참고문헌 183

CHAPTER 9 객체 구축과 객체지향 설계 185
단계적으로 구축하기 187
합성 유형 190
의존체 회피하기 193
카디널리티 195
종합: 예제 199
결론 200
참고문헌 200

CHAPTER 10 디자인 패턴 201
디자인 패턴이 필요한 이유 202
스몰토크의 모델/뷰/컨트롤러 204
디자인 패턴의 종류 206
안티패턴 216
결론 218
참고문헌 218

CHAPTER 11 의존적이거나 경직된 클래스가 되지 않게 하기 221
합성 대 상속, 그리고 의존성 주입 224
결론 232
참고문헌 233

CHAPTER 12 객체지향 설계의 SOLID 원칙 235
객체지향 설계의 SOLID 원칙 237
결론 255
참고문헌 255

찾아보기 257