절대 만사 OK가 아니다

변형도 마찬가지임


가끔 보면 이 패턴이 코드 디자인에서 정답인 것 마냥 제시하는 사람이 있어


'그냥 MVC 패턴 쓰면 되잖아'


세상의 모든 프로그래밍 디자인은 씹어버리고 닥치고 그냥 MVC 패턴만 쓰래

잘못된 거야


MVC는 View의 Depth가 깊어질수록 유지보수가 굉장히 힘들어진다

그리고 모듈 하나당 클래스를 몇개 씩 파야돼


이게 무엇을 의미하느냐


1. 개발자가 읽어야 할 코드의 양이 많아진다

2. 개발자가 추가해야할 코드의 양이 많아진다

3. 모델이 뱃살이다. 마인부우 같은 코드가 됨.


따라서 유지보수가 씹창이 나며, 프로그램이 커질수록 개발 속도에 지장이 생김


이게 가장 큰 단점이야

그럼에도 왜 쓰냐고? 보편적이고, 대중화 되었고 직관적이니까 쓰는 거임


안드로이드가 공식으로 쓰는 패턴인데 뭘 쓰지마 빼애애액 할 사람도 있을 텐데

그건 프로그래밍 입문 난이도를 낮추기 위해 구글이 배려해준 거야


구조에는 정답이 없다 다만


1. 디커플링

2. 응집도

3. Keep it simple


우리는 이 세 가지만 의식하면 좋은 구조를 짤 수 있음

SOLID 같은 원칙은 결국 저 세 가지를 지키는 데서 자연스럽게 지켜져


구조라는 건 프로젝트 참여 인원의 프로그래밍 레벨, 어떤 앱인가, 어떤 언어를 쓰는가, 어떤 패러다임을 사용하는가에 따라 천차만별로 달라진다

어디가서 무식하게 '그냥 MVC(MVVM,MVP) 패턴 씁시다' 이러지 마라 제발


계층화 패턴 (Layered pattern)

클라이언트-서버 패턴 (Client-server pattern)

마스터-슬레이브 패턴 (Master-slave pattern)

파이프-필터 패턴 (Pipe-filter pattern)

브로커 패턴 (Broker pattern)

피어 투 피어 패턴 (Peer-to-peer pattern)

이벤트-버스 패턴 (Event-bus pattern)

MVC 패턴 (Model-view-controller pattern)

블랙보드 패턴 (Blackboard- pattern)

인터프리터 패턴 (Interpreter pattern)


아키텍쳐 패턴은 수십가지고 꼭 여기서 골라 쓰라는 법도 없음