#객체지향

한빛미디어 <나는리뷰어다> 활동을 위해서 책을 제공받아 작성된 서평입니다. 원제 : はじめての設計をやり抜くための本 第2版 (처음 설계를 시작하는 사람들을 위한 책 제2판) 저자 : 吉原 庄三郎 출간 : 翔泳社, 2022 / 한빛미디어, 2024 설계라는 영역의 세부 분야에 대해서 다루는 책은 많다, 아키텍처, UML, RDB 설계, 각종 개발 방법론, 프레임워크 개론 등, 제목만 붙여도 생각나는 책들이 많이 있다. 그러나 이들을 하나로 묶어내어 프로젝트가 진행되는 전체 과정을 다루는 실체는 대부분 다루지 않는다. 정답이 없는 영역이

타입 : 변수에 저장할 수 있는 내용물의 종류와 변수에 적용될 수 있는 연산의 가짓수를 의미. 안타깝게도 프로시저만으로는 충분히 풍부한 추상화의 어휘집을 제공할 수 없다. 이것은 언어 설계에서 가장 중요한 추상 데이터 타입의 개념으로 우리를 인도한다. 추상 데이터 타입은 추상 객체의 클래스를 정의한 것으로 추상 객체에 사용할 수 있는 오퍼레이션을 이용해 규정된다. 이것은 오퍼레이션을 이용해 추상 데이터 타입을 정의할 수 있음을 의미한다. 추상 데이터 객체를 사용할 때 프로그래머는 오직 객체가 외부에 제공하는 행위에만 관심을 가지며

퍼블릭 인터페이스에 오퍼레이션을 정의할때 참고할 수 있는 지침을 제공. 루틴 Routine : 어떤 절차를 묶어 호출 가능하도록 이름을 부여한 기능 프로시저 Procedure : 정해진 절차에 따라 내부의 상태를 변경하는 루틴의 종류. 부수효과를 발생시킴 함수 Function : 어떤 절차에 따라 필요한 값을 계산해서 반환하는 루틴의 종류. 부수효과가 없다. 명령 Command : 객체의 상태를 변경하는 명령은 반환값을 가질 수 없다. 쿼리 Query : 객체의 정보를 반환하는 쿼리는 상태를 변경할 수 없다. 질문이 답변을 수정해서

메시지를 처리할 책임과 책임을 수행하는데 필요한 변수 지정을 먼저 한다. 다른 객체의 구현을 고려할 필요 없이 필요한 메시지를 결정하면 다른 객체의 내부 구현을 깔끔하게 캡슐화 할 수 있다. 메시지가 변경되지 않는 한 객체에 어떤 수정을 가하더라도 호출하는 쪽에는 영향을 미치지 않는다. 메시지를 기반으로 협력을 구성하면 객체 사이 결합도를 느슨하게 유지할 수 있다. 책임 주도 설계 calculateFee()를 위한 객체 설계를 한다. 상세 구현을 한다. 4장과 다른점은 switch 문 내에 또 다른 분기가 없다는 점 정도.. 첫번째

데이터를 먼저 결정하고 고립된 객체의 상태에 초점을 맞추면 캡슐화를 위반하기 쉽고, 요소들 사이의 결합도가 높아지며, 코드를 변경하기 어려워진다. 책임에 초점을 맞춰서 설계할 때 어떤 객체에게 어떤 책임을 할당할지를 결정 하는 것이 어렵다. 책임 할당 과정은 트레이드오프 활동이다. 데이터 중심의 설계에서 책임 중심의 설계로 전환하는 방법 클라이언트 관점에서 객체가 수행하는 행동이란 곧 객체의 책임을 의미한다. 객체는 협력에 참여하기 위해 존재하며 협렵 안에서 수행하는 책임이 객체의 존재가치를 증명한다. 너무 이른시기에 데이터에 초점

객체지향 패러다임 관점의 핵심 역할 Role 책임 Responsibility 협력 Collaboration 협력 : 객체들이 어플리케이션의 기능을 구현하기 위해 수행하는 상호작용 책임 : 객체가 협력에 참여하기 위해 수행하는 로직 역할 : 객체들이 협력 안에서 수행하는 책임들이 모여 객체가 수행하는 구성 객체지향 시스템은 자율적인 객체들의 공동체다. 객체는 고립된 존재가 아니라 시스템의 기능이라는 더 큰 목표를 달성하기 위해 다른 객체와 협락하는 사회적인 존재다. 협력은 객체지향 세계에서 기능을 구현할 수 있는 유일한 방법이다. 메

이번 장은 이 책을 읽으면서 이해하게 될 다양한 주제들을 얕은 수준으로 가볍게 살펴보는 것 책의 예제 소개를 위한 요구사항 할인 조건 순서 조건 : 상영 순번으로 할인 여부 결정 기간 조건 : 영화 사영시작 시간으로 할인 여부 결정 할인 정책 : 할인 할 요금 결정 금액 할인 정책 : 정액 할인 비율 할인 정책 : 비율 할인 객체지향 패러다임으로 전환은 클래스가 아닌 객체에 초점을 맞출 때에만 얻을 수 있다. 어떤 클래스가 필요한지 고민 하기 전에 어떤 객체들이 필요한지 고민하라 클래스는 공통적인 상태와 행동을 공유하는 객체들을 추

이론보다 실무가 먼저다. 설계에 관한 이론은 1970년이 되서야 등장했다. 설계에 대한 이론은 있으나 유지보수에 대한 이론은 없다. 객체지향 프로그램을 설계하고 유지보수하는 데 필요하는 원칙과 기법을 설명하는것이 목적이다. 코드 보기 소프트웨어 모듈의 목적 실행 중에 제대로 동작하는 것이다. 변경을 위해 존재한다. 대부분의 모듈은 생명주기 동안 변경되기 때문에 간단한 작업 만으로도 변경이 가능해야 한다. 코드를 읽는 사람과 의사소통 하는것. 현실의 프로세스와 벗어난 비즈니스 로직은 코드를 읽는 사람과 제대로된 소통이 되지 않는다.