스위프트 문법 : (x)
HIG : (x)
CS : (x)
코딩테스트 : (x)
크리스마스로 오늘은 약속을 다녀왔다. 원래는 오늘도 문법과 HIG를 정리하여 블로그에 업로드하려 하였지만 꾸준히 하기 위해서는 너무 집착하면 안되겠다 생각하여 약속을 가기 전 디자인 패턴에 대한 공부를 하면서 생각을 정리하기는 가벼운 공부만 하였다. 오늘은 HIG에 대한 생각을 많이 하였는데 다른 웹이나 안드로이드 앱 같은 경우에 이렇게 HIG가 잘되어 있나라는 생각도 많이 하게 되었다. 사실 그동안은 서버 개발을 하면서 디자인에 대한 이렇게 생각을 해본 적이 없는데 요 며칠간 HIG를 보면서 내가 그동안 당연하다고 생각하면서 사용했던 부분들이 애플과 개발자가 의도한 것들이라니 라는 생각을 하게 되었다.(그래서 내가 iOS에서 안드로이드로 갔다가 결국 다시 iOS로 돌아오며 지금은 맥북에 아이패드까지 쓰게 된건가..)
메리 크리스마스 ^&^
--------------Cocoa
Cocoa = Foundation + AppKit = OS X
Cocoa Touch = Foundation + UIKit = iOS
- AppKit, UIKit 둘 다 UI를 위한 목적으로 개발 되었으나 platform환경이 다름
현재의 Cocoa는 ObjectC Runtime기반의 NSObject를 상속받는 모든 클래스, 객체를 지칭
Foundadtion, UIKit, Core Data로 구성
- Core Data는 앱에서 지속되어야 하는 데이터를 관리(종료 후에도 유지)
-------------Cocoa Framework Degisn Pattern
메모리 관리를 위한 [두단계 초기화 패턴]
객체의 역할에 따라 구분하는 [MVC패턴]
객체가 처리할 메세지를 지연시키는 [메세지 셀렉터 패턴]
- 두단계 초기화 패턴
alloc > 메모리에 올리는 과정 : 힙 공간에 객체 인스턴스 메모리 공간을 할당
init > 초기화 과정 : 객체 인스턴스 속성이나 내부 객체들을 초기화
if) init을 거치지 않아도 사용할 수 있을까? (사용할수도 있다) 하지만 초기화 권장
두 단계의 과정을 하나로 줄여서 사용도 가능
Pen *aPen = [[Pen alloc] init]; >>> Pen *aPen = [Pen new];
- 지정 초기화 메서드 공부
- MVC 패턴
Cocoa Framework에서는 Model-Controller 관계에서 옵저버, 컴포지트패턴 사용
Observer: Model-Controller 사이에서 NSNotificationCenter
Composite: Controller가 해당 Model을 포함하는 경우 사용
Model
앱에서 지속적으로 사용하는 데이터는 모델 객체 내부에 "캡슐화"되고
FileManager, DB를 통해 영구적으로 저장하여 사용
- 화면을 구성, 데이터 처리, 데이터 추상화
View
-
주로 UIView 클래스를 상속받아 화면을 그림, 사용자의 입력을 받음
-
일반적으로 View 객체가 표시하는 "정보"는 Model객체가 갖고 있는 데이터 기반(즉, 서로 의존관계가 생기면 안됨)
-
하나의 View가 0개 이상의 Model Data와 매칭될 수 있음
View 객체는 화면을 구성하기 위해 Model Data와 밀접한 관계가 있지만 "해당 관계를 느슨하게 하는게 MVC 패턴 핵심" Controller가 그 역할을 해줌
Controller가 연결해주는 Model객체에 따라서 View객체는 얼마든지 "재사용" 가능
Controller
View와 Model사이에서 사용자 입력, 데이터 변화에 대한 "중재"
V > C > M : 사용자의 입력에 따른 데이터 변화를 CRUD
M > C > V : 변경된 데이터를 받아 View에 전달, 화면에 표시, 인터랙션
View 화면 복잡,사용자 입력 방식 다양 >> Data Model 커짐
Data Model 커짐 >> Model을 조작하는 Coltroller 동작 복잡 = Massive
*MVC패턴의 고민 Controller코드 복잡 길어짐
가볍고 재사용성 높히기 위해 변형 패턴 등장(MVVM,VIPER)등
- 메세지 셀렉터 패턴
** 단일 책임 원칙
모든 클래스는 하나의 책임만 가지며 책임을 완전 "캡슐화" 유지 보수와 관련
같이 수정해야할 것들은 묶고 따로 수정해야될 것들은 분리
여러 책임을 자신의 속성과 행동으로 직접 수행하는 객체 = GOD Object
GOD Object가 잣신의 메소드로 직접하지 않고 책임들 담당한 다른 클래스들의 인스턴스를 통해 동작
결국 하나의 클래스가 너무 많은 책임을 가지진 않았는지를 생각해봐야 함
유지보수가 용이한 코드로 분리하는 것
--Observer Pattern
한 객체의 상태가 바뀌면 그 객체에 의존하는 객체들한테 연락이 가는 일대다(구독,) 의존성을 말함.
느슨한 결합의 장점 :
-
언제든 옵저버 추가,제거 가능
-
주제와 옵저버가 서로 독립적 (바뀌더라도 서로에게 영향 제로)
*iOS에서는 ViewController(Sub), Model(Pub)로 사용
따라서 여러개의 ViewController가 하나의 Model의 변경사항을 사용할 수 있음
장점 : Open/Close원칙 지킬 수 있음, 코드수정없이 새로운 클래스 추가 가능
단점 : 알림의 순서 랜덤, 관계 정의를 잘 해야함.
--Composite Pattern
객체를 트리 구조로 구성하여 마치 하나의 객체인 것처럼 작업할 수 있는 패턴
ex) 어느 한 지점의 디렉토리or파일의 크기를 계산하는 프로그램을 본다고 하면 어느 지점에서든 파일이면 본인만 크기를 계산, 디렉토리라면 하위까지 같이 계산하여 반환하면 됨, 크기 계산을 하는 메서드를 interface에 정의하면 됨
*모두에게 똑같이 적용이 되는 메서드들을 한번의 정의할 수 있다.