[책읽기] 오브젝트_01 객체, 설계

https://jojoldu.tistory.com/609 

향로님의 글에 추천되어 있는 책을 한 권 빌렸다.

 

백엔드 프리온보딩을 하며, "객체지향이란 뭘까"에 대한 고민을 다시 하게되었다.

배워서 잘 쓰고있다고 생각했지만, 실제로 접목하려고하니 머리가 아팠다. 

 

객체지향이란 뭘까? 그 해답을 얻을 수 있을까 하여 이 책을 읽으려고 한다.

 

서울시 전자도서관에서 책을 빌렸다. 도서관 만세

 

들어가며_ 프로그래밍 패러다임 

프로그래밍 패러다임은 개발자 공동체가 동일한 프로그래밍 스타일과 모델을 공유할 수 있게 한다.

이로써 불필요한 의견 충돌을 방지하고, 동일한 규칙과 방법을 공유하는 개발자로 성장할 수 있도록 한다.

 

이 책은, 객체지향 패러다임에 대한 책이다. 

우리가 객체지향 패러다임에 대해 어느정도 유사한 그림을 그릴 수 있는 기반을 제공하고,

어느정도 동일한 규칙과 표준에 따라 프로그래밍할 수 있도록 한다.

 

CHAPTER 01_ 객체, 설계 

책에서는 티켓 판매 애플리케이션을 예제로 들어 코드와 함께 설명하고 있다.

 

핵심 : 어떻게 변경하기 쉬운 코드를 작성할 수 있을까?

 

인터페이스(interface)와 구현(implementation) 

객체를 인터페이스와 구현으로 나누고, 인터페이스만을 공개

→ 객체 사이의 결합도를 낮추고 변경하기 쉬운 코드를 설계하기 위한 기본 원칙이다.

 

인터페이스 : 외부에서 접근 가능한 영역

구현 : 외부에서 접근이 불가능한 영역 (상세 내용)

 

A객체가 B객체를 이용할 때, 내부에 어떤 필드를 포함하고 있는지는 몰라도 되고,

오직 인터페이스에만 의존한다. 

 

캡슐화의 목적 

각 객체들은 캡슐화를 통해, 내부 구현을 외부에 노출하지 않고 자율성을 띌 수 있다.

→ 자신의 문제를 스스로 해결할 수 있다.

→ 객체 스스로 자신의 데이터를 책임질 수 있다.

 

절차지향 VS 객체지향 

절차지향 : 책임(기능)이 한 곳에 집중

• 프로세스 / 데이터가 별개로 존재
  • 모든 처리가 하나의 클래스(프로세스)에 의존하고, 나머지는 그저 데이터 역할이다.
  • 데이터는 모두 수동적인 존재이다.
• 클래스 하나를 수정하기 위해 여러 클래스를 수정해야한다.
  • 프로세스가 필요한 모든 데이터에 의존하기 때문이다.

→ 각 객체가 자신의 데이터를 스스로 처리하도록 프로세스의 일부를 이동할 수 있다. (객체지향으로 가는 길)

 

객체지향 : 책임이(기능) 여러 객체에 분산

• 프로세스 / 데이터가 함께 존재 
  • A객체와 관련된 프로세스는 A객체 안에 존재
• 캡슐화를 이용한다.
• 불필요한 의존성이 제거됨으로 인해, 결합도가 낮아진다

 

객체 

현실에선 수동적인 객체일지라도, 객체지향 세계에선 능동적이고 자율적인 존재이다.

객체지향에서 각 객체들을 현실과 비슷하게 설계해야 한다고 생각할 수 있다.

현실에서 대부분의 객체들은, 인간 없이는 수동적인 존재이다. (인간없이는 아무 일도 일어나지 않는다.)

하지만, 객체지향에서의 객체들은 능동적이고 자율적이다.

 

의인화적 관점에서 소프트웨어를 생물로 생각하자. 

 

객체지향 설계의 핵심 

클래스를 설계하는 것이 아닌, 객체를 먼저 생각해보고 이후에 객체들에 해당하는 클래스를 고민하는 것.

캡슐화를 통해 적절한 객체에 적절한 책임을 할당하는 것

불필요한 의존성을 제거해 객체 사이의 결합도를 낮춰라. = 최소한의 의존성만 남겨라. 

어떻게?

캡슐화해라!

 

설계 

설계란 코드를 배치하는 것이다.

좋은 설계?

오늘의 요구 기능을 온전히 수행하면서, 내일의 변경을 매끄럽게 수용할 수 있는 설계이다.

 

변경을 매끄럽게 수용한다?

이해하기 쉬운 코드 -> 의존성이 적은 코드를 말한다. 

 

애플리케이션은 여러 개의 객체로 구성되고,

애플리케이션의 기능은 객체간 상호작용을 통해 구현된다.

 

객체간 상호작용은 주고받는 메세지로 표현되고,

메세지를 전송하기 위한 지식이 두 객체를 결합시키며 의존성을 만들어낸다.

 

좋은 객체지향 설계?

협력하는 객체 사이의 의존성을 적절히 관리하는 설계이다.

 

어떤 기능을 설계하는 방법은 한 가지 이상일 수 있다.

동일한 기능을 한 가지 이상으로 설계할 수 있기 때문에, 설계는 트레이드오프의 산물이다.

어떤 경우에도 모든 사람을 만족시킬 수 있는 설계는 없다.

설계는 균형의 예술. 훌륭한 설계는 적절한 트레이드오프의 결과

 

결론 

책의 내용을 나름대로 정리해보았는데, 중복되는 내용도 많고 정리가 없는 것 같긴 하다.

내가 이해한대로 요약해보자면,

 

굳이 좋은 설계를 하지 않더라도 돌아가는 프로그램은 만들 수 있다. 

하지만 의존성이 높은 코드는 변경이 어렵다.

 

그리고, 요구사항은 고정되지 않고 자주 변경된다. 따라서 우리는 미래를 위해 변경에 용이한 코드를 작성할 필요가 있다.

 

변경에 용이하기 위해서는, 각 객체간 결합도가 낮아야하고 이는 불필요한 의존성을 제거해야한다는 말이다.

의존성을 제거하기 위해서는, 캡슐화를 이용해서 인터페이스만 제공하고 상세한 구현은 외부에서 알 수 없어야 한다.

 

그런데, 캡슐화를 하다보면 결합도가 오히려 높아지는 상황이 발생하기도 한다. 두 가지중에 어떤 것이 정답이라고 할 수 없으며, 따라서 설계는 답이 정해져있지 않은 균형의 예술이라는 표현을 쓰기도 한다.

 

모든 사람을 만족시키는 설계는 없다. 라는 말이 인상적이었다.

 

그럼에도 더 나은 설계를 위해 꾸준히 고민해야할 것 같다.