본문 바로가기

IT 도서 정리/오브젝트

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

핵심 용어

 

  • 도메인
  • 객체(상태 + 행동)
  • 접근 제어와 접근 수정자
  • 협력
  • 메시지와 메서드
  • 지연 바인딩(동적 바인딩)
  • 초기 바인딩(정적 바인딩)
  • 추상화
  • 상속과 다형성
  • 추상 클래스와 인터페이스
  • 상속과 협력

 

핵심 요약 - 객체지향 프로그래밍을 구성하는 다양한 요소와 구현 기법


객체지향 프로그래밍

 

온라인 영화 예매 시스템이라는 구체적인 예시로 설명을 시작한다.

 

객체지향 프로그래밍

1. 어떤 클래스가 필요한지 고민하기 전, 어떤 객체들이 필요한지 고민하라.
2. 객체를 독립적인 존재가 아닌, 기능을 구현하기 위해 협력하는 공동체의 일원으로 파악하라.

 

도메인(domain) - 문제를 해결하기 위해 사용자가 프로그램을 사용하는 분야

프로그래머는 도메인의 구조(객체들의 관계)에 맞게 클래스들을 구성하는 것이 좋다!

 

 

객체

객체 - 상태와 행동을 함께 가지는 자율적인 존재이다.

 

객체의 자율화는 캡슐화와 접근 제어로 실현되고,
이는 객체를 인터페이스(외부)와 구현(내부)로 구분한다.

 

접근 제어(access control) - 외부에서의 접근을 통제하는 메커니즘

 

 

협력 - 메시지와 메서드

 

협력(Collaboration) - 시스템의 어떤 기능을 구현하기 위해 객체들 사이에 이뤄지는 상호작용

 

협력은 오직 메시지의 전송과 수신으로만 가능하다!

 

이때 메시지와 메서드를 구분하는 것이 중요하다.

다형성의 개념이 바로 여기서 출발하기 때문이다.

 

메시지(message) - 객체끼리 상호작용을 위해 보내는 것. 객체들끼리 '무엇무엇을 해줘'라는 메시지를 주고받는다고 할 수 있다.
메서드(method) - 수신된 메시지를 처리하기 위한 객체 자신만의 방법

 

 

 

추상화 - 상속과 다형성

 

객체지향에서 코드(클래스)의 의존성과 실행 시점(객체)의 의존성은 서로 다를 수 있다.

두 의존성이 서로 다를 수 있는 이유 - 지연 바인딩

지연 바인딩(동적 바인딩) - 메시지와 메서드를 실행 시점에 바인딩
초기 바인딩(정적 바인딩) - 컴파일 시점에 실행될 함수나 프로시저를 결정

코드(클래스)의 의존성과 실행 시점(객체)의 의존성은 서로 다를 수 있는 것도 모두 지연 바인딩이라는 메커니즘 덕분이다.

 

※ 단, 다르면 다를수록 코드를 이해하는 것은 어려워진다는 트레이드오프가 존재한다.

 

상속과 다형성

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

 

다형성 - 동일한 메시지를 전송, but 실제로 어떤 메서드가 실행될 것인지는 메시지를 수신하는 객체의 클래스에 따라 달라지는 것.

 

그러므로, 다형적인 협력에 참여하는 객체는 모두 같은 메시지를 이해할 수 있어야 한다.

즉, 같은 인터페이스를 지녀야 한다.

이는 상속을 통해 쉽게 이뤄질 수 있다.

 

상속은 인터페이스와 추상 클래스를 통해 이뤄진다.

인터페이스 - 구현은 공유 X, 순수하게 인터페이스만 공유.
추상 클래스 - 구현과 인터페이스를 모두 공유.

※ 두 차이는 코드의 구현에서 트레이드 오프를 가져온다.

 

 

 

추상화와 유연성

 

추상적이라는 것은 인터페이스(외부)에 초점을 맞춘다는 것이다.

 

추상화의 장점은 두 가지가 존재한다.

1. 추상화의 계층만 따로 떼어놓고 살펴보면 요구사항의 정책을 높은 수준에서 서술할 수 있다.
※ 이는 기본적인 애플리케이션의 협력 흐름을 기술한다는 것이다.
2. 설계가 좀 더 유연해진다.

 

 

 

코드 재사용

 

상속은 코드 재사용을 위해 널리 사용되는 방법이다.

그러나, 코드 재사용을 위해서라면 상속보다는 합성(compositon)을 사용하는 것이 좋다.

 

합성 - 외부에 공개된 인터페이스에 정의된 메시지를 통해서만 코드를 재사용하는 방법

 

 

상속이 좋지 않은 이유

1. 캡슐화를 위반한다 - 상속을 할 경우 자식 클래스는 부모 클래스의 구조를 잘 알고있어야 한다. 이는 캡슐화를 위반한다.

2. 설계가 유연하지 않아진다 -  상속을 할 경우 부모 클래스와 자식 클래스 사이의 관계는 컴파일 시점에 결정된다.

 

※ 단 상속을 사용하지 말라는 것은 아니다, 상속과 합성은 언제나 함께 사용된다.
코드를 재사용하는 경우는 합성이 좋지만,
다형성을 위해 인터페이스를 재사용할 땐 상속을 사용하는 것이 좋다.

책에는 이밖에도 여러가지 tip과 개념들이 많았지만, 핵심 부분만을 살피기 위해 그 부분은 생략하였습니다.

궁금하다면 책을 구입해 읽어보는 것을 추천합니다.