모-코드

14장 일관성 있는 협력유사한 요구사항을 반복적으로 추가하거나 수정할 때 각 협력이 서로 다른 패턴을 따르면 전체적인 설계의 일관성이 무너진다재사용은 공짜로 얻어지지 않는다. 객체들의 협력방식을 일관성 있게 해야한다 -> 코드가 읽기 쉬워진다유사한 기능을 구현하기 위해 유사한 협력 패턴을 사용하라정신적 부담이 크게 줄어든다1. 핸드폰 과금 시스템 변경하기기본정책을 확장하여 4가지로 한다고정 요금 방식 / 시간대별 방식 / 요일별 방식 / 구간별 방식고정요금 방식: 일정 시간 단위로 동일한 요금을 부과하는 방식입니다. (예: 10초당 18원)시간대별 방식: 하루 24시간을 특정한 시간 구간으로 나눈 후 각 구간별로 서로 다른 요금을 부과하는 방식입니다. 만약 통화가 여러 날에 걸쳐서 이뤄진다면, 통화 구간..

13장: 상속의 본질 - 타입 계층과 다형성상속의 진정한 목적이 코드 재사용이 아니라 '타입 계층'을 구축하는 것1. 상속의 두 얼굴: 서브클래싱 vs 서브타이핑책에서는 상속을 사용하는 용도를 엄격하게 두 가지로 구분한다.서브클래싱 (Subclassing - 구현 상속)단순히 부모 클래스의 코드를 재사용하기 위해 상속을 사용하는 경우를 말한다.이는 부모와 자식 간의 결합도를 높여 변경에 취약한 설계를 만든다.10장에서 비판했던 방식이 바로 이 서브클래싱이다.서브타이핑 (Subtyping - 인터페이스 상속)부모 클래스가 정의한 타입 계층을 물려받아 다형적으로 동작하기 위해 상속을 사용하는 것을 의미한다.객체지향 설계에서 상속을 사용하는 유일하고 올바른 목적이다. 2. 대체 가능성을 결정하는 기준: 리스코..

개인 이해 정리Dry 원칙 해결 방법 ->상속(is-a) : 코드 재사용 (컴파일 타임)합성(has-a) : 퍼블릭 인터페이스 재사용 (런 타임)두개는 코드 재사용이라는 동일한 목적을 제외하면 구현 방법부터 변경 다루는 방법까지 모든 면에서 차이가 있다.1. 상속을 합성으로 변경하기 (상속 으로부터의 안정성 향상)상속 문제불필요한 인터페이스 상속 문제 : 자식 클래스에게는 부적합한 부모 클래스의 오퍼레이션이 상속메서드 오버라이딩 부작용 문제 : 자식 클래스가 부모 클래스 메서드 호출방법에 영향 받는 문제부모 클래스와 자식 클래스의 동시 수정 문제 : 부모 클래스 변경 시 자식 클래스도 함께 변경하는 문제불필요한 인터페이스 상속문제과제 1. 상속코드를 합성으로 변경하기 : 참고합성으로 변경에 불안정한 코드..

개요객체지향 프로그램 장점은 코드 재사용에 용이전통적인 프로그래밍의 재사용 방법은 복사한 후 수정하기재사용 관점에서 상속이란 : 클래스 안에 정의된 인스턴스 변수와 메서드를 자동으로 새로운 클래스에 추가하는 구현 기법합성 : '새로운 클래스의 인스턴스 안'에 '기존 클래스의 인스턴스'를 포함시키는 방법1. 상속과 중복코드중복코드는 사람들의 마음속에 의심과 불신의 씨앗을 뿌린다.DRY 원칙중복코드는 변경을 방해한다. 이것이 중복코드를 제거해야하는 이유프로그램의 본직은 비즈니스 지식을 코드로 변경인데, 지식은 항상 변한다 -> 코드도 변한다중복코드의 가장큰 문제는 코드 수정에 노력을 몇배로 증가시킨다.모든코드 수정 + 개별적 테스트로 동일한 결과확인 필요중복 여부 판단 기준은 '변경'요구 사항 변경 시 두 ..

1. 개방 폐쇄 원칙개방 폐쇄 원칙의 핵심은 '추상화에 의존'이다 (런타임 의존성으로 대체)문맥에 따라 변하는 부분은 생략된다생략된 부분에서 확장의 여지가 생긴다.변경에 의한 파급효과 최소화 위해서는 변하는것과 변하지 않는것이 무엇인지 이해하고 추상화의 목적으로 삼아야한다2. 생성 사용 분리Movie 클래스 내부에서 AmointDiscoutPolicy 같은 구체 클래스의 인스턴스를 생성해서는 안된다개방 폐쇄 원칙 위반이것은 동일 클래스 내 객체 생성과 사용이라는 '이질적인' 목적을 가진 코드가 공존하는것이 문제다결국 '생성과 사용을 분리'해야한다객체 생성은 클라이언트로 옮긴다.클라이언트의 컨텍스트에 대한 지식으로 옮기므로, 특정 클라이언트에 결합되지 않고 독립적이다Factory 추가하기하지만 client..

