도니의 iOS 프로그래밍 세상

데이터 중심의 문제는 객체에 상태에 초점을 맞추기 때문에, 변경등에 취약함따라서 책임에 초점을 맞추도록 해야하지만, 실제로 어떤 객체에 책임을 할당하지 정하는게 쉽지 않음→ 올바른 책임 할당을 위해 Grasp 패턴을 적용1. 책임 주도 설계를 향해데이터 중심에서 책임 주도 설계로의 전환을 위한 두가지 원칙데이터 보다 행동을 먼저 결정협력이라는 문맥 안에서 책임을 결정데이터 보단 행동을 먼저 결정객체에서 중요한 건 데이터가 아닌, 외부에 제공하는 행동(이것이 곧 “책임”)객체가 수행할 책임을 먼저 결정하고, 필요한 데이터가 무엇인지 결정협력이라는 문맥 안에서 책임을 결정책임의 품질은 협력에 적합한 정도로 결정메세지 전송 클라이언트 의도에 적합한 책임을 할당메세지 수신자에 대한 가정을 하지 않기 때문에, 수..

훌륭한 객체 지향 설계를 위해선 비용 내에서 변경을 수용할 수 있는 구조를 만드는 것유연한 구조를 위해 응집도가 높고 결합도가 낮으며, 객체의 상태가 아닌 행동 더 나아가 책임에 초점을 맞춤1. 설계 트레이드 오프객체 설계의 장단점을 비교하기 위한 3가지 척도인 캡슐화, 응집도, 결합도캡슐화객체를 사용하여 변경 가능성이 높은 부분을 숨기고, 외부에 상대적으로 안정적인 부분을 공개하여 변경의 여파를 통제상태는 변경 가능성이 높은 부분이며, 상대적으로 안정적인 부분은 객체의 책임, 메시지핵심은 변경 가능성이 높은 부분을 객체 내부로 숨기는 추상화 기법으로서, 내부 구현이 변하더라도 변화의 여파를 통제할 수 있음응집도와 결합도응집도(변경의 관점) 변경 발생시 모듈 내부에서 발생하는 변경의 정도하나의 변경 수용..

상속의 목적은 타입 계층을 구조화(not 코드 재사용!)타입 계층은 다형성의 기반을 제공함Chap01. 다형성오버로딩 다형성함수의 이름은 동일하나, 서로 다른 파라미터class Bank { func withdraw(won: WON) func withdraw(dollar: Dollar) } 2. 강제 다형성언어가 지원하는 자동 타입 변환 및 사용자 직접 타입변환을 통해 사용하는 방식ex. + 정수일떈 값을 더함, 문자열은 append 시킴3. 포함 다형성메시지는 동일하고, 수신 객체 타입에 따라 실제 수행되는 행동이 달라지는 것subtype 다형성Chap02. 상속의 양면성객체지향 아이디어의 근거는 데이터와 행동을 객체라는 하나의 실행 단위로 통합하는 것상속은 결국 부모의 데이터와 행동이 자식에 포함되..

상속과 합성은 가장 많이 사용되는 코드 재사용 기법상속은 클래스 사이에 정적인 관계, 합성은 동적인 관계상속은 부모 클래스에 구현에 의존하기 때문에 자식과 부모간의 강한 결합도를 가짐(부모 클래스이 구현에 의존하지 않는다면 어떻게 될까? → 부모 inteface에 의존한 상속을 설계한다면 더욱 유연해지지 않을까?)합성은 퍼블릭 인터페이스에 의존하기 때문에 객체 내부 구현 변경에 따른 영향이 최소화되어 안정적임→ 이로인해, 합성이 상속에 비해 유연한 설계가 가능함(구현이 아닌, 인터페이스에 의존하기 때문)1. 상속으로 인한 조합의 폭발적인 증가상속이 가진 부모 자식간의 결합도는 코드 수정간 더 많은 작업량을 요구함합성은 상속과 같이 중복을 제거하면서도 보다 간단하게 처리가 가능함새로운 클래스 생성기능 A,..

