도서 오브젝트(Object) 요약 (저자: 배민 조영호님)

우아한 형제들의 조영호 팀장님 책  'Object'를 구입하시길 강력 추천드립니다.

객체지향 설계에 대한 모든것을 담아냈다해도 과언이 아닙니다

책 구입을 원하시는분은 요기를 클릭하시면 됩니다.

하단의 내용은 제가 예전에 읽었던 내용을 제 나름대로 요약한 것으로 저자의 의도와는 다를 수 있습니다

 

 

객체지향 프로그래밍: 책임과 권한을 가진 객체들이 서로 메시지를 주고 받으며 협력해서 필요한 기능을 수행하도록 시스템을 개발하는것

 

 

-훌륭한 객체지향 설계

 

1.데이터(상태) 보다 행동을 먼저 결정하라

2.협력이라는 문맥 안에서 책임을(객체에 정의되는 응집도있는 행위의 집합) 결정하라.

  메시지 전송자에게 적합한 책임을 할당해야한다.(객체지향 개발에서 가장 중요한 능력은 책임을 능숙하게 소프트웨어 객체에 할당하는것)

  메시지로 객체를 결정한다. 

3.모든 객체들이 자율적으로 행동하는 설계를 한다(자율성을 높이자. 자신의 문제를 스스로 해결하도록 코드를 변경하라)

4.캡슐화를 이용해 의존성을 적절히 관리함으로써 객체 사이의 결합도를 낮춘다.

 

 

 

-설계는 trade-off의 산물이자 균형의 예술(다양한 방법)

 

A의 자율성 vs B의 결합도

코드의 의존성 vs 실행시점 의존성

책임 할당 과정

 

 

-캡슐화

 

객체 내부의 세부적인 사항을 감추는 것을 캠슐화라고 부른다. 캡슐화 목적은 변경하기 쉬운 객체를 만드는 것이다. 

캡슐화를 통해 객체 내부로의 접근을 제한하면 객체와 객체 사이의 결합도를 낮출 수 있기 때문에 설계를 좀더 쉽게 변경할 수 있게 된다.

핵심은 객체 내부의 상태를 캡슐화하고 객체 간에 오직 메시지를 통해서만 상호작용하도록 만드는 것이다.

 

 

 

-다형성

 

다형성은 객체지향 프로그래밍의 컴파일  의존성과 런타임 의존성이 다를 수 있다는 사실을 기반으로 한다.

다형성은 동일한 메시지를 수신하더라도 동적(지연)바인딩에따라  다르게 응답(여러 메서드 중 한개) 할 수 있는 능력을말한다

다형성을 제공한다는 뜻은 소스코드의 의존성을 어디서든 역전시킬 수 있다는 의미

 

 

-추상화를 사용할 경우의 장점

 

요구사항의 정책을 높은 수준에서 서술할 수 있다.

설계가 좀 더 유연해지기에 확장에 용이하다

 

 

 

 

-상속

 

상속의 가장 큰 문제점은 캡슐화 위반으로 인한 강한결합으로 자식 클래스 변경될 확률 높인다.

설계가 유연하지 않다. 상속은 부모 클래스와 자식 클래스 사이의 관계를 컴파일 시점에 결정한다. 따라서 실행 시점에 객체의 종류를 변경하는 것이 불가능하다.

 

 

 

-협력

 

협력이란 어떤 객체가 다른 객체에게 무엇인가를 요청하는 것이다. 메세지 전송은 객체 사이의 협력을 위해 사용할 수 있는 유일한 커뮤니케이션 수단이다.

 

 

-책임

 

책임이란 협력에 참여하기 위해 객체가 수행하는 행동

책임이란 객체에 정의되는 응집도 있는 행위의 집합. 

객체의 책임을 크게 하는것(doing)과 아는것(knowing)의 두가지 범주로 세분화할 수 있다.

객체가 유지해야 하는 정보와 수행할 수 있는 행동에 대해 개략적으로 서술한 문장이다. 그래서 메시지보다 추상적이고 개념적으로 더 크다. 메시지 <책임

객체가 책임을 수행하게 하는 유일한 방법은 메시지를 전송하는 것이므로 책임을 할당한다는 것은 메시지의 이름을 결정하는 것과 같다.

객체지향 개발에서 가장 중요한 능력은 책임을 능숙하게 소프트웨어 객체에 할당하는것

책임 할당 과정은 일종의 트레이오프 활동이다. 

CRC카드 후보(Candidate, 클래스,객체,컴포넌트,역할),책임(Responsibiltiy), 협력자(Collaborator)

 

 

 

 

-메세지가 객체를 결정한다

 

객체에게 책임을 할당하는 데 필요한 메시지를 먼저 식별하고 메시지를 처리할 객체를 나중에 선택했다는 것이 중요하다

즉, 객체가 메시지를 선택하는 것이 아니라 메시지가 객체를 선택하게 했다.

이렇게 해야하는 이유는

 

첫째, 객체가 최소한의 인터페이스를(minimal interface) 가질 수 있게 된다. 

