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

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

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..

행위(behavior) 요구사항을 기계에 구현하고 버그를 수정하는 일이 개발자의 모든 일이 아님을 깨닫는게 중요 개발자를 고용하는 이유는 이해관계자를 위해 기계가 수익을 창출하거나 비용을 절약하기 위함 곧 이해관계자가 기능 명세서나 요구사항 문서를 구체화할 수 있도록 돕는 임무를 포함 아키텍처(architecture) 핵심은 'sofrware': 부드러운(soft) 제품(ware) 소프트웨어는 부드러움을 지니도록 구성 - 기계의 행위를 쉽게 변경할 수 있도록 하기 위함 부드럽다는 의미는 변경하기 쉬워야하며 이해관계자가 기능에 대한 생각을 바꾸면 변경사항을 간단하고 쉽게 적용할 수 있어야함 변경사항을 적용하는 데 드는 어려움은 변경되는 형태와는 관련이 없어야하며, 범위에 비례해야함 ex) 잘못개발 사례: ..

"빨리 가는 유일한 방법은 제대로 가는 것이다." - 로버트 C. 마틴 (Rovert C. Martin) 설계(design)와 아키텍처(architecture)의 차이 결론적으로 의미 차이가 없음 아키텍처(architecture): 디테일한 것보다는 전체적인 것 설계(design): 디테일한 것에 초점 ex) "집"의 아키텍처: 집의 형태, 외관, 방의 배치 - 이런 것들은 모두 설계(design), 즉 아키텍처(architecture)는 설계(design)로 표현할수 있으므로 같은 의미 소프트웨어 아키텍처의 목표 필요한 시스템을 만들고 유지보수하는 데 투입되는 인력을 최소화 하는것 * 참고: Clean Architecture

1. 위 구조의 장점 - Framework가 독립적이라 바꾸기 쉬움 - UI, DB, server없이 비즈니스 rules들을 테스트 가능 - UI가 독립적이라 바꾸기 쉬움 (비즈니스 rules없이 바꾸기 가능) - DB종류에 대해 독립적 (DB종류가 바뀌어도, 바뀐 부분만 수정하면 똑같은 함수를 써서 똑같은 결과를 낼 수 있는 기대) 종합적으로, 각 레이어들이 바뀌어도 다른 레이어들이 모를 정도로 독립적인 구조라서 유지보수에 좋음 독립성: 결합도(모듈과 모듈과의 상호 의존 정도)는 낮게, 응집도(내부 모듈의 기능 집중도)는 높게 2. 위 레이어 구성을 사용할 때의 Rules 가장 중요 - 소스코드에서도 들어나야 함: 밖 layer에서 선언된 이름/함수/클래스 이름이, 내부에서 아예 불려지지 않아야함 - ..