도니의 iOS 프로그래밍 세상

디자인 패턴s/w 설계에서 반복적으로 발생하는 문제에 대해 적용할 수 있는 해결 방법(언어에 독립적)프레임 워크설계와 코드를 함께 재사용하기 위한 것1. 디자인 패턴과 설계 재사용소프트웨어 패턴실무 컨텍스트에서 유용하게 사용해 왔고 다른 실무 컨텍스트에서 유용할 것이라고 예상되는 아이디어패턴은 경험을 통해 축적된 실무 지식을 효과적으로 요약하고 전달함(커뮤니케이션 비용 감소)패턴과 책임-주도 설계객체 지향 설계는 올바른 책임을 올바른 객체에게 할당하고 유연한 협력 관계를 구축하는 일패턴은 공통으로 사용할 수 있는 역할, 책임, 협력의 템플릿중요한 것은 패턴의 세부 내용이 아닌 특정한 상황에서 패턴을 따르면 설계를 쉽고 빠르게 떠올릴 수 있다는 사실캡슐화와 디자인 패턴알고리즘 변경을 캡슐화할 때 사용하는 ..

객체는 협력을 위해 존재하며, 협력 구조가 다를경우 코드 이해도가 낮아지고 버그의 위험성이 높아짐설계 재사용을 위해서 객체들의 협력 방식을 일관성 있게 만들어야 함1. 설계에 일관성 부여하기변하는 개념을 변하지 않는 개념으로부터 분리변하는 개념을 캡슐화캡슐화 다시 살펴보기캡슐화는 데이터의 은닉만을 의미하는 것이 아닌, 변할수 있는 모든 개념을 감추는 것협력을 일관성 있게 만들기 위한 두가지 캡슐화의 방법서브 타입 캡슐화와 객체 캡슐화서브 타입 캡슐화:컴파일 타임 때는 슈퍼 타입만 알고 있더라도, 실행 시점에 자식 클래스 인스턴스와 협력함. 서브서브 타입의 종류를 캡슐화객체 캡슐화특정 클래스는 다른 클래스 타입을 private으로 인스턴스 변수로 갖고 있음이로 인해 객체와 객체 사이에 관계가 캡슐화 되어 ..

상속의 두가지 용도타입 계층 구현코드 재사용1. 타입객체지향 패러다임 관점의 타입개념 관점에서 타입이란 공통의 특징을 공유하는 대상들의 분류프로그래밍 언어 관점에서 타입이란 동일한 오퍼레이션을 적용할 수 있는 인스턴스의 집합객체지향 관점에서 객체가 수신할 수 있는 메시지의 집합은 퍼블릭 인터페이스결국 같은 퍼블릭 인터페이스를 제공 한다면, 객체 지향 관점에서는 동일한 타입2. 서브클래싱과 서브타이핑언제 상속을 사용해야 하는가?is-a 관계를 만족할 때클라이언트 입장에서 부모 클래스 타입을 자식 클래스로 사용해도 무방할 때is-a 관계, 행동 호환성is-a 관계에서 만족시켜야 할 것은 직관이 아닌, 클라이언트 입장에서 대체 가능성클라이언트 입장에서 is-a 관계를 만족시킨다면 타입 계층으로 설정할 수 있음..

상속의 타입 계층을 구조화 하기 위해 사용하는 것이지 코드 재사용이 아님1. 다형성서브타입 다형성은 메세지가 동일하더라도 수신한 객체의 타입에 따라 실제 수행되는 행동이 달라지는 것우리가 부르는 다형성은 일반적으로 서브타입 다형성 의미상속은 다형성을 위한 서브타입 계층을 구축하여, 런타임에 상속 계층 안에서 적절한 메서드 선택을 가능하게 함2. 상속의 양면성객체 지향 패러다임의 아이디어는 객체라고 불리우는 실행 단위 안으로 데이터와 행동을 통합하는 것데이터와 행동 관점에서만 바라본다면, 상속이란 부모 클래스의 데이터와 행동을 자식 클래스와 자동적으로 공유할 수 있는 메카니즘진정한 목적은 타입 계층을 구조화 하는 것3. 업캐스팅과 동적 바인딩같은 메시지, 다른 결과업캐스팅이란 부모 클래스 타입으로 선언된 ..

합성은 내부 객체의 구현이 아닌, 퍼블릭 인터페이스에 의존하기 때문에 안정적인 코드를 얻을 수 있음상속은 is-a 관계, 합성은 has-a 관계합성은 실행 시점에 동적으로 변경할 수 있기에 더욱 유연한 설계를 얻을 수 있음1. 상속으로 인한 조합의 폭발적 증가작은 기능을 조합해서 더 큰 기능을 수행하는 객체를 만들어야 할 때, 상속은 두가지 문제점을 발생하나의 기능을 추가하거나 수정하기 위해 불필요하게 많은 수의 클래스 추가 및 수정 필요모든 조합의 클래스를 만들어야 하기 때문ex.) A기능을 수행하는 객체와, B 기능을 수행하는 객체를 합성하여 C 객체를 만들때합성은 A + B의 클래스만 필요한 반면, 상속은 A*B의 객체가 필요하게 됨단일 상속만 지원하는 언어에서는 상속으로 인해 오히려 중복 코드 양..

