1) 절차지향과 객체지향
- 일반적으로 절차적 프로그래밍은 우리의 직관에 위배된다.
우리는 관람객과 판매원이 자신의 일을 스스로 처리할 것이라고 예상한다.
하지만 절차적 프로그래밍의 세계에서는 관람객과 판매원이 수동적인 존재일뿐이다.
타인이 자신의 가방을 마음대로 헤집어 놓아도 아무런 불만을 가지지 않는 소극적인 존재다.
절차적 프로그래밍의 세상은 우리의 예상을 너무나도 쉽게 벗어나기 때문에
코드를 읽는 사람과 원활하게 의사소통하지 못한다.
- 더 큰 문제는 절차적 프로그래밍의 세상에서는 데이터의 변경으로 인한 영향을
지역적으로 고립시키기 어렵다는 것이다.
Audience와 TicketSellter의 내부 구현을 변경하려면
Theater의 enter 메서드를 함께 변경해야 한다.
- 변경은 버그를 부르고 버그에 대한 두려움은 코드를 변경하기 어렵게 만든다.
따라서 절차적 프로그래밍의 세상은 변경하기 어려운 코드를 양산하는 경향이 있다.
- 변경하기 쉬운 설계는 한 번에 하나의 클래스만 변경할 수 있는 설계다.
절차적 프로그래밍은 프로세스가 필요한 모든 데이터에 의존해야 한다는
근본적인 문제점 때문에 변경에 취약할 수 밖에 없다.
- 해결 방법은 자신의 데이터를 스스로 처리하도록 프로세스의 적절한 단계를
Audience와 TicketSeller로 이동시키는 것이다.
수정한 후의 코드에서는 데이터를 사용하는 프로세스가 데이터를 소유하고 있는
Audience와 TicketSeller 내부로 옮겨졌다.
- 이처럼 데이터와 프로세스가 동일한 모듈 내부에 위치하도록 프로그래밍하는 방식을
객체지향 프로그래밍(Object-Oriented Programing)이라고 부른다.
- 객체지향 프로그래밍 방식으로 구현된 구조에서는 Theater는 오직 TicketSeller에만 의존한다.
물론 TicketSeller 입장에서는 Audience에 대한 또 다른 의존성이 추가됐지만
적절한 트레이드오프의 결과로 볼 수 있다.
- 훌륭한 객체지향 설계의 핵심은 캡슐화를 이용해 의존성을 적절히 관리함으로써
객체 사이의 결합도를 낮추는 것이다.
일반적으로 객체지향이 절차지향에 비해 변경에 좀 더 유연하다고 말하는 이유가 바로 이것이다.
- 객체지향 코드는 자신의 문제를 스스로 처리해야 한다는
우리의 예상을 만족시켜주기 때문에 이해하기 쉽고,
객체 내부의 변경이 객체 외부에 파급되지 않도록 제어할 수 있기 때문에 변경하기가 수월하다.
'오브젝트' 카테고리의 다른 글
| [오브젝트] 책임 (0) | 2024.12.24 |
|---|---|
| [오브젝트] 의존성 관리하기 (0) | 2024.12.13 |
