객체지향

3. 객체지향 패러다임의 핵심, 역할 책임 협력 | 오브젝트 3장

객체지향 패러다임의 핵심은 역할, 책임, 협력이다. 클래스, 상속, 지연 바인딩은 구현 매커니즘일 뿐이다. 객체지향의 본질은 협력하는 객체들의 공동체를 창조하는 것이다. 1. 협력 객체지향 원칙을 따르는 애플리케이션의 제어 흐름은 다양한 객체들 사이에 균형 있게 분배된다. 다양한 객체들이 영화 예매라는 기능을 구현하기 위해 메시지를 주고받으면서 상호작용한다. 협력: 객체들이 기능을 구현하기 위해 수행하는 상호작용 책임: 객체가 협력에 참여하기 위해 수행하는 로직 역할: 객체가 협력 안에서 수행하는 책임들 메시지 전송은 협력을 위해 사용할 수 있는 유일한 커뮤니케이션 수단이다. 메시지를 수신한 객체는 메서드를 실행해 요청에 응답한다. 객체는 메시지를 처리할 방법을 스스로 선택한다. Screening은 Mo..

2. 코드로 이해하는 객체지향 프로그래밍 | 오브젝트 2장

이번 장은 뒤에서 다룰 다양한 주제들을 얕게 살펴보는 장이다. 온라인 영화 예매 시스템 예제를 다뤄보자. 1. 영화 예매 시스템 요구사항 영화 (movie) : 영화가 가지고 있는 기본적인 정보 상영 (screening) : 관객들이 영화를 관람하는 사건 할인 조건 (discount condition) : 할인 여부를 결정 순서 조건: 상영 순번을 이용해 할인 여부를 결정 (ex. 매일 10번째로 상영되는 영화에 대해 할인) 기간 조건: 상영 시작 시간을 이용해 할인 여부 결정 (ex. 매주 월요일 오전 10시부터 오후 1시 사이에 상용되는 영화에 대해 할인) 할인 정책 (discount policy) : 할인 요금을 결정 금액 할인 정책: 일정 금액을 할인 비율 할인 정책: 일정 비율의 요금을 할인 영..

1. 코드로 이해하는 객체와 설계 | 오브젝트 1장

프로그래밍 패러다임은 특정 시대의 어느 성숙한 개발자 공동체에 의해 수용된 프로그래밍 방법과 문제 해결 방법, 프로그래밍 스타일이다. 이 책은 객체지향 패러다임에 관한 책이다. 이 책의 패러다임 전환이란 절차형 패러다임에서 객체지향 패러다임으로의 변화이다. C: 절차형 패러다임 Java: 객체지향 패러다임 LISP: 함수형 패러다임 PROLOG: 논리형 패러다임 각 패러다임과 패러다임을 채용하는 언어는 특정한 종류의 문제를 해결하는 데 필요한 일련의 개념들을 지원한다. 프로그래밍 패러다임에서는 두 패러다임이 공존할 수 있다. 이러한 언어를 다중패러다임 언어라 한다. C++: 절차형 패러다임 + 객체지향 패러다임 Scala: 함수형 패러다임 + 객체지향 패러다임 프로그래밍 패러다임은 혁명적이 아니라 발전적..

8. 추상화 기법 | 객체지향의 사실과 오해 8장 (END)

추상화? 추상화는 도메인의 복잡성을 단순화하고 직관적인 멘탈 모델을 만드는 데 사용할 수 있는 가장 기본적인 인지 수단이다. 분류와 인스턴스화 일반화와 특수화 집합과 분해 객체지향의 가장 큰 장점은 동일한 추상화 기법을 프로그램의 분석, 설계, 구현 단계에 걸쳐 일관성 있게 적용할 수 있다는 점이다. 분류와 인스턴스화 개념과 범주 개념: 속성과 행위가 유사한 객체에 공통적으로 적용되는 관념이나 아이디어 뷴류(범주로 묶는 것): 객체들의 특정 집합에 공통의 개념을 적용하는 것 (ex. 자동자 범주에 적용되는 개념: 바퀴를 이용해 사람을 운반하는 운송수단) 분류를 통해 개별 현상(객체)을 하나의 개념(타입)으로 다룰 수 있다. 즉, 분류는 객체와 타입 간의 관계를 나타낸 것이다. 분류의 역은 타입에 해당하는..