6장 메시지와 인터페이스애플리케이션은 클래스로 구성되지만, 메시지를 통해 정의된다.1. 협력과 메시지클라이언트 - 서버 모델클라이언트 - 서버 모델은 두 객체 사이의 협력관계 설명하기 위해 사용하는 메타포이다.객체가 독립적으로 수행할 수있는 것보다 더 큰 책임을 수행하기위해서는 다른 객체와 협력해야한다메시지 전송자와 수신자는 서로에 대한 상세한 정보를 모른 채 단지 메시지라는 얇은 끊으로 연결된다.수신가능한 메시지가 객체의 퍼블릭 인터페이스와 오퍼레이션을 결정한다2. 인터페이스 설계와 품질좋은 인터페이스는 최소한의 인터페이스(꼭 필요한 오퍼레이션만)와 추상적인 인터페이스(무엇을 하는지 표현 -> 메시지를 먼저 선택 / 메시지가 객체를 선택) 조건을 만족해야한다1. 디미터 법칙객체의 내부 구조에 대한 결합..

들어가며앞장에서 책임에 맞춰 설계 할 때 가장 큰 어려움은 어떤 객체에게 어떤 책임을 할당할 것인지 결정하기가 쉽지않다.책임할당 과정은 트레이드 오프 활동이다.같은 문제에 대한 다양한 책임 할당 방법이 존재한다 그 최선은 상황과 문맥에 따라 달리 판단된다1. 책임주도 설계를 향해데이터 중심 설계에서 책임 주도 설계로 전환은 2가지 원칙을 따라야한다데이터 보다 행동을 먼저 결정하라협력이라는 문맥 안에서 결정하라1. 데이터 보다 행동을 먼저 결정하라객체에게 중요한 것은 데이터가 아니라 외부에 제공하는 행동이다.클라이언트 관점에서 객체가 수행하는 행동이란 곧 객체의 책임이다.질문의 순서를 바꾸는 것이 중요하다이 객체게 수행해야하는 책임은 무엇인가 -> 이 책임을 수행해야하는 데이터가 무엇인가즉 책임을 먼저 결..

지난 내용 정리OOP의 핵심은 역할, 책임, 협력이다협력 : 애플리케이션 기능 구현하기 위해 메시지를 주고 받는 객체들의 상호작용책임 : 객체가 다른 객체와 협력하기 위해 수행하는 행동역할 : 대체 가능한 책임1. 데이터 중심의 예매시스템책임이 무엇인가 VS 데이터가 무엇인가?데이터 중심 관점데이터 조작을 위한 오퍼레이션 정의객체의 상태에 초점을 맞춰 구현객체는 독립된 데이터 덩어리책임 중심 관점다른 객체가 요청할 수있는 오퍼레이션을 위해 필요한 상태 보관객체의 행동에 초점객체는 협력하는 공동체의 일원채택둘중 책임을 택한다. 그 이유는 '변경'이다.데이터 중심 설계객체 내부에 저장되어있는 데이터를 기반으로 시스템을 분할하는 방법이다.이 경우 멤버 변수간 배타적 사용 형태와 분기 처리 방식으로 진행된다2...

관련 실습 PR 링크 : https://github.com/object-nextstep21/object/pull/12장 객체지향 프로그래밍OOP 를 향해협력, 객체, 클래스OOP 작성할 때 클래스를 결정하고 클래스에 어떤 속성과 메서드 고민 X객체에 초점을 맞출 때 가능어떤 객체인지!도메인사용자의 문제를 해결하기 위해 사용자가 프로그램을 사용하는 분야자율적인 객체객체는 상태(state)와 행동(behavior)을 함께 가지는 복합적인 존재객체가 스스로 판단하고 행동하는 자율적인 존재이렇게 데이터와 기능을 묶는것을 캡슐화라고 한다 이를 위해 접근 제어를 이용한다객체의 두 부분 (seperation of interface and implementation)public interface외부에서 접근가능하다메시..

들어가며글래스는 스포트웨어 크리에이티비티2.0 에서 이론보다 실무가 먼저라고 한다. 다른 분야에 비해 역사가 짧기 때문이다.특히 소프트웨어 설계와 소프트웨어 유지보수가 실무가 앞서있다.소프트웨어 생명 주기 동안 유지보수가 차지하는 비중을 감안할 때 이론은 매우 실망스럽다. 결국 실무에 초점을 맞추는게 중요하다.추상적인 개념과 이론은 훌륭한 코드를 작성하는데 필요한 도구이다.01 티켓 판매 애플리케이션 구현하기1장의 첫 구현의 로직은 간단하고 예상대로 동작한다. 하지만 몇가지 문제점이 있다.02 무엇이 문제인가로버트 마틴은 클린 소프트웨어에서 소프트웨어 모듈이 가져야하는 3가지 기능을 설명한다제대로 동작해야한다변경을 위해 존재해야한다 어렵다면 개선해야한다코드를 읽는 사람과 의사소통 하는것이다. 특별한 훈련..