2장 객체 지향 프로그래밍

주요 키워드

• 도메인
•  

---

1장에서는 객체지향 프로그래밍을 공부하기 앞서 어떠한 코드가 좋은 코드인지 알려주는 내용이였다면 2장에서는 객체지향 프로그래밍하면 빠질수 없는 "다형성", "캡슐화", "접근제어자"같은 개념들을 위주로 설명하는 파트였습니다. 객체지향의 핵심 키워드를 다시 짚어가며 공부를 했기에 복습한다는 느낌으로 읽었고 제가 중요하다고 느낀것들을 인용하고 만약 제가 따로 코멘트 할 것이 있다면 따로 남기고자 합니다.

 

진정한 객체지향 패러다임으로의 전환은 클래스가 아닌 객체에 초점을 맞출 때에만 얻을 수 있다.

1장에서도 그랬듯 2장의 서두에서 객체지향의 본질은 클래스가 아닌 객체라고 언급하는 것을 확인할 수 있습니다.

 

어떤 클래스가 필요한지를 고민하기 전에 어떤 객체들이 필요한지 고민하라. 

1장의 말을 인용하자만 클래스는 객체를 표현하는 하나의 수단에 불과합니다. (ex. JavaScript) 그렇기에 객체를 중심으로 생각해야 합니다.

 

객체를 독립적인 존재가 아니라 기능을 구현하기 위해 협력하는 공동체의 일원으로 봐야 한다.

이 역시 1장에서 언급한 내용을 반복합니다. 그러나 여전히 중요하다고 생각합니다. 그리고 설계를 할 때 전지전능한 객체가 생성되는 것을 경계해야 한다고 생각합니다.

 

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

도메인 주도 설계(DDD)에서 나오는 도메인과 동일한 의미를 지닙니다. 그동안 도메인이라는 단어에 대해 어렴풋이 알고 있었지만 책에서 하나의 문장으로 짚고 넘어갔기 때문에 포스팅에도 작성하는게 좋다고 생각하였습니다.

 

경계의 명확성이 객체의 자율성을 보장하기 때문이다.

이 역시 1장의 내용을 반복하지만 다시 정리하면 객체들간의 명확한 경계는 책임의 분리로 이어진다고 생각합니다. 그리고 이는 좋은 설계의 첫걸음이라 생각합니다.

 

외부에서 접근 가능한 부분으로 이를 퍼블릭 인터페이스(Public Interface)라고 부른다.

비단 프로그램을 작성하는 순간뿐 아니라 컴퓨터에 대해 공부하면 필연적으로 접하게 되는 단어인 "인터페이스"입니다. 그리고 그 동안 저에게 있어 인터페이스란 두 기기가 통신하기 위한 하나의 창구정도로 생각을 하였습니다. 그러나 2장에서 인터페이스의 정의를 하나의 문장으로 정리해주었기 때문에 포스팅에 남기고자 합니다.

 

외부에서 접근 불가능하고 오직 내부에서만 접근 가능한 부분을 이를 구현(Implementation)이라고 합니다.

여기서 말하는 구현은 자바에서 사용하는 키워드인 implementation과는 조금 결이 다르다고 생각합니다. 자바에서는 implementation은 인터페이스를 사용할수 있게끔 만드는 것을 구현이라 하지만 여기서는 조금 더 개념적인 의미로 접근했다고 생각합니다.

 

의미를 좀 더 명시적이고 분명하게 표현할 수 있다면 객체를 사용해서 해당 개념을 구현하라.

이는 기존에 제가 알고 있는 지식과 매핑시키자면 하나의 래퍼 클래스(Wrapper Class)를 의미한다고 생각합니다. 그렇기에 예를 들어 좌표 값 x, y를 의미하는 데이터들이 있을때 이를 하나의 객체로 만들어 표현하면 기존보다 명확한 의미를 지닌다고 생각합니다.

 

부모 클래스에 기본적인 알고리즘의 흐름을 구현하고 중간에 필요한 처리를 자식 클래스에게 위임하는 디자인 패턴을 TEMPLATE METHOD패턴이라고 부른다.

객체지향 패러다임을 응용한 디자인 패턴중 하나로 이미 우리가 익숙하게 사용하고 있는 패턴중 하나입니다. 객체지향을 공부하고 객체지향 언어로 개발자를 희망한다면 반드시 배워야 하는 내용중 하나라고 생각합니다.

 

생성자의 파라미터 목록을 이용해 초기화에 필요한 정보를 전달하도록 강제하면 올바른 상태를 가진 객체의 생성을 보장할 수 있다.

이는 수정자(setter)로 상태 변경을 허용할 경우 생기는 문제점을 우회하며 설명했다고 생각합니다.

 

어떤 클래스가 다른 클래스에 접근할 수 있는 경로를 가지거나 해당 클래스의 객체의 메서드를 호출할 경우 두 클래스 사이에 의존성이 존재한다고 말한다.

응집도와 결합도를 이야기하며 빠질수 없는 키워드중 하나인 의존성에 대한 설명입니다. 쉽게 설명하자면 하나의 클래스가 다른 클래스의 정보를 알고 있는것이라 생각합니다. 그리고 이는 객체지향적으로 코드를 작성하면 어쩔수 없이 생겨나는 문제점으로 이를 최소화하기 위해 다형성이 필요하다고 생각합니다.

 

코드의 의존성과 실행 시점의 의존성이 서로 다를 수 있다는 것이다.
... 한가지 간과해서는 안되는 사실은 코드의 의존성과 실행 시점의 의존성이 다르면 다를수록 코드를 이해하기 어려워진다는 것이다....

의존성 대목을 읽기전까지는 코드 상의 의존성 == 의존성 이라 생각을 하였습니다. 그러나 실행시점의 의존성까지 언급을 해주며 서로 트레이드 오프라는 것을 짚어 주었기에 새로운 시각에서 객체지향적으로 생각할 수 있게 되었습니다.

 

상속이 가치 있는 이유는 부모 클래스가 제공하는 모든 인터페이스를 자식 클래스가 물려받을 수 있기 때문이다.
...
결과적으로 자식 클래스는 부모 클래스가 수신할 수 있는 모든 메시지를 수신할 수 있기 때문에 외부 객체는 자식 클래스를 부모 클래스와 동일한 타입으로 간주할 수 있다.
...

상속이 가지는 장점에 대해 언급하고 있습니다. 책에서는 추상 메서드를 위주로 설명하고 있습니다. 기존의 저는 인터페이스를 상속받아 구현하는 방향으로만 코드를 작성했기에 추상 메서드에 존재 의의에 다시금 생각할 수 있게 되었습니다. 

 

추상화의
첫 번째 장점은 추상화의 계층만 따로 떼어 놓고 살펴보면 요구사항의 정책을 높은 수준에서 서술할 수 있다는 것이다.
두 번째 장점은 추상화를 이용해 상위 정책을 표현하면 기존 구조를 수정하지 않고도 새로운 기능을 쉽게 추가하고 확장할 수 있다. 다시 말해 설계를 유연하게 만들 수 있다.

결국 추상화가 의미하는 것이 무엇이든 설계에서 말하는 요구사항을 높은 수준에서 처리할 수 있기 때문에 자주 사용한다고 생각합니다.

 

추상화가 유연한 설계를 가능하게 하는 이유는 설계가 구체적인 상황에 결합되는 것을 방지하기 때문이다.

바로 위에서 언급한 내용과 어느정도 일맥상통하며 이는 구현의 단계에서 언급하는 내용이라 생각합니다.

 

하나는 상속이 캡슐화를 위반한다는 것이고, 다른 하나는 설계를 유연하지 못하게 만든다는 것이다.

이는 상속이 가지는 단점이다. 책에서는 이를 해결하기 위해 합성이라는 것을 제시합니다.

 

인퍼테이스에 정의된 메시지를 통해서만 코드를 재사용하는 방법을 합성이라고 한다.

책에서 제시하는 합성의 정의입니다.