일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | ||||
4 | 5 | 6 | 7 | 8 | 9 | 10 |
11 | 12 | 13 | 14 | 15 | 16 | 17 |
18 | 19 | 20 | 21 | 22 | 23 | 24 |
25 | 26 | 27 | 28 | 29 | 30 | 31 |
Tags
- 의존성
- 메서드를 통한 해결
- 유여난 설계
- 명령-쿼리 분리
- 책임주도설계
- 유연한 설계
- 합성
- 상속
- 다형성
- OOP
- dip
- '기존 설계 재사용
- 설계 재사용
- 상속 조합 폭발적 증가
- 행동 호환성
- 믹스인
- 객체지향
- 컴파일 타임 의존성
- 객체 생성 사용 분리
- 추상화
- 하향식 접근
- 서브 타이핑
- 일관성 있는 협력
- 오브젝트
- iSP
- Apple # HIG #iOS15 #iOS14 #Human #Interface #Guidelines #Apple developer # Apple human interface guidelines
- OCP
- 알고리즘
- 런타임 의존성
- Swift#flatMap#map#Monad#함수형 프로그래밍#Optional
Archives
- Today
- Total
도니의 iOS 프로그래밍 세상
[오브젝트] 15장 - 디자인 패턴 / 프레임워크 본문
디자인 패턴 및 프레임 워크
디자인 패턴
- S/W 설계에서 반복되는 문제에 대해 적용할 수 있는 해결 방법
프레임워크
- 설계와 코드를 함께 재사용하기 위한 것
공통점
- 협력을 일관성 있게 제공하는 게 목적
차이점
- 디자인 패턴: 설계의 묶음
- 프레임 워크: 일관성 있는 협력을 제공하는 확장 가능한 코드
01. 디자인 패턴과 설계 재사용
- 패턴의 핵심은 정의가 아닌 뉘앙스를 이해하는 것
- 패턴의 핵심적 특징
- 패턴은 반복적 문제와 해법의 pair로 구성
- 패턴을 사용하여 다른 사람과 의사소통이 간단해짐
- 패턴은 실무에서 “발견된 것”
- 패턴은 다양한 context에서 사용되는 유용한 idea
패턴 분류
- 아키텍쳐 패턴
- s/w 전체 구조 결정에 사용
- 정의된 서브 시스템 제공, 각 서브 시스템의 책임 정의, 서브 시스템 관계간 규칙 및 가이드라인 포함
- 디자인 패턴
- 특정 context에서 설계 문제 해결
- 협력 컴포넌트 사이 반복적 구조를 서술
- 기타(분석 패턴, 이디엄 패턴)
패턴과 책임-주도 설계
- 객체 지향에서 책임과 협력을 결정하는 작업에는 많은 시간이 소요될 가능성이 높음
- 이때, 패턴은 공통으로 사용할 수 있는 역할, 책임, 협력이 Template화 되어 있음
- 이를통해 특정 상황에 적용 가능한 설계를 빠르게 적용할 수 있음
패턴은 출발점(Not 목적지)
- 패턴은 목적지가 아니기 때문에 맹목적으로 사용할 때 문제가 발생
- 패턴 사용의 이유가 설계의 문제점을 해결할 수 있는 좋은 해결책이 아닌, “특정 패턴을 경험해보고 싶기 때문” 될 수 있음
- 패턴 사용시 단순함 < 패턴의 복잡성을 통해 얻는 이득 일때만 사용해야 함
- 동료들이 해당 패턴에 익숙한지 여부를 확인해야 함
02. 프레임워크와 코드 재사용
디자인 패턴
- 재사용 가능한 설계의 idea를 제공하는게 목적
- 따라서, 특정 언어에 맞춘 가공이 필요한 게 단점
재사용 관점
- 설계 재사용 < 코드 재사용
- 기존 컴포넌트를 재조립해서 App을 구현할 수 있기 때문
- 그렇다고 해서 코드 재사용만 추종하기엔 그로인한 trade-off가 더욱 큼
- 따라서 코드 재사용 및 설계 재사용의 적절한 레벨을 사용해야 함
- 적절함의 기준은 X → But, 이에대한 가장 좋은 사례가 바로 framework
Framework
- 시스템 전체 or 일부를 구현한 재사용 가능한 설계
- ex. iOS 개발에선 UIKit framework
- 특정 화면을 만들기 위해선 기존 정의된 UIView를 상속받아 사용
- 특정 화면 및 동작을 위해선 기존 정의된 UIViewController를 상속받아 사용
- 재사용성을 위해 일관성 있는 협력 구조를 가짐
- 의존성을 추상화에 의존하고, 변경 가능한 것들을 캡슐화한 구조
- 하위모듈(변경 가능한 것) → 상위 모듈(변경될 가능성이 적은 것)
- 컴파일 관점에서 하위 모듈(변경 가능한 것)이 변해도 상위모듈은 re-compile되지 않음
- 상위 모듈이 변한다면, 당연히 그에 따른 하위 모듈또한 당연히 re-compile됨
제어 역전 원리
- 객체 지향 이전
- 상위 정책 → 구체적 세부사항에 의존
- app이 특정 toolkit, 라이브러리의 코드를 호출
- 객체 지향 이후
- 하위 모듈 → 상위 모듈
- framework는 일반적 해결책 제공, 구체적 동작은 app에서 확장
- app이 특정 framework를 호출하는 게 아닌, framework가 main program을 사용함
- 제어 주체가 framework가 됨
- ex. iOS에서 레이아웃 관련 코드들은 우리가 작성
- 하지만, 레이아웃 코드가 호출되는 것은 framework에서 제어함
제어 주체가 app → framework로 이동하여, 제어 흐름이 역전됨
결론
- 디자인 패턴은 설계를 재사용하는 것, 프레임워크는 설계 및 코드 재사용
- 패턴은 목적지가 아니기 때문에, 특정 상황에 적절한 패턴을 적용해야 함
- 적절한 코드 재사용 및 설계 재사용의 예시가 프레임워크
- 프레임워크는 일관성 있는 협력을 통해 추상화에 의존하는 의존성 역전의 구조를 지님
'OOP' 카테고리의 다른 글
[오브젝트 2회독] 2장 - 객체지향 프로그래밍 (3) | 2024.09.08 |
---|---|
[오브젝트 2회독] 1장 - 객체 설계 (0) | 2024.08.15 |
[오브젝트] 14장 - 일관성 있는 협력 (0) | 2024.07.21 |
[오브젝트] 13장 - 서브 클래싱 및 서브 타이핑(2) (1) | 2024.07.21 |
[오브젝트] 13장 - 서브클래싱과 서브 타이핑(1) (0) | 2024.06.06 |
Comments