필요한 메시지가 실별될때까지 객체의 퍼블릭 인터페이스에 어떤 것도 추가하지 않기 때문에 객체는 애플리케이션에 크지도,작지도 않은 꼭 필요한 크기의 퍼블릭 인터페이스를 가질 수 있다.

 

둘째, 객체는 충분히 추상적인 인터페이스를(abstract interface) 가질 수 있게 된다.

객체의 인터페이스는 무엇을(what) 하는지 표현해야하지만 어떻게(how) 수행하는지를 노출해서는 안된다. 메시지는 외부의 객체가 요청하는 무언가를 의미하기 때문에 메시지를 먼저 식별하면 무엇을 수행할지에 초점을 맞추는 인터페이스를 얻을 수 있다.

 

 

-행동이 상태를 결정한다.

 

객체가 존재하는 이유는 협력에 참여하기 위해서다. 객체를 객체답게 만드는 것은 객체의 상태가 아니라 객체가 다른 객체에게 제공하는 행동이다.

객체지향 패러다임에 갓 입문한 사람들이 가장 쉽게 빠지는 실수는 객체의 행동이 아니라 상태에 초점을 맞추는 것이다.  

너무 이른 시기에 데이터에 초점을 맞추면 객체의 캡슐화가 약화되기 때문에 낮은 응집도와 높은 결합도를 가진 객체들로 넘쳐나게 된다. 그결과로 얻게 되는것은 변경에 취약한 설계다.

가장 기본적인 해결방법은 객체를 설계하기 위한 질문의 순서를 바꾸는것이다. 데이터 중심의 설계에서는 "이 객체가 포함해야 하는 데이터가 무엇인가?"를 결정한 후에 "데이터를 처리하는데 필요한 오퍼레이션은 무엇인가?"를 결정한다. 

반면 책임중심의 설계에서는 "이 객체가 수행해야하는 책임은 무엇인가"를 결정한 후에 " 이 책임을 수행하는데 필요한 데이터는 무엇인가" 를 결정한다. 

 

 

 

-역할과협력

 

객체가 어떤 특정한 협력 안에서 수행하는 책임의 집합을 역할이라고 부른다.

역할은 다른 것으로 교체할 수 있는 책임의 집합이다.

 

 

 

-응집도와 결합도

 

응집도는 모듈에 포함된 내부 요소들이 연관돼 있는 정도를 나타낸다.

응집도란 변경이 발생할 때 모듈 내부에서 발생하는 변경의 정도로 측정할 수 있다.

응집도가 높은 사례에서는 하나의 요구사항을 변경하기 위해 오직 하나의 모듈만 수정하면된다.

 

 

밀접하게 연관된 작업만을 수행하고 연관성이 없는 작업은 다른 객체에게 위임하는 객체를 가리켜 응집도가 높다고 말한다. 

자신의 데이터를 스스로 처리하는 자율적인 객체를 만들면 결합도를 낮출 수 있을뿐더라 응집도를 높일 수 있다. 

객체의 응집도를 높이기 위해서는 객체 스스로 자신의 데이터를 책임져야 한다. 객체는 자신의 데이터를 스스로 처리하는 자율적인 존재여야한다.

 

응집도가 낮은 클래스의 특징

1.응집도가 낮으면 클래스가 여러 이유로 변경된다

2.인스턴스 변수가 초기화 되는 시점에 객체의 속성중 일부만 초기화됨 -->함께 초기화되는 속성을 기준으로 코드를 분리해야한다( 응집도가 높으면 모든 속성을 함께 초기화함).

3.메서드들이 인스턴스 변수를 사용하는 방식을 봤을때  메서드들이 사용하는 속성에 따라 그룹이 나뉜다면 응집도가 낮은것이다-->함께 사용되는 그룹을 기준으로 클래스를 분리 (모든 메서드가 객체의 모든속성을 사용하면 응집도가 높은 것이다.) 

 

 

 

결합도는 의존성의 정도를 나타내며 다른 모듈에 대해 얼마나 많은 지식을 갖고 있는지를 나타내는 척도다

결합도는 한 모듈이 변경되기 위해서 다른 모듈의 변경을 요구하는 정도로 측정할 수  있다. 다시말해 하나의 모듈을 수정할때 얼마나 많은 모듈을 함께 수정해야하는지를 나타낸다.

결합도가 높으면 함께 변경해야 하는 모듈의 수가 늘어나기 때문에 변경하기가 어려워진다.

의존성은 변경에 대한 영향을 암시한다. 객체 사이의 의존성이 과한 경우를 가르켜 결합도가 높다고 말한다.

 

 

 

-디미터의 법칙 

최소 지식의 원칙

묻지 말고 시켜라(Tell, don't ask)

 

 

 

-명령 쿼리 분리의 원칙

 

프로시저는 부수효과를 발생시킬 수 있지만 값을 반환할 수 없다.

함수는 값을 반환할 수 있지만 부수효과를 발생시킬 수 없다.

 

명령은 프로시저와 동일하고 쿼리는 함수와 동일하다

객체의 상태를 변경하는 명령은 반환값을 가질 수 없다. 

객체의 정보를 반환하는 쿼리는 상태를 변경할 수 없다.