2021. 9. 26. 19:55ㆍapp Architecture/MVC
https://www.youtube.com/watch?v=gI3pz7eFgfo&t=10s
이 포스팅은 위의 강의를 듣고 참고하여 작성하였습니다.
제 느낌대로 번역했기 때문에 잘못된 부분이 있을 수 있습니다. 이런 부분은 댓글을 부탁드립니다.
안녕하세요 bannavi입니다^ㅅ^
오랜만입니다. 요즘은 개인 앱출시를 앞두고 있어서 프로젝트 작업에 열심이었네요!
오늘은 MVC 패턴 첫시간 입니다. 오늘은 MVC패턴에 대해서 아 요런~ 느낌이구만!을 깨달는 시간을 가져볼거에요!!
바로 시작하겠습니다!
오늘 배워볼건 MVC지롱?
MVC는 Model, Controller, View로 구성이 되어있구나
쉽게말해,
Model: 네 application이 뭐로 구성되어 있는지 설명해줄게
View: Controller's minion들
Controller: 나의 Model이 user들에게 어떻게 보여질지(UIlogic이 있는곳)
Model과 View의 직접적인 통신은 절대불가하다.
이유1) Model의 UI는 독립적이고, View는 오직 UI항목을 갖고있어서 통신할 수 있는 길이 없습니다.
이유2) View의 객체들은 일반 객체이기 때문입니다. 버튼과 slider같은 한낱 객체가 뭘 어찌할 수 있으리오..
강사님이 강조하셨다"NO WAY, NO WAY 저 노란 선넘지마라"
View는 Controller와 통신할 수 있습니다.
음 예를들어 버튼을 클릭할 때와 같이말이죠.
근데 이 communication은 blind및 structured(구조화)가되어야 합니다.
일반 뷰 객체이기 때문에 Blind여야한다고 하네요.
UIButton은 Controller에 대해 아무것도 알지 못해요 엥 그럼 어떻게..?
음음 Controller에 메서드를 생성하고 UIButton이나 other things는 action을 이용해서 버튼을 누를때마다 target을 호출합니다.
(아하.. 이런걸 괜히 어렵게 blind structured 통신이라고 했구나 ㅎ)
간단하죠?
근데 복잡한것도 있어요 예를들면 scrollView같은거.
View가 Controller에 알려야하는 정보가 있을 수 있다는거죠.
예를들면, 끝까지 스크롤했는데 스크롤 더해도돼..? 가로로, 세로로 스크롤해도돼..?같은! 정보.
(오호 View는 계속 Controller와 대화하기를 원하겠구나)
Controller는 미리 정의된 메서드를 사용해서 이를 수행합니다.
여기서 delegate의 개념이 나왔는데, View의 행동을 Controller가 대신해서 할 수 있도록 도와주는게 delegate인것 같아요.
should, will, did라는 키워드로...! 이게 고전적인 delegate방법이라네요.
이렇게 되면 Controller는 protocol채택을 통해서 ScrollView에게 말할 수 있게된다고 합니다.
여기서 중요한것! View는 View가 표시하는 data를 소유할 수 없습니다.
대신에 Controller가 protocol매커니즘(dataSource)을 사용해서 Model과 대화하고 View에 대한 데이터를 가져올 수 있습니다.
Model은 직접적으로 Controller와 대화할 수 있는건 아닙니다.
Model은 UI에있어서 독립적이고, Controller는 기본적으로 UI에 종속되어 있어서 직접 수행할 수 없대요!
이럴땐 Notification과 KVO를 이용합니다.
MVC는 iphone 또는 ipad에서 한 화면만 제어하는데 사용됩니다.
근데 대부분의 앱은 많은 화면을 갖고있죠.
그럼 여러 MVC에서 앱을 구축하려면 어떻게 해야할까요?
보라색은 모두 Controller인데 항상 다른 MVC를 뷰의 일부로 취급합니다.
일반적이고 재사용 가능한 구성 요소처럼 작동.......으아 디버그 하기 너무 힘들어보이네요. 그래서 이렇겐 안할거에요.
강사님이 예시로 준 화면. 카드게임 같은걸 만들고 싶어하시는거 같아요. 강의 중간중간 계속 카드 게임 컨트롤러, 카드 게임 컨트롤러...ㅎ
왼쪽에 보여지는게 View고 오른쪽에 있는게 Controller입니다.
M이없네요. Model!!!! 만들러 가봅쉬당
UI가 아니라 Model에 대해 얘기하고 있으니까 Swift File로 충분해요
UIKit은 가져오지 않을거에요 UI파일이 아니니까요!
강사님은 이렇게 class를 만들때마다 public ApI가 뭔지 생각한다고 하네요? 뭔소리야..!
일단 API는 Application Programing Interface의 약자에요. 하.. 진심. 애증의 APIㅋ 요친구도 곧 다뤄볼게요.
API는 해당 class의 모든 메서드와 인스턴스 변수의 목록이에요.
public APi는 다른 class가 호출하도록 허용할 모든 인스턴스 변수와 메서드래요.
지금부터 아래의 글은 코드를 해석하려 하지 말고 느낌만 봐주세요..!
전체 코드도 없을뿐더러 오늘 강의의 목적은 아하 MVC가 이런거구나 느낌 파악하기! ㅎㅎ
강사님은 요렇게 간단한 Model을 만드셨어요. Card를 만들어놓지 않아서 에러가 나네요.
그리고 이 Card를 struct로 만들거에요
struct는 데이터를 보유하는 littile thing이고, swift에서 struct와 class는 거의 동일합니다.
그럼 뭔 차이점은 뭐냐?
1) struct - 상속 없음.(오 class보다 struct가 간단하네)
2) struct는 값형식, class는 참조 형식
값형식: 인수로 전달하면 배열에 넣고 다른 변수에 할당해도 복사됩니다.(구조체인 Array, int, String, Dictionary은 모두 값형식)
참조형식: 포인터를 전달한다.
현재 상태입니다.
엥! 카드에는 호박, 유령같은 그림도 있잖아요!
네 있겠죠 근데 Model은 UI에 있어서 독립적(independent)이라했죠?
그래서 이모지~, jpeg 이미지~ 이런걸 가질 방법은 없습니다.
Model에 이모티콘, 이미지 따위는 들어가지 않을거란 말을 어렵게 했네요.
강사: API와 Model이 여기있네요. (class를 API라고 표현하셨음)
그럼 MVC에서 제일 의문이었던 점.
만들어둔 Model을 Controller에서 어떻게 사용해요..?
맞아요 이 green arrow를 만들어야해요.
요 사진으로 어떤 느낌인지 느낌을 캐치할 수 있어야해요.
앞으로 MVC에 대해 반복적으로 공부할테니 지금은 느낌만 파악해보세요.
그리고 Model내용을 추가해봤습니다.
여기에서는 구조체를 전달할 때 복사한다는것을 이해해주세요
이제 Controller가 Model과 이어집니다.(green arrow)
이제 Model에서 View를 업데이트 해야합니다.
