shw0471/mvp_designpattern_practice

안드로이드 MVP 디자인패턴 연습

mvp_designpattern_practice's Issues

코드 리뷰 9/24

사소한 것들

1. 패키지 명이 왜 대문자로 시작 허허
2. HumanListAdapter 26라인: LayoutInflater.from(context)를 통해서 얻을 수 있어용
3. onBindViewHolder에서 humanList.get()을 통해서 변수에 담아두고 사용, 일관성이나 가독성 면에서 더 좋아보임
4. HumanListAdapter에서 addHumanList는 마지막에 하나의 요소를 추가할 때 사용하는 것 같은데, 이름이 addHumanList인 것 부터 이상함, addHuman으로 변경해서 human 하나만 파라미터로 받은 후 처리하는 것이 좋아보임. 아마도 humanList를 ArrayList타입으로 변경해야 할 것임

아키텍처

일단 Model이라는 개념에 대해서 헷갈리는 부분이 많을 것이라 생각하는데,

내 생각에는 Presenter로 데이터를 전달하기 전 처리하는 모든 과정 (데이터 접근(서버, 로컬db, preference 등), 캐싱) 에 해당하는 부분이 Model이라 생각함

그래서 View, Presenter와는 다르게 더 많은 계층으로 구성될 수 있음. 우리 회사 같은 경우에는 Data access, 캐싱 계층이 Model에 포함됨

1. Model이 Presenter를 알고있음, 모델은 하나의 화면, Presneter에 종속된 로직이 위치한 계층이 아님. 하나의 데이터에 하나의 화면만 접근하는 것이 아니잖아. 예를 들어서 상품 리스트 화면과 관심 상품 화면이 있을 때, 상품이라는 데이터에 접근하는 화면이 하나가 아니기 때문에 이렇게 설계하면 중복되는 코드가 반드시 존재할 것임

그렇기 때문에 사용하는 방법으로는 Interface를 통해서 콜백을 생성하는 것, model의 getList를 호출할 때 그 인터페이스를 Presenter에서 구현하여 넘겨줘서 콜백 방식으로 하는 것이 베스트일듯.

2. Context를 Presenter로 넘겨주는 로직

Realm.init()은 프로그램 실행 때 한번만 호출해주면 되기 때문에 모델에서 안해도 될듯, 그리고 Presenter로 context를 넘겨주면 추후에 테스트 코드를 작성하기 힘들어짐. 왜냐면 Context는 안드로이드 프레임워크에 종속적인 개념이기 때문에 Presenter로직을 테스트할 때 방해물이 될 가능성이 높음

3. Contract의 모델 인터페이스

이건 개인 취향차이라고 할 수 있는데. 개인적으로는 Contract에 모델을 포함하는 것은 어울리지 않다고 생각함. 위에서 말한 것 처럼 하나의 화면, 기능에 종속적인 개념이 아니라서. 하지만 인터페이스로 직접적인 의존성을 만들지 않는 습관은 테스트나 유지보수에 좋으므로 Contract에서 인터페이스를 빼는 작업만 해도 좋을듯.

4. Advanced MVP

아래 링크는 MVP를 설계할 때 좋은 자료

https://www.youtube.com/watch?v=ooMT69xOiKI

5. 테스트와 MVP

아래는 MVP와 테스트 코드를 작성하는 방법, TDD프로세스를 사용한다는 것은 품질높은 코드와 유지보수성을 높이는 가장 좋은 방법

https://www.youtube.com/watch?v=avcKY-_3gus

6. View 메소드 이름들

public interface View {
        void setRecyclerView(List<Human> humanList);

        void addRecyclerView(List<Human> humanList);
    }

setRecyclerView, addRecyclerView 허허... setHumanList 이런게 어울릴듯