2장: 객체지향 프로그래밍
Last updated
Last updated
어떤 클래스가 필요한지를 고민하기 전에 어떤 객체들이 필요한지 고민하라. 어떤 객체들이 어떤 상태와 행동을 가지는지를 먼저 결정해야 클래스를 설계할 수 있다.
객체를 독립적인 존재가 아니라 기능을 구현하기 위해 협력하는 공동체의 일원으로 봐야 한다. 이를 통해 설계를 유연하고 확장 가능하게 만든다.
도메인이란 문제를 해결하기 위해 사용자가 프로그램을 사용하는 분야를 일컫는다.
요구사항과 프로그램을 객체라는 동일한 관점에서 바라볼 수 있기 때문에, 도메인을 구성하는 개념들이 프로그램의 객체와 클래스로 매끄럽게 연결될 수 있다.
아래는 영화 예매 도메인을 구성하는 개념과 관계를 표현한 것이다. 영화는 여러 번 상영될 수 있고 상영은 여러 번 예매될 수 있는 등의 관계를 표현하였다.
결국 위 도메인의 구조와 유사한 형태로 클래스의 구조도 정의될 것이다.
경계의 명확성이 객체의 자율성을 보장하기 때문에 클래스의 내부와 외부를 구분해야 한다.
이를 위해 외부에서는 객체의 속성에 직접 접근할 수 없도록 막고 적절한 public 메서드를 제공하여 내부 상태를 변경 할 수 있게 해야 한다.
객체는 상태와 행동을 가지는 복합적인 존재이고, 스스로 판단하고 행동하는 자율적인 존재이다.
객체의 상태는 숨기고 행동만 외부에 공개해야 객체지향의 핵심인 스스로 상태를 관리하고, 판단하고, 행동하는 자율적인 객체들의 공동체를 구성할 수 있다.
클래스 작성자
새로운 데이터 타입을 프로그램에 추가한다.
클라이언트 프로그래머에게 필요한 부분만 공개하고 나머지는 숨긴다. (implementation hiding | 구현 은닉)
public 영역을 변경하지 않는 이상 코드를 자유롭게 수정할 수 있다.
클라이언트 프로그래머
클래스 작성자가 추가한 데이터 타입을 사용한다.
필요한 클래스들을 엮어서 애플리케이션을 빠르고 안정적으로 구축하는 것이 목표이다.
사용자는 영화 예매 시스템을 이용해 쉽고 빠르게 보고 싶은 상영중인 영화를 예매할 수 있다. 특정 조건을 만족하는 예매자는 요금을 할인받을 수 있다.
영화는 제목, 상영시간, 가격 정보와 같이 영화가 가지고 있는 기본적인 정보를 나타낸다.
상영은 상영 일자, 시간, 순번 등을 나타낸다.
영화에는 할인 정책을 할당하지 않거나 할당하더라도 오직 하나만 할당할 수 있고, 할인 정책이 존재하는 경우에는 하나 이상의 할인 조건이 반드시 존재한다.
할인 조건을 통해 n번째 순서나 특정 기간일 때 할인 정책이 적용됨을 표현할 수 있다.
Screening
상영할 영화(movie), 순번(sequence), 상영 시작 시간(whenScreened)
reserve 메서드를 통해 예매한 영화 정보를 담고 있는 Reservation의 인스턴스를 생성해서 반환한다.
Money
금액과 관련된 다양한 유틸성 메서드를 담는 클래스이다.
의미를 좀 더 명시적이고 분명하게 표현할 수 있다면 객체를 사용해서 해당 개념을 구현해라. 그 개념이 비록 하나의 인스턴스 변수만 포함하더라도 개념을 명시적으로 표현하는 것은 전체적 인 설계의 명확성과 유연성을 높이는 첫걸음이다.
Reservation
고객(customer), 상영 정보(screening), 예매 요금(fee), 인원 수(audienceCount) 정보를 포함한다.
위와 같이 영화를 예매하기 위해 Screening, Movie, Reservation 인스턴스들은 서로의 메서드를 호출하며 상호 작용(협력)한다.
객체는 다른 객체의 인터페이스에 공개된 행동을 수행하도록 요청(request)할 수 있다.
요청을 받은 객체는 자율적인 방법에 따라 요청을 처리한 후 응답(response)한다.
메서드(method)란 다른 객체에서 요청이 도착하여 수신된 메시지를 처리하기 위한 자신만의 방법을 의미한다. 메시지를 수신한 객체는 스스로의 결정에 따라 자율적으로 메시지를 처리할 방법을 결정한다.
추상 클래스에서 메서드를 정의해두고, 세부적인 로직은 구현체에서 추상 메서드를 구현하도록 하는 방식
추상 클래스에서는 추상 메서드를 호출하여 기본적인 로직의 흐름을 구현하고, 중간에 필요한 처리는 자식 클래스가 담당하게 된다.
두 가지의 할인 조건을 표현하기 위해서는 먼저 인터페이스를 생성해 검증 로직을 담당하는 메서드를 만든다. 그리고 해당 메서드를 구현한 순번 조건과 기간 조건 클래스를 생성한다.
이후 영화에 적용될 할인 정책에 이러한 할인 조건 객체들을 저장해두면 된다.
위 코드는 구체 클래스에 의존하는 것이 아닌 인터페이스에 의존하고 있다. 실제로 객체를 생성하고 실행될 때 구체 클래스를 주입시켜주면 된다.
구현 상속을 서브클래싱(subclassing)이라고 부르고 인터페이스 상속을 서브타이핑(subtyping)이라고 부른다. 구현 상속은 순수하게 코드를 재사용하기 위한 목적으로 상속을 사용하는 것이고, 인터페이스 상속은 다형적인 협력을 위해 부모 클래스와 자식 클래스가 인터페이스를 공유하기 위해 사용한다.
코드의 의존성과 실행 시점의 의존성이 서로 다를 수 있다. 즉, 클래스 사이의 의존성과 객체 사이의 의존성은 동일하지 않을 수 있다.
설계가 유연해질수록 코드를 이해하고 디버깅하기는 점점 더 어려워진다.
코드의 의존성과 실행 시점의 의존성이 다르면 코드를 이해하기 위해서는 객체를 생성하는 부분을 찾아가 확인해야 하기 때문이다.
추상화를 사용하면 세부적인 내용을 무시한 채 상위 정책을 쉽고 간단하게 표현할 수 있다.
기본적인 애플리케이션의 협력 흐름을 표현할 수 있어 디자인 패턴이나 프레임워크 등에서도 모두 추상화를 이용해 상위 정책을 정의하는 객체지향의 매커니즘을 활용한다.
상속은 객체지향에서 코드를 재사용하기 위해 널리 사용되는 기법이지만 캡슐화를 위반하고, 설계를 유연하지 못하게 만든다.
컴포지션 방식은 인터페이스에 정의된 메시지를 통해서만 코드를 재사용한다. 즉, 인터페이스를 내부 변수로 두고 이 인터페이스에 정의된 메서드만 사용한다.
상속을 이용하기 위해서는 부모 클래스의 내부 구조를 잘 알고 있어야하므로 부모 클래스의 구현이 자식 클래스에게 노출되므로 부모 클래스의 변경이 일어날 때 자식 클래스도 변경되어야 하는 가능성이 높아진다.
상속은 부모 클래스와 자식 클래스 사이의 관계를 컴파일 시점에 결정하므로, 컴포지션 방식과 달리 런타임에 객체가 상속받는 부모 클래스를 변경하는 것이 불가능하다. 따라서 컴포지션 방식이 훨씬 유연한 설계이다.
상속은 다형성을 위해 인터페이스를 재사용하는 경우에 유용하다.