[TIL] 21.11.01 Today I Learned (UML, KVO, Property Observer)

최근들어 직접 스토리보드를 다루며 처음으로 앱 같은 것을 만들고 있다. 

맨날 콘솔 로그로만 구현을 하다가 스토리 보드로 시뮬레이터도 돌려보고 하니 훨씬 재미있는 것 같다.

물론 해야할 것들은 점점점~~~ 늘어나고 있긴 하다. (Auto Layout도 공부해야 하고 LLDB도 공부해야 하고 Swift 문법도 좀 더 공부해야 하고..) 

 

오늘 할 일 

- JuiceMaker Step 2 프로젝트 리팩토링 

- 오토 레이아웃 관련 스크럼

- View의 LifeCycle 관련 공부

 

# KVO

외부에서 변화를 관찰하고 싶을 때 사용한다

특정 인스턴스의 key에 해당하는 값이 변하는지 계속 지켜보게 된다.
예를 들어 FruitStore의 재고가 변하는지 트래킹을 하고 싶은 경우, 인스턴스 외부에서 값이 바뀌는 것을 알고 싶다면 KVO를 사용할 수 있다.

여기서 직접 값이 변하는 클래스는 아무것도 하지 않고 단순히 외부에서 지켜보게 된다.
다만 Private으로 설정된 경우 KVO를 사용해서 외부에서 지켜볼 수 없다.

# Property Observer

스스로 변화에 대해 대처하고 싶을 때 사용한다

Property Observer의 경우 본인 타입의 변화에 대해 능동적으로 반응하기 위해 사용한다.

• willSet: 값이 변동되기 직전에 호출
  -> 만약 바뀔 값을 알고 싶을 땐 newValue를 사용한다.
• didSet: 값이 변한 직후 호출
  -> 예전 값을 알고 싶을 땐 oldValue를 사용한다.

Property Observer의 장점은 private한 값도 지켜볼 수 있다는 것이다.
(본인 타입을 본인이 지켜보는 것이라 가능하다)

=> 단 init을 할 때는 Property Observer가 동작하지 않는다.

연산 프로퍼티의 경우 Property Observer와 유사한 구조를 가진다
하지만 Property Observer와는 완전히 다르다.

• 연산 프로퍼티의 경우 computed property 블록에 있다.
• Property Observer의 경우 값을 가지고 있어야 하기 때문에 Stored property에서만 사용 가능하다.

# 그렇다면 KVO가 있는데 왜 Notification Center를 사용할까?

노티피케이션 센터의 경우 싱글톤으로 어디서든 메세지를 주고 받을 수 있다. 하지만 KVO의 경우 해당 클래스를 명확히 지정해준 경우만 사용할 수 있다.

따라서 용도와 목적에 따라 이들을 사용해야 한다. 무조건 맞는 방법은 없다

---

# UML

UML은 통합 모델링 언어이다. 단순히 코드를 도식화하는 다이어그램을 표현하는 것이 아니다.

그렇다면 왜 UML을 언어로 표현했을까? 그 이유는 바로 UML이 커뮤니케이션을 하기 위해 코드를 구조화하고 규격화했기 때문이다. 즉, 소통을 위한 방법으로 사용하기 때문에 언어라고 표현하고 있는 것이다.

이런 UML Diagrams는 2가지로 분류할 수 있다.

• 구조 다이어그램 (대표적으로 Class Diagram이 있다)
• 행위 다이어그램 (대표적으로 Sequence Diagram이 있다)

# Class Diagram

Class Diagram을 잘 활용하면 의존 관계를 파악하고, 순환 의존을 찾을 수 있다.
-> 여기서 의존이란 특정 객체에서 다른 객체를 사용하는 것을 말한다.

• 일반화: 상속 관계를 표현 (하위 클래스에서 상위 클래스로 화살표를 보낸다)
• 실체화: 인터페이스와 그 것을 구현한 것과의 관계
• 의존: 어떤 클래스가 다른 클래스를 사용함 (사용하는 객체 쪽으로 화살표를 보낸다)
• 연관: 클래스의 속성에서 사용함.
• 집합 (집약, 합성): 다이아몬드가 붙어있는 곳이 전체 객체
• 집약: 전체 객체가 사라져도 부분 객체는 사라지지 않는다. (생명주기가 의존적이지 않다)
• 합성: 전체 객체가 사라지면 부분 객체가 사라진다. (부분 객체의 생명주기를 전체 객체가 관리)

# Sequence Diagram

시간 순서에 따라 객체 간 협력을 보여준다.

• 실선: 요청하는 메세지
• 점선: 리턴되는 메세지

# 어떻게 UML 다이어그램을 그려야 할까?

• UML diagram을 그리다보면 너무 복잡해짐 → 쪼개기, 상위 개념에서 생각해보기 (자잘한 부분은 생략해보기)
• 처음부터 완벽하게 그릴 수 없음. (많은 수정이 좋은 구조로 가는 길이다)
• 꼭 지켜야 하는 법칙은 없다. (의사소통이 주 목적이다)

---

# 왜 viewDidLoad와 loadView는 파라미터에 아무 값도 넣지 않고 다른 메서드들은 파라미터에 animated를 Bool타입으로 받을까?

내가 생각했을 때 viewDidLoad와 loadView는 아직 화면이 구성되지 않은 상태이다. 따라서 어떻게 보여질 지를 animated를 통해 받을 필요가 없다.

이에 반해 viewWillAppear, viewDidAppear, viewWillDisappear, viewDidDisappear의 경우 사용자에게 어떻게 animated될 지 정해줘야 한다. 따라서 이들은 파라미터로 값을 받게 된다.

# 소스파일 이름의 경우 명사형으로 적는다.