SEARCH : 📚 Book(48)

CATEGORY : 📚 Book(48)

TAGS : 📚 Book(48)

ARCHIVE : 📚 Book(48)

06 메세지와 인터페이스

06 메세지와 인터페이스

2020. 2. 19.

들어가며 클라이언트-서버 모델 두 객체 사이의 협력 관계를 설명하기 위해 사용되는 메타포는 클라이언트 - 서버(Client - Server) 모델이다. 협력 안에서 메세지를 전송하는 객체를 클라이언트, 메세지를 수신하는 객체를 서버라고 부른다. Movie는 DiscountPilicy의 관점에서 메세지 전송자가 될 수 있다. 대부분의 사람들은 객체가 수신하는 메세지의 집합에만 초점을 맞추지만 협력에 적합한 객체를 설계하기 위해서는 외부에 전송하는 메세지의 집합도 함께 고려하는 것이 바람직하다. 객체가 독립적으로 수행할 수 있는 것보다 더 큰 책임을 수행하기 위해서는 다른 객체와 협력해야 한다. 두 객체 사이의 협력을 가능하게 해주는 매개체가 바로 메세지 이다. 메세지와 메세지 전송 메세지는 오퍼레이션명(o..

7장 SRP: 단일책임 원칙

2020. 2. 17.

들어가며 사람들이 흔히 알고있는 의미는 "하나의 클래스는 하나의 책임만을 가지고 설계가되어야한다." 이다. 하지만 하나의 책임(일)을 가지는것은 함수 또는 메서드이다. 결론적으로 SRP의 정확한 의미는 "하나의 모듈(함수와 데이터로 응집된 집합)은 하나의, 오직 하나의 액터에 대해서만 책임져야한다." 이다. SRP를 위반하는 사례 1 : 우발적 중복 하나의 클래스가 여러메서드를 포함하는데 이 여러 메서드를 서로다른 액터를 책임지는경우 SRP를 위반한다. -> 하나의 액터에 의해 한 메서드를 변경하게될 경우 다른 액터에게도 영향이 가기때문. 결국 SRP는 서로 다른 액터가 의존하는 코드를 서로 분리하라고 말함. 2 : 병합 마찬가지로 하나의 클래스의 여러 메서드가 서로다른 액터를 책임지는 경우 각각의 개발..

5장 객체 지향 프로그래밍

2020. 2. 17.

들어가며 OO (Object-Oriented)를 설명 할 때 주로 캡슐화, 상속, 다형성 이 세 가지 적절히 조합된것이라고 말하고는 한다. 캡슐화 (Encapsulation) 캡슐화는 데이터와 함수가 응집력 있게 구성된 집단을 서로 구분선을 그어 구분선 바깥에서는 데이터가 은닉되고, 일부 함수만이 외부에서 노출되는 것을 말한다. OO가 강력한 캡슐화를 지원하지는 않는다.(C++에서는 헤더파일에 멤버변수명이 노출됨) 그러므로 OO프로그래밍은 프로그래머가 충분히 올바르게 행동함으로써 캡슐화된 데이터를 우회해서 사용하지 않을 거라는 믿음을 기반으로 한다. 상속 (Inheritance) OO언어 이전에도 상속이란 개념은 존재했으며 C언어에서도 구현해서 사용하고 있었다. OO언어가 완전히 새로운 개념을 만들지는 ..

6장 함수형 프로그래밍

2020. 2. 17.

가변성의 분리 "함수형 언어에서는 변수의 값이 변경 되지않는다." 아키텍처를 고려할 때 이 내용은 중요하게 여겨진다. 경합 조건, 교착상태 조건, 동시업데이트 즉, 동시성 문제가 모두 가변 변수로 인해 발생하기 때문이다. 그렇기때문에 애플리케이션을 제대로 구조화하기위해서는 변수를 변경하는 컴포넌트와 변경하지않는 컴포넌트를 분리해야한다. 불가변 컴포넌트와 가변컴포넌트는 분리하며 가변컴포넌트는 트랜잭션 메모리(책참고)를 통해 동시성문제로부터 가변변수를 보호할 수 있다. 이벤트 소싱(Event Sourcing) 상태가아닌 트랜잭션을 저장하자는 전략을 말한다. 결과적으로 애플리케이션은 동시성문제를 유발하는 CRUD가 아닌 CR만 수행하게되므로 동시성문제가 발생하지않는다. 저장공간과 처리능력이 충분하다면 이 전략..

4장 구조적 프로그래밍

2020. 2. 17.

구조적 프로그래밍 goto문이 난무하는 순차프로그래밍 방식에서는 합리적 증명할 때 필수적인 기법인 분할 정복 접근법을 사용할 수 없다. 그러나 if/then/else와 do/while과 같은 분기와 반복이라는 제어 구조만을 사용한다면 모듈을 더 세분화하는것이 가능하다. 즉, 모든 프로그램은 순차, 분기, 반복이라는 세가지 구조만으로 표현(구조적 프로그래밍)할 수 있으며, 구조적 프로그래밍은 모듈을 기능적으로 분해할 수 있다. (Ex. 거대한 문제 기술서를 받더라도 문제를 고수준의 기능들로 분해, 저수준의 함수들로 분해, 분해과정을 끝없이 반복이 가능함.) 결론 제어흐름의 직접적인 전환에 대해 규칙을 부과하며 goto문을 앗아간다.
05 책임 할당하기

05 책임 할당하기

2020. 2. 16.

들어가며 데이터가 아닌 책임에 초점을 맞추면 데이터 중심 설계로 인해 발생되는 문제를 해결할 수 있다. 그러나 책임 주도 설계시 어떤 객체에게 어떤 책임을 할당할지 결정하기 쉽지않다. GRASP 패턴은 책임할당의 어려움을 해결하기 위한 답을 제시해 줄 것이다. 01 책임 주도 설계를 향해 책임 중심 설계로 전환되기 위해서는 다음 두 가지 원칙을 따라야 한다. - 데이터보다 행동을 먼저 결정하라. - 협력이라는 문맥 안에서 책임을 결정하라. 데이터 보다 행동을 먼저 결정하라 클라이언트 관점에서 객체가 수행하는 행동이란 곧 객체의 책임을 의미한다. 그러므로 객체는 데이터가 아닌 외부에 제공하는 행동이 중요하다. 책임 중심 설계에서는 객체가 수행해야하는 책임을 결정 한 후 책임 수행에 필요한 데이터를 파악하는..
04 설계 품질과 트레이드 오프

04 설계 품질과 트레이드 오프

2020. 2. 10.

들어가며 객체지향 설계의 핵심은 역할, 책임, 협력이다. 협력 - 애플리케이션의 기능을 구현하기 위해 메세지를 주고받는 객체들 사이의 상호작용. 책임 - 객체가 다른 객체와 협력하기 위해 수행하는 행동. 역할 - 대체 가능한 책임의 집합. 역할, 책임, 협력중에서 가장 중요한 것은 책임이다. 객체지향 설계란? 객체에게 올바른 책임을 할당하며, 낮은 결합도와 높은 응집도를 가진 구조를 창조하는 활동이다. 결합도와 응집도를 합리적으로 유지할 수 있는 원칙이 있다. 객체의 상태가 아닌 행동에 초첨을 맞추는것이다. 객체를 단순 데이터 집합으로 바라보는 시각은 객체의 내부 구현을 퍼블릭 인터페이스에 노출시켜 설계가 변경에 취약해지기 때문이다. 행동 즉, 책임 주도 설계가 데이터 중심 설계보다 어떤 면이 좋은지 살..
03 역할, 책임, 협력

03 역할, 책임, 협력

2020. 2. 2.

01 협력 영화 예매 시스템 돌아보기 영화 예매라는 기능을 완성하기위해 협력하는 객채들의 상호작용을 표한한 그림이다. 객체들이 애플리케이션의 기능을 구현하기 위해 수행하는 상호작용을 협력, 객체가 협력에 참여하기 위해 수행하는 로직은 책임이라고 부른다. 즉, 객체들이 협력 안에서 수행하는 책임들이 모여 객체가 수행하는 역할을 구성한다. 협력 객체사이의 협력을 위해 사용할 수 있는 유일한 커뮤니케이션 수단은 메세지 전송(message sending)이다. 객체는 다른 객체의 상세한 내부 구현에 직접 접근할 수 없기 때문에 오직 메세지 전송을 통해서만 자신의 요청을 전달할 수 있다. 메세지를 수시한 객체는 메서드를 실행해 요청에 응답한다. 객체가 메세지를 처리할 방법을 스스로 선택한다는 점이 중요하다, 이것..