디자인 패턴, 아키텍처

공부한 것

• 타입의 실체화는 인스턴스화. 이니셜라이즈 하는 과정이다. (리마인드)
• 스위프트에서 객체(Object)라는 말을 잘 안 쓰는 이유: 객체는 class의 인스턴스만을 뜻하고, Swift에는 struct나 enum도 있기 때문
• 디자인 패턴: 소프트웨어 디자인 과정 중 흔히 발생할 수 있는 문제 상황에 대한 재사용 가능한 해결 방법이다.
• 디자인 패턴을 사용하는 것을 교리처럼 따르면 안 된다. 적합한 상황에 필요한 만큼 사용하면 된다.
• MVC: Model-View-Controller 패턴

고민한 점

• 애플의 MVC는 무엇을 구분할까?
  • 모든 객체가 코드 안에서, 앱 안에서 수행하는 역할에 따라 Model Object, View Object, Controller Object라는 3개의 타입으로 나누어진다.
  • 객체의 목적 및 역할을 최대한 나눌수록 객체의 재사용성 및 해당 객체가 속한 프로그램의 확장성을 증대할 수 있다.

• 아키텍처에 따라 사용 가능한 디자인 패턴이 어느 정도 정해진 느낌인데, 디자인 패턴은 아키텍처에 종속된 것인가? (활동학습 중에 나왔던 질문)
  • 아키텍처에 따라 내부적으로도 어느 정도 패턴화가 될 수 있다. 아키텍처는 건물의 설계도같은 거고, 층별로 조금씩 디자인이 다를 수도 있고 같을 수도 있고..
  • 큰 덩어리의 범주냐, 작게작게 타입 및 단위별로 패턴화할 수 있냐 정도의 차이?
  • 서양식 건물 설계도에서 한국식 방을 만들기 힘든 것처럼, 조화롭게 엮이기 힘든 아키텍처와 디자인 패턴은 있기 마련이다.

• MVC 패턴의 단점은 무엇이며, 왜 MVVM에 목을 매는가?
  • 애플 MVC 패턴에서는, 뷰 관련된 코드와 모델로부터 데이터를 받아오는 코드가 뷰 컨트롤러라는 하나의 클래스에 혼재되어 있다.
  • 즉 뷰 컨트롤러가 유저의 입력에 따라 뷰도 바꾸고, 모델 객체에도 손을 대는데, 그 코드가 한 곳에 몰려 있다는 이야기이다.
  • 프로젝트가 커질수록 뷰 컨트롤러도 비대해지고, 유지보수에 어려움을 겪을 수 있다.
  • 반면 MVVM의 컨트롤러는 뷰 관련 역할만 수행한다. 전체적으로 모듈화된 코드로 인해 유지보수가 좀 더 쉽다. 또한 각각의 모듈에 대한 테스트도 용이해진다.
  • 다만 MVC를 통해 기본을 잘 다져야만, MVVM도 올바르게 사용할 수 있다고 느꼈다. MVVM은 데이터의 흐름에 대해 잘 파악해야 수월히 사용할 수 있다고 생각했기 때문..