7. 객체지향의 개념, 명세, 구현 | 객체지향의 사실과 오해 7장

마틴 파울러는 객체지향 설계 안에 존재하는 세 가지 상호 연관된 세 가지 관점을 설명했다. 1. 개념 관점 개념 관점에서 설계는 도메인 안에 존재하는 개념과 개념들 사이의 관계를 표현한다. 도메인은 특정 분야/주제이며, 소프트웨어는 도메인 내 문제를 해결하기 위해 개발된다. (ex. 커피 전문점, 재판장 등) 개념 관점은 사용자가 도메인을 바라보는 관점을 반영하기 때문에, 실제 도메인의 규칙과 제약을 최대한 유사하게 반영하는 것이 핵심이다. 2. 명세 관점 사용자의 영역인 도메인을 벗어나 개발자의 영역인 소프트웨어로 초점이 옮겨진다. 도메인의 개념이 아닌 실제 소프트웨어 내 객체들의 책임에 초점을 맞추어 객체의 인터페이스를 바라보게 된다. 프로그래머는 객체가 협력을 위해 '무엇'을 할 수 있는가에 초점을..

6. 다이어그램으로 보는 도메인 모델 | 객체지향의 사실과 오해 6장

길을 지나가는 사람에게 물어보는 방법은 기능적이고 해결책 지향적인 접근법, 길을 지도를 보고 찾아가는 방법은 구조적이고 문제 지향적인 접근법이다. 지도는 구체적인 기능이 아닌 구조를 제공하며, 다양한 목적을 위해 재사용될 수 있다. 지도는 기능에 비해 상대적으로 잘 변하지 않는 안정적인 지형 정보를 기반으로 하기 때문에, 요구사항이 변함에도 수용할 수 있다. 즉, 기능이 아니라 구조를 기반으로 모델을 구축하는 편이 좀 더 범용적이고 이해하기 쉬우며 변경에 안정적이다. 객체지향은 안정적인 구조를 기반으로 시스템을 구조화한다. 자주 변경되는 기능이 아니라 안정적인 구조를 따라 역할, 책임, 협력을 구성하라. 모든 소프트웨어 제품의 설계에는 기능과 구조의 측면이 존재하며 조화를 이루도록 해야 한다. 기능 측면..

5. 코드로 보는 객체의 자율적인 책임 | 객체지향의 사실과 오해 5장

1. 협력에 참여하는 객체의 책임이 자율적이어야 한다. 자율적인 책임이 설계의 품질을 좌우한다 객체지향 공동체를 구성하는 기본 단위는 '자율적'인 객체다. 자율적인 객체란 스스로 정한 원칙에 따라 판단하고 스스로의 의지를 기반으로 행동하는 객체다. 객체가 어떤 행동을 하는 유일한 이유는 다른 객체로 부터 요청을 수신했기 때문이다. 요청을 처리하기 위해 객체가 수행하는 행동이 책임이다. 즉 자율적인 객체란 스스로의 의지와 판단에 따라 각자 맡은 책임을 수행하는 객체다. 적절한 책임이 자율적인 객체를 낳고, 자율적인 객체들이 모여 유연하고 단순한 협력을 낳는다. 객체에게 할당되는 책임은 자율적이어야 한다. class King implements Judge { listenToTestimony(trialHelp..

4. 코드로 보는 객체의 협력 관계 | 객체지향의 사실과 오해 4장

최후통첩 게임은 인간을 바라보는 두 가지 관점의 충돌을 잘 설명한다. 인간이 가지고 있는 본연의 특성이라는 관점에서 인간은 이기적으로 합리적인 존재다. 그러나 타인과 관계를 맺는 과정 속에서 인간은 본연의 특성을 배제하고 자신의 이익을 최소화하는 불합리한 선택을 하게 된다. 결론적으로 인간이 어떤 본질적인 특성을 지니고 있느냐가 아니라 어떤 상황에 처해 있느냐가 인간의 행동을 결정한다. 즉, 각 개인이 처해 있는 정황 또는 문맥이 인간의 행동 방식을 결정한다. 객체의 세계에서도 협렵이라는 컨텍스트가 객체의 행동 방식을 결정한다. 객별적인 객체의 행동이나 상태가 아니라 객체들 간의 협력에 집중하자. 1. 협력 협력의 본질은 요청과 응답으로 연결되는 네트워크다. 협력은 한 객체가 다른 객체에게 도움을 요청할..