객체 지향 코드 재사용의 관점에서 상속이란 클래스 안에 정의된 인스턴스 변수와 메서드를 새로운 클래스에 추가하는 기법코드 재사용의 동기는 중복 코드 제거1. 상속과 중복 코드DRY 원칙중복 코드 제거의 가장 큰 이유는 변경을 방해한다는 것비즈니스 로직의 변화로 코드를 변경할 때, 중복 코드는 수정하는데 많은 노력이 발생중복 코드를 발견하여도, 개별적 테스트 후 동일한 결과를 체크해야 함중복의 기준은 변경,요구 사항 변경시 함께 수정되는 것상속을 이용한 중복 코드 제거이미 존재하는 클래스와 유사 클래스 필요시 코드를 복사하지 않고 상속을 이용상속을 염두하지 않는 클래스를 상속을 통해 재사용하는 것은 쉽지 않음상속은 부모 클래스와 자식 클래스 사이의 강한 결합을 만들어 코드 수정을 어렵게 만듦2. 취약한 기..

1. 개방-폐쇄 원칙(OCP)OCPs/w는 확장에 열려있고, 수정에 닫혀있어야 함이는 기존 코드 수정 없이 동작이 추가되고 변경되어야 한다는 뜻추상화가 핵심이다추상화를 통해 핵심적인 부분만 의존하도록 해, 문맥이 변하더라도 바뀌지 않음문맥에 따라 적합한 기능을 구체화 하면 된다.2. 생성 사용 분리객체가 추상화만 의존하기 위해선, 추상화의 구체 클래스를 객체 내부에서 생성해서는 안됨구체 클래스를 객체가 직접 생성한다면, 기능(구체 클래스)을 변경할 때 기존 코드의 변경이 발생할 수 밖에 없고, 이는 OCP 위반그리하여 유연한 설계를 위해서는 생성과 사용이라는 책임을 두 객체로 분리 한다.Factory 추가하기생성과 사용 분리를 위해 객체 생성에 특화된 Factory를 사용3. 의존성 주입사용하는 객체가 ..

잘 설계된 객체 지향 App은 작고 응집도 높은 객체로 구성작고 응집도가 높기 때문에 다른 객체와의 협력이 필수적이고 이는 의존성이 필연적으로 수반됨과도한 의존성은 App의 수정을 어렵게 하기에 이를 관리해야 함1. 의존성 이해하기두가지 의존성실행 시점 의존성: 객체 정상 동작을 위해선 실행 시 의존 대상 객체가 반드시 존재해야 함구현 시점: 의존 대상 객체 변경시, 의존하는 개체또한 변경런타임 의존성과 컴파일 타임 의존성런타임 의존성애플리케이션 실행 시점컴파일 타임 의존성컴파일 시점 or 코드 그 자체를 의미하며 이는 코드의 구조를 의미함→런타임의 객체 사이의 의존성을 의미하고, 컴파일 타임때는 클래스간 의존성을 의미함객체가 협력하기 위해선 구체적인 클래스를 알아선 안되고, 런타임에 협력 객체가 결정되..

문제 해결에 필요한 핵심만 남기는 작업을 추상화이때, 큰 문제를 해결 가능한 작은 문제로 나누는 작업을 분해라고 함1. 프로시저 추상화와 데이터 추상화프로시저 추상화s/w가 무엇을 해야 하는지 추상화기능 분해(알고리즘 분해)데이터 추상화s/w가 무엇을 알아야 할지 추상화타입 추상화(abstract data type)데이터를 중심으로 프로시저를 추상화(Object-oriendted)2. 프로시저 추상화와 기능 분해전통적인 하항식 접근 방법을 따름시스템을 구성하는 가장 최상위 기능을 정의하고, 작은 하위 기능으로 분해하향식 접근 시스템의 예시직원 급여 계산 시스템(main 함수) - 전역 변수 저장 직원 기본급 정보를 얻음 - 세율을 입력받음 - 이를 통해 급여를 계산함하향식 접근의 문제점기능 추가시에 메인..

1. 협력과 메세지객체가 다른 객체와 협력함으로써 독립적인 객체에서 더 큰 책임을 가질 수 있다이때 협력을 위한 매개체가 메시지 이다.메시지와 메시지 전송메시지 전송자는 클라이언트, 수신자는 서버라고 부르기도 함결국 메시지 전송자는 특정 객체의 함수를 호출하는 객체, 수신자는 특정 객체를 의미메시지와 메서드메시지를 수신했을 때, 실제 실행되는 함수 또는 프로시저를 메서드 라고 함메시지를 전송시 컴파일 시점과 실행 시점에 따라 메서드가 다를 수 있음이를 통해 유연하고 확장 가능한 코드 작성 가능2. 인터페이스와 설계 품질좋은 인터페이스는 최소한 + 추상적 인터페이스라는 두가지 조건을 만족시켜야 함이를 위해 책임 주도 설계를 활용한다면, 객체가 필요한 메시지만 가질 수 있게 됨디미터 법칙객체 내부 구조에 강..