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

[오브젝트] 00. 시작하기

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

 

책에서 기억하고 싶은 내용

어떤 객체가 필요할지 먼저 고민하자, 객체에 초점을 맞추는게 객체 지향이다.

+ 문제를 해결하기 위해 사용자가 프로그램을 사용하는 분야를 도메인이라고 한다

 

객체가 다른 객체와 상호 작용할 수 있는 유일한 방법은 메세지를 전송하는 것 뿐이다.

다른 객체로 부터 요청이 도착할 때 해당 객체가 메세지 수신 했다고 한다. 메세지를 수신한 객체는 스스로의 결정에 따라 자율적로 메세지를 처리할 방법을 찾는다. 수신된 메세지를 처리하기 위한 자신만의 방법은 메서드라 한다.

 

추상화

• 상속
• 다형성

상속은 부모 클래스가 제공하는 모든 인터페이스를 자식 클래스가 물려받을 수 있기 때문에 가치가 있다.

인터페이스는 객체가 이해할 수 있는 메시지의 목록을 정의한다.

구현 상속 → 서브클래싱(Subclassing) 인터페이스 상속 → 서브 타이핑(Subtyping)
대부분의 경우 상속은 구현 상속이 아니라 인터페이스 상속을 위해 사용해야 한다.
구현을 재사용할 목적으로 상속 하면, 변경에 취약해짐 (쉽게 변경 불가)

 

업캐스팅

외부 객체는 자식클래스를 부모 클래스와 동일한 타입으로 간주 할 수 있다.

상속의 단점

• 캡슐화 위반 ( 부모 클래스에 대한 이해를 필요함,부모 클래스 구현이 자식에게 노출됨 )
• 설계를 유연하지 못하게 만듬 ( 컴파일 시점에 정해지기 때문에, 실행 시점에 객체 종류 변경이 불가능 )

 

다형성

메세지 ≠ 메서드

메세지는 한결 같더라도 메세지를 수신하는 객체에 따라 어떤 메서드가 실행 될지 정해진다.

다형성이란 동일한 메세지를 수신 했을 때 객체 타입에 따라 다르게 응답할 수 있는 능력

 

추상화를 사용하면, 세부적인 내용을 무시한 채 상위 정책을 쉽고 간단하게 표현할 수 있다.

유연성이 필요한 곳에 추상화를 사용하라!

 

트레이드 오프

그러면 무조건 좋은 것인가? 그렇지 않다. 추상화를 선택함으로서 다른 기회비용 즉, 트레이드오프가 생긴다.

따라서 작성하는 코드는 합당한 이유가 있어야 한다.

 

상속은 코드를 재사용하기 위해 널리 사용되는 방법이지만, 가장 좋은 방법은 아니다.

코드 재사용을 위해서 더 선호하는 합성이라는 방법도 있다.

합성

인터페이스에 정의된 메세지를 통해서만 코드를 재사용하는 방법

 

 

떠오르는 생각

코드를 작성하는데 합당한 이유가 있어야한다는 것은 좋은 공감요소였다.

하지만 매번 합당한 이유를 찾으면서 설계하는 것은 쉽지 않을 것이라 생각했고 그래서 디자인패턴(어떠한 문제를 해결하기 위한 정형화된 방식)이 있는 거구나 알았다. 다음은 디자인 패턴을 공부해봐야겠다는 생각이 들었다.