-
Notifications
You must be signed in to change notification settings - Fork 3
Week2 Assignment
Ellie Kim edited this page Feb 14, 2019
·
21 revisions
성준
-
개발자들과 디자이너들 사이에서 통용되는 공식 용어를 알고 사용할 수 있습니다.
- 이는 협업 간 커뮤니케이션에 큰 도움을 줄 수 있습니다.
-
일련의 작업들이 어떠한 방식으로 동작하는 지 이해 할 수 있습니다.
- 앱이나 화면을 설계할 때 큰 도움을 줄 수 있습니다.
-
Apple에서 정의한 Guideline을 통해 사용자의 관점에서 이해 할 수 있도록 도와줍니다.
- 사용자가 직접 터치하고 반응하는 화면을 구현하는 개발자로써 좀 더 사용 친화적인 결과물을 내놓을 수 있도록 도움을 줄 수 있습니다.
혜리
- 좋은 인터페이스를 제공합니다.
- 사용자가 사용하기 좋은 인터페이스를 제공합니다.
- 일관적인 애플리케이션을 제공합니다.
- 일관적인 아이콘이나 액션들을 제공합니다.
현태
- 사용자, 디자이너, 개발자 관점에서 앱 이해하기
- 서로의 관점에서 이해 하기 쉽도록 가이드라인을 제시받을 수 있습니다.
- 공식 용어를 이해하므로서 협업을 조금 더 용이하게 할 수 있습니다.
- UI 그리고 UX
- 오랜 기간동안 철학자들이 고민한 기준을 HIG를 통해서 쉽게 사용자들에게 제공할 수 있습니다.
- 특히 중요한 액션들은 기준을 제공함으로서 사용자들과 상호작용을 할 수 있습니다.
- 이러한 특징들을 통해서 사용성을 극대화 시킬 수 있습니다.
- UIButton이나 UIControl이 아닌 UIView를 상속받아 만들어 봅니다.
- 어렵다면 모둠원과 협심하여 하나의 저장소에서 구현해봐도 좋습니다.
정의
-
Model - View - Controller
- Model : 데이터 모델, 비즈니스 로직으로 구성되며, 애플리케이션이 무엇을 할 것인지를 정의
- View : 사용자에게 제공되어 보여지는 UI로 구성되며, 화면에 무엇인가를 보여주기 위한 역할을 함
- Controller : 모델이 어떻게 처리할 지를 알려주는(notify) 역할과 Model과 View를 연결 시켜주는 역할을 함
- 장단점 :
- 장점
- Model과 View를 완전히 분리시켜 이들의 재사용성을 높일 수 있습니다.
- 각각의 역할을 분명히 하여 코드가 목적대로 구분되지 않고 섞이는 스파게티 코드를 방지합니다.
- 매우 높은 생산성을 보여줍니다.
- 단점
- Massive ViewController 문제점 야기
- View나 Model에 들어가기엔 애매한 코드들이 모두 Controller로 들어가게 되는 경우
- View와 Controller가 라이프사이클에 의해 강하게 연결되어있습니다.
- 테스트가 힘들고, 여러 Side-Effect를 야기할 수 있습니다.
- Massive ViewController 문제점 야기
- 장점
- 참고자료 :
- [MVC 참고자료 1]
- [MVC 참고자료 2]
-
Model - View - ViewModel
- Model : 데이터처리, 비지니스 논리, 서비스 클라이언트 등으로 구성됩니다.
- View : 사용자의 눈에 보이는 인터페이스, 레이아웃
- ViewModel : View와는 Command, Data Binding로 연결하고 model과는 데이터를 주고 받습니다.
- 특징 :
- MVVM패턴은 Command패턴과 Data Binding패턴을 사용한다. 이 패턴으로 View와 ViewModel은 의존성이 사라집니다.
- ViewModel과 View는 1:N 관계
- 장단점 :
- 장점
- View와 ViewModel은 의존성을 없애 각각의 부분은 독립적이기 때문에 모듈화하여 개발할 수 있습니다.
- 단점
- ViewModel의 설계가 어렵습니다.
- 장점
- 참고자료 :
-
Model - View - Presenter
- Model : 프로그램에서 사용되는 실제 데이터 및 데이터 조작 로직을 처리하는 부분
- View : 사용자에게 제공되어 보여지는 UI 부분
- Presenter : View에서 요청한 정보를 Model로 부터 가공해서 View로 전달하는 부분
- 특징 : 언뜻보면 MVC 와 상당히 유사하지만 아래와 같은 차이를 보인다.
- UIViewController는 View 의 역할을 가지고 있다. 또한 MVC에서는 유저의 입력을 Controller에서 받는 반면에 MVP에서는 View에서 유저의 입력을 받는다.
- Presenter는 레이아웃에 관련된 코드가 전혀 없고, ViewController의 라이프사이클에 전혀 영향을 끼치지 않는다.
- 장단점 :
- 장점
- UIViewController에 View만 존재하고 Presenter는 구분되어 있으므로 뷰의 재사용성 덕분에 비즈니스 로직 테스트의 용이성을 지닌다.
- Model과 View는 서로를 전혀 알 필요가 없다.
- 단점 :
- View와 Presenter가 1:1의 강한 의존성을 갖게 된다.
- MVC 패턴에 비해서 코드의 양이 길어진다.
- 장점
- 참고자료 :
- [MVP 참고자료 1]
- [MVP 참고자료 2]
프로젝트 설계에서 디자인 패턴이 왜 필요할까?에 대한 팀원 간 토론입니다.
- 디자인 패턴은 어떤 구체적인 원인으로 앞으로 시스템을 변경해야 한다는 것을 미리 보여줍니다. 디자인 패턴은 다른 부분에 독립적으로 시스템 구조를 변경할 수 있게 하여, 시스템이 어떤 특정 변화에 순응할 수 있도록 합니다.
- 디자인 패턴을 사용하게 되면 통일된 의사소통 수단을 제공합니다. 또한 문제가 발생하면 해법을 찾기위한 불필요한 논쟁이 줄어듭니다.
- 저는 프로젝트를 하면서 많은 기능들이 추가되거나 삭제되는 경우가 굉장히 많을 것이라고 생각합니다.
- 이 때에 많은 버그들이 발생할 여지가 있고, 만약 디자인 패턴이 전혀 사용되지 않은 프로젝트라면 일정한 패턴이나 밑그림이 없기 때문에 일일히 코드를 분석하여 디버깅을 해야할 것입니다.
- 그래서 디자인 패턴은 유지보수 측면과 개발 과정에서의 다양한 이슈들을 해결하는데 큰 도움을 주기 때문에 필요하다고 생각합니다.
- 저도 디자인패턴이 개발의 측면에 있어서 굉장히 많은 도움을 주는것은 찬성하지만, 디자인 패턴을 너무 믿지 않는 것 또한 맞다고 생각합니다.
- 예전에 no silver bullet이라는 글을 읽은 적이 있습니다. 한번씩 참고해 보시면 좋을 것 같습니다.
- 따라서 무슨 디자인패턴을 100% 적용할까 라기 보다는 우리 앱에는 어떤 디자인패턴의 어떤 부분을 차용해야 할까 라는 점에서 접근해야 한다고 생각합니다.
- 적용한 부분들은 팀원 모두 그리고 추후의 인력들에게 인수인계 하기 위해서 따로 문서로 정리해 놓는 것이 좋다고 생각합니다!
- Cocoa Touch의 아버지 격인 Cocoa(API)는 NeXT사가 1980년대에서 90년대 사이에 개발한 프레임워크입니다.
- 79년도에 제록스 팰러앨토 연구소에서 MVC 패턴이란 것이 최초로 소개되었다고 합니다.
- 그래서 개발 연도를 고려해봤을 때, Cocoa Touch의 전신인 Cocoa가 개발되었을 당시 MVC 패턴이 가장 효율적이고, 획기적인 아키텍처이였기에 MVC 패턴을 채용한 것이 아닐까 추측해봅니다.
- 여러분 생각은 어떠신가요?
- 참고자료
- 바인딩, 다큐먼트 아키텍처, 스크립팅 등 같이 많은 Cocoa의 기술과 아키텍처가 MVC에 기반하고 있기 때문에 Cocoa touch, Cocoa touch Framework 또한 MVC에 기반으로 작성된 것 같습니다.