오브젝트 - 1장 객체, 설계(강추)
우선 이챕터는 이해할 수 없을 가능성이 높음. ( 결론적으로 이해하기 매우 쉬웠음-> 객체지향의 사실과 오해를 읽고 와서 그런건지.. 그런데 확실한 것은 그 책보다는 쉬움)
다른 챕터들의 내용을 축약해놓고, 그 다음에 하나씩하나씩 다음 챕터에서 나아갈 것이기 때문.
이론이 먼저인가? 실무가 먼저인가?
로버트 글래스 → 이론이 먼저인가? 실무가 먼저인가?
어떤 분야를 막론하고 이론을 정립할 수 없는 초기에는 실무가 먼저 급속한 발전을 이룬다. 실무가 어느정도 발전학 ㅗ난 다음에야 비로소 실무의 실용성을 입증할 수 있는 이론이 서서히 그 모습을 갖추고, 그 후에 이론이 실무를 추월하게 된다.
소프트웨어 분야 → 실무가 더 앞서있으며, 실무가 먼저
객체지향 프로그램을 설계하고 유지보수하는데 필요한 원칙과 기법
→ 실무가 먼저이므로, 실무부터 소개
티켓판매 어플리케이션
의식의 흐름대로 티켓판매 어플리케이션을 작성했으나, 뭔가 부족해보임 → 더 낫게 바꾼다?
클린 소프트웨어
- 기능해야함
- 변경하기 쉬워야함 ( 어려우면 그부분을 고쳐야함)
- 가독성이 좋아야함 ( 읽기 어려우면 고쳐야함)
변경 용이성과 가독성이 좋지 않음
문제는 소극장이 관람객 마음대로 초대장을 확인하여 열어본다는 것.
코드를 이해하기 힘듬 → 실제로는 그렇게 동작되지 않기 때문
Theater를 이해하기 위해서는 Audience가 bag을 가지고 있고, Bag안에는 현금과 티켓이 들어있고.. TicketSeller가 TickerOffice를 판매하고..
하나의 클래스나 메서드에서 너무 많은 세부사항을 다루기 떄문에 작성하는 사람뿐만 아니라 코드를 읽고 이해하는 사람 모두에게 큰 부담을 준다.
변경에 취약한 코드
이 코드는 관람객이 현금과 초대장을 보관하기 위해 항상 가방을 들고 다닌다고 가정. 판매원이 매표소에서만 티켓을 판매한다고 가정한다. 관람객이 현금이 아니라 신용카드를 이용해서 결제한다면? 판매원이 매표소 밖에서 티켓을 판매해야 한다면?
→ 변경하기 쉽게 만등자
객체 사이의 의존성(dependency)과 관련된 문제다. 문제는 의존성이 변경과 관련돼 있다는 점이다.
객체 사이의 의존성을 완전히 없애는 것이 정답이 아님. 객체지향 설계는 서로 의존하면서 협력하는 객체들의 공동체를 구축하는 것.
객체 사이의 의존성이 과한 경우를 가리켜 결합도(coupling)가 높다고 말한다.
설계 개선하기
→ 변경과 의사소통이라는 문제가 서로 엮여 있음
→ 관람객과 판매원은 자신의 일을 스스로 처리해야 한다는 우리의 직관을 벗어남
Theater가 관람객의 가방과 판매원의 매표소에 직접접근한다는 것은 여러단계에 걸쳐서
결합되어 있다는 것 → 변경이 거의 불가능한 상황
Theater가 관람객과 판매원에 관해 세세한 사항까지 모르도록 정보를 차단하자!
→ 아마도 이게 public method 겠지..
관람객이 가방을 가지고 있다는 사실과 판매원이 매표소에서 티켓을 판매한다는 사실을 극장이 알필요가 없음. 극장이 원하는 것은 관람객이 소극장에 입장하는 것 뿐.
관람객이 스스로 가방안의 현금과 초대장을 처리하고( 관람객마다 다양하게 구입가능)
판매원이 스스로 매표소의 티켓과 판매 요금을 다루게 하자 ( 판매원마다 다양하게 판매가능!!)
객체지향의 사실과 오해가 떠오르는..
→ public 함수 없애기 → 캡슐화
Theater는 TickerSeller의 인터페이스에만 의존하도록 수정 → Theater의 의존성을 낮추어 설계
관람객이 소지품을 스스로 관리, → 근데 이거 너무 당연한거 아닌가.. → 요즘 코드 저렇게 짜ㅡㄴ 사람 없으니까
핵심은
객체 내부 상태를 캡슐화 → 객체 간에 오직 메시지를 통해서만 상호작용하도록 만드는 것 ( 그래야 의존성이 낮아져서 변경하기 엄청 쉬워짐)
서로 내부를 모르도록 설계하자
밀접하게 연관된 작업만을 수행하고 연광성 없는 작업은 다른 객체에게 위임하는 객체 > 응집도가 높다.
자신의 데이터를 처리 → 외부의 간섭을 배제하고 메시지를 통해서만 협력하는 자율적인 개개ㄱ체들의 공동체를 만든다.
절차지향과 객체지향
데이터와 프로세스로 나누어 진행하는 것 → 절차적 프로그래밍
절차적 프로그래밍은 우리의 직관에 위배된다.
절차적 프로그래밍은 변경하기 어려운 코드를 양산하는 경향이 있음
데이터와 프로세스를 동일한 모듈 내부에 위치하도록 프로그래밍 하는 방식을 객체지향 프로그래밍
훌륭한 객체지향 설계의 핵심은 캡슐화를 통해 의존성을 적절히 관리함으로써 객체 사이의 결합도를 낮추는 것이다.
책임의 이동
두 방식의 근본적인 차이. 절차지향에서는 데이터에는 책임이 없었지만, 객체지향에서는
객체가 책임을 지님.
결국, 절차지향에서는 극장이 모든 책임을 지녔지만, 객체지향에서는 책임이 적절하게 분산돼있음
객체지향은 단순히, 데이터와 프로세스를 하나를 합친 것보다 큰 무언가
- 책임이 분산되어, 변경에 탄력적으로 대응할 수 있게 됨
- 코드가 더 이해하기 쉬워짐. 직관적으로 해당 객체의 역할을 설정할 수 있음
설계를 어렵게 하는 것→ 의존성 → 불필요한 의존성을 낮춤으로서 결합도를 낮추는 것
가방도 자율적인 존재로 바꾸자
Bag의 내부 상태에 접근을 public에서 private으로 변경
tickerSeller도 역시 자율성을 주기 위해 변경했지만..
→ 의존성이 복잡해짐
자율성과 의존성 둘 중에 하나를 포기해야할 때가 종종 찾아옴
- 설계하는 방법은 한 가지 이상일 수 있음
- 동일한 기능을 한 가지 이상의 방법으로 설계할 수 있기 떄문에 결국 설계는 트레이드오프의 산물
- 어떤 경우에도 모든 사람들을 만족시킬 수 있는 설계를 만들 수 없음
여기까지 읽고 난 생각..
객체지향의 사실과 오해보다 훨씬 이해하기 쉬운듯..
→ 이 책을 읽고 객체지향의 사실과 오해를 읽었으면 더 좋았을 지도
(왜냐하면 1장이 이해하기 어려울 수 있다고 했지만, 예제를 통해서 이해하기 매우 쉬웠다.)
객체지향의 세계에 오면, 모든 것이 능동적이고 자율적인 존재로 바뀜. 능동적이고 자율적인 존재로 소프트웨어 객체를 설계하는 원칙을 의인화라고 함.
설계가 왜 필요한가
설계란 코드를 배치하는 것
어떤 사람들은 설계를 코드를 작성하는 것보다는 높은 차원의 창조적인 행위
→ 하지만 설계를 구현과 떨어트려서 이야기하는 것은 불가능
구현이 불가능하면 설계자체가
→ 매 순간 코드 배치를 어떻게 할 것인가에 대한 고민
설계는 코드 작성의 일부
변경에 유연하게 대응할 수 있는 코드!
객체지향 패러다임 → 세상을 바라보는 방식대로 코드를 작성할 수 있음!!
객체 사이의 의존성을 적절하게 관리하는 설계!
유연한 객체지향 설계에 이르는 길이 생각보다 어렵지 않다는 사실을 알게 될 것이다.
1장을 읽은 후기는
<객체지향의 사실과 오해> 이전에 <오브젝트>를 읽어야한다는 것이다.
왜냐하면 1장의 도입부에서 작가가 말했듯이,
이론인가 실무인가에 대해
우리들은 둘다 잘 모르는 상태이며,
객체지향 실무에 완전 초고수가 아닌이상
실제 코드의 예제로 이해하는 것이 훨씬 이해하기 쉬울 것이다.
물론 객체지향의 사실과 오해에도 코드는 분명히 있긴하지만,
있다고 하기 좀 그렇다.