객체 지향의 장점중 하나인 상속을 통한 코드 재사용합성을 통해서도 코드 재사용 가능Chap01. 상속과 중복 코드중복 코드란 스펙이 변경될 때 함께 수정되어야 하는 코드중복을 제거해야 하는 이유는, 추후 코드 수정시에 몇배의 노력이 발생 하기 때문(계속된 중복 코드는 제곱배로 커져, 버그 발생 가능성이 높아짐)따라서, 신뢰할 수 있는 소프트웨어를 위해선 DRY 원칙(Don’t Repeat Yourself를 지켜야 함중복 제거 방법타입코드중복 코드를 제거를 위해, 클래스로 만들어 중복 코드를 이관시킴타입코드는 낮은 응집도와 높은 결합도 문제 발생(특정 타입에 종속되어 있기 때문)상속상속을 통해 기반 클래스의 로직을 재활용상속을 염두하지 않는 클래스를 상속하는 것은 코드 수정 및 이해를 어렵게 함상속은 부모..

유연하게 대응할 수 있는 설계를 만드는 원칙 중 하나인 OCP(Open-Closed Principle)에 대해 알아보자.Chap01. OCP소프트웨어 개체(클래스, 모듈, 함수)는 확장에 열려 있고, 수정에 닫혀 있어야 한다.확장에 대해 열려있다: 애플리케이션 요구 사항 변경시, 변경에 맞게 새로운 동작을 추가해서 기능을 확장할 수 있다.수정에 닫혀 있다: 기존 “코드”를 수정하지 않고, 애플리케이션 동작을 추가하거나 변경할 수 있다.이는 결국 추상화를 의미한다. 추상화 과정을 거쳐 문맥이 바뀌더라도 변하지 않는 부분만 남고, 변하는 부분은 생략된다.런타임 때 의존성이 변경되도록 구현하면 된다.결국, 문맥이 바뀌더라도 변하지 않는 부분을 추상화하고, 변하는 부분이 수정할 수 있도록 하는 것이 핵심ex. ..

협력객체는 자율적, 협력적 존재자율적인 존재가 되기 위해캡슐화를 통해 side-effect를 최소화다른 객체와의 협력을 통해, 특정 행동을 위임할 수 있어야 함협력을 통해 객체의 문맥이 결정Movie라는 객체는 일반적인 의미가 아닌, 협력 내에서 의미가 결정됨→ 개인적 의견팀 프로젝트시 가장 중요한 건, 팀원들간의 객체 이해도객체가 일반적인 의미를 많이 갖고 있으면 있을수록, 이해가 빨라짐따라서, 직관적 이해를 위해 일반적인 의미를 웬만하면 갖는게 더 좋음책임객체가 수행하는 행동을 의미하는것, 아는것으로 나뉨책임 할당특정 동작 수행을 위해, 어떤 객채에게 책임을 할당할 것인지가 중요필요한 정보를 가장 많이 아는 객체에게 할당해주어야 함메세지 객체 결정객체의 행동을 위한 메세지 결정 → 그 메시지에 적합한..

1. 영화 예매 시스템결국 프로그래밍에서 중요한 건 용어를 알맞게 정의하는 것책에서 영화 예매 프로그램을 구현하기 전, 영화와 상영의 정의를 나누고 있음우리가 일반적으로 예매하는 건, 영화가 아닌 상영(특정 시간에 상영되는 영화)영화는 단순히 실제 영화 정보를 담고 있음이게 실제 세계와 맞는지 중요하지 않고, 해당 프로그램을 만들 때 이렇게 정의한 게 중요2. 객체지향 프로그래밍을 향해객체, 클래스, 협력객체 지향 프로그래밍의 본질은 객체(not class)객체 지향에 핵심 두가지어떤 객체가 필요한가?이를통해, 해당 객체에 필요한 state(속성)과 행동(behavior)를 정의객체는 협력하는 공동체의 일원(not 독립적 존재)객체를 협력의 대상으로 봄으로써, 유연하고 확장 가능하게 만듦클래스, 도메인도..

들어가기 전패러다임(paradigm)은 특정 학문, 분야, 또는 시스템에서 특정한 시각이나 접근 방식그중 프로그래밍 패러다임은, 프로그래밍에서 쓰일수 있는 유용한 방법론들의 모음이라고 생각함객체지향 패러다임, 함수형 패러다임, 절차형 패러다임등 다양한 패러다임을 배우고 이를 적용하는게 가장 좋은듯실제로 객체지향 패러다임에, 함수형을 적절하게 섞어 더욱 가독성 있고 이해하기 쉬운 코드를 짤수 있는 것 처럼!티켓 판매 어플리케이션 구현기존 설계 방식커플링이 굉장히 심한 구조Theater(클래스)외에 다른 세가지 클래스가 데이터만 갖고 있는 형태절차 지향적 방식이라는 말은 이해하지 못했으나, 결국 클래스의 ㅛ책임이 한쪽에 집중된 구조캡슐화없이 Theater가 클래스의 모든 데이터 구조 및 함수를 알고 있는 구..

디자인 패턴 및 프레임 워크디자인 패턴S/W 설계에서 반복되는 문제에 대해 적용할 수 있는 해결 방법프레임워크설계와 코드를 함께 재사용하기 위한 것공통점협력을 일관성 있게 제공하는 게 목적차이점디자인 패턴: 설계의 묶음프레임 워크: 일관성 있는 협력을 제공하는 확장 가능한 코드01. 디자인 패턴과 설계 재사용패턴의 핵심은 정의가 아닌 뉘앙스를 이해하는 것패턴의 핵심적 특징패턴은 반복적 문제와 해법의 pair로 구성패턴을 사용하여 다른 사람과 의사소통이 간단해짐패턴은 실무에서 “발견된 것”패턴은 다양한 context에서 사용되는 유용한 idea패턴 분류아키텍쳐 패턴s/w 전체 구조 결정에 사용정의된 서브 시스템 제공, 각 서브 시스템의 책임 정의, 서브 시스템 관계간 규칙 및 가이드라인 포함디자인 패턴특정..