김종권의 iOS 앱 개발 알아가기

Component (컴포넌트) 컴포넌트의 개념: 시스템의 구성 요소로 배포할 수 있는 가장 작은 단위 iOS에서는 .ipa 파일 컴파일형 언어에서 컴포넌트는 '바이너리 파일'의 결합체 인터프리터형 언어에서 컴포넌트는 '소스 파일'의 결합체 cf) 인터프리터형 언어: 컴파일러를 거쳐서 기계어로 변환되지 않고 바로 실행되는 프로그래밍 언어 스위프트는 '컴파일형'언어 Component Cohesion (컴포넌트 응집도) REP(Reuse/Release Equivalence Principle): 재사용/릴리즈 등가 원칙 CCP(Common Closure Printciple): 공통 폐쇄 원칙 CRP(Common Reuse Principle): 공통 재사용 원칙 REP 재사용을 위하여 컴포넌트를 구성하는 모든 모..

DIP 소스 코드 의존성이 추상에 의존하며 구현체에는 의존하지 않는 시스템 이유: 의존한다는 것은 의존하는 대상이 변경될때 영향을 받으므로, '추상'은 '구체'보다 변화가 적기때문에 '추상'에 의존함으로서 변경에 유연한 코드를 유지하기 위함 인터페이스는 구현체보다 변동성이 낮은 점을 사용 소프트웨어 설계자는 인터페이스의 변동을 낮추고 구현체에 기능을 추가할 수 있는 방법을 찾기위해 노력 운영체제나 플랫폼 같이 안정성이 보장된 환경에 대해서는 DIP를 무시 예를 들어 자바의 String은 구체 클래스이며, String클래스가 변경되는 일이 거의 없으므로 DIP가 아니어도 안정적 Factory 아이디어: 변동성이 큰 구현체 객체를 생성할 때는 의존성을 주의하여 생성 builder 역할 구현체 객체를 사용하기..

ISP 필요 이상으로 많은걸 포함하는 모듈에 의존하는 것을 분리하기 위해, 의존 범위를 interface를 통해 좁히는 것 User1은 op1()만 사용, User2는 op2()만 사용, User3는 op3()만 사용할 때 아래 구조 ISP에 어긋난 구조: User1에서는 op2와 op3를 전혀 사용하지 않아도 User1의 소스 코드는 이 두 메서드에 의존하는 관계 ISP를 따르는 구조: User1, User2, User3 각각 기능에 따라 Interface를 따라서 의존 범위를 좁혀줌으로서 op1이 변경되어도 User2, User3에 영향이 가지 않도록 설계 ISP에 어긋난 구조 ISP를 따르는 구조 * 참고 Clean Architecture

LSP 부모 클래스의 객체 대신에 자식 클래스의 객체로 치환해도 프로그램의 행위에 변화를 주지 않아야 한다는 원칙 자식 클래스 or 구현체를 만들 때, 상위 타입의 객체로 치환해도 문제가 없는지 파악해야 한다는 의미 인터페이스를 구현한 구현체 역시도 LSP원칙을 준수 목적: 치환 가능성을 조금이라도 위배하면, 추후 상당량의 별도 메커니즘이 필요 정사각형 - 직사각형 문제 사각형의 하위 타입으로 정사각형으로 구성하면 LSP위배 User입장에서는 Interface인 Reactangle의 성격을 생각하고 사용하지만, Square에서의 성격이 다른경우가 존재하면 오류 발생 그 오류를 해결하기 위해서는 상당량의 별도 매커니즘이 User에 필요하게 되는 악순환 발생 예시) setH, setW 호출 후 넓이 계산하는..

OCP 개념: 기능이 추가될때 소프트웨어 개체는 확장을 하는 방향이며, 변경은 최소화 더욱 정확한 개념: 의존관계를 잘 설정하여 특정 항목이 변경되어도 중요한 interactor같은 컴포넌트는 변경하지 않아도 되는 형태 목적: 시스템을 확장하기 쉬운 동시에 변경으로 인해 시스템이 너무 많은 영향을 받지 않도록 하는 것 OCP 아이디어 아이디어: A, B 관계에서 A컴포넌트에서 변경 발생 -> B컴포넌트는 수정하지 않는 방법? B컴포넌트가 A컴포넌트에 의존하고 있지 않으면 해결 의존성을 관리하려면 Interface를 통해 의존 관계를 변경 예시 View에서 변경 -> Presenter 보호 Presenter에서 변경이 발생 -> Controller 보호 View, Presenter, Controller, ..

SRP 개념 개념: 하나의 *모듈은 오직 하나의 *액터에 대해서만 책임져야한다는 원칙 * 액터(actor): 해당 변경을 요청하는 한 명 이상의 사람을 지칭 * 모듈: 함수와 데이터 구조로 구성되어 응집된(cohesion) 집합 잘못된 SRP의 의미 주의 잘못된 개념1: 모든 모듈이 단 하나의 일만 해야한다는 잘못된 개념 -> 모든 모듈이 단 하나의 일만 해야한다는 개념은 '함수'의 정의 잘못된 개념2: 하나의 모듈은 오직 하나의 사용자 또는 이해관계자에 대해서만 책임 -> 시스템이 동일한 방식으로 변경되기를 원하는 사용자나 이해관계자가 두 명 이상일 수 있기 때문에 잘못된 개념 SRP는 메서드와 클래스 수준의 원칙이며, 이보다 상위 수준인 컴포넌트 수준은 공통 폐쇄 원칙(Common Closure Pr..

Architecture vs SOLID Architecture는 빌딩, SOLID는 좋은 벽돌 SOLID를 통해서 좋은 아키텍처를 정의 SOLID: 함수와 데이터 구조를 클래스로 배치하고, 이 클래스들을 결합하는 방법에 대한 이론 cf) architecture vs design pattern vs SOLID architecture: 프로그램 내에서 큰 구조로 구성되어 다른 구성 요소들을 관리 방법으로 넓은 개념 design pattern: 특정 유형의 문제를 해결하는 방법으로 좁은 개념 SOLID: design pattern은 특정 문제 유형을 해결하는 개념이고, SOLID는 아키텍처를 위하여 세부 구조를 어떻게 배치하고 결합하는지에 관한 개념 SOLID의 목적 변경에 유연 이해하기 쉬움 많은 소프트웨어..

함수형 프로그래밍 함수형 프로그래밍의 핵심은 가변 변수: 가능한 가변 변수를 지양 race condition, deadlock, concurrent update 문제 해결을 위한 프로그래밍 람다(lambda) 계산법이 핵심 (Alonzo Church, 1930년대에 발명) cf) 1958년 최초 함수형 프로그래밍 List, 1972년 절자치향 프로그래밍 c언어 클로저 표현식 존재 4가지 특징 1. Pure Functions 외부의 상태값을 참조 or 변경할수 없는 것 // x let num = 1 func add(a: Int) { return a + num } 2. Statesless, Immutability (= no sideEffect) multi thread 환경에서도 안정적으로 동작 가능 // x..