먼저 간단히 질문을 한번 해보죠. 이것은 한번 생각해보시라는 뜻입니다.

"왜 현재 Android 구조에서 adapter계열을 둬서 model의 데이터를 view형태로 만들까?" 

model의 업데이트 내역을 view 에서 직접 갱신하는 방법은 mvc 초창기 패턴에서 사용하던 방법입니다.

하나의 model에 하나의 view. 이것을 커플링이 생긴다고 말하는 것입니다.

왜냐면 model - view이 각자 독립적으로 나뉠 수 없기 때문입니다.

model 을 떼어서 다른 view에 붙히지도 못하고,

view를 떼어서 다른 model을 붙히니지도 못합니다.

정리하신 내용은 MVVM이라고 해서 Model-View-ViewModel 방법론으로 말하는 사람들도 있고,

저도 이것이 mvc라는 구시대의 방법론을 개선하고 직교성을 높히는 데의 의의가 있다고 생각합니다만,

재사용성이 떨어지는건 탐탁치 않은 모습입니다.

그렇다면 장점인 직교성을 취하면서 단점인 재사용성이 떨어지는 것을 해결하기 위해서는 어떻게 해야 할까?

같은 방법으로 interface를 통해 view가 다른 역할자와 통신하도록 하면 되고, 이것이 MVP라는 패턴의 골자입니다.

fragment를 언급하셨는데,

나중에 제가 정리해서 올리려고 했는데 지금 맛보기로 간략히 말씀드리면,

FragmentActivity + Fragment계열 adapter를 묶어서 presenter로 만들고,

View를 담당하는 Fragment는 Attach 될 때 callback interface를 생성해둬서

presenter와 통신할 수 있도록 하는 식입니다.

// View 와 presenter 간의 interface 통신 채널 구축

    OnViewRequestListener mCallback;
   
    @Override
    public void onAttach(Activity activity) {
        super.onAttach(activity);
        Utils.logging(this, "onAttach : " + activity.toString() );

        // This makes sure that the container activity has implemented
        // the callback interface. If not, it throws an exception.
        try {
            mCallback = (OnViewRequestListener) activity;
        } catch (ClassCastException e) {
            throw new ClassCastException(activity.toString()
                    + " must implement OnConvertListener");
        }
    }

// 사용자 인터랙션

@Override
    public boolean onDoubleTap( MotionEvent e ){
....중략...
        mCallback.onViewModeChange();
        return false;
    }

// Presenter의 data update

    @Override
    public void onViewModeChange() {
        mFragmentAdapter.ViewModeChange();
        mFragmentAdapter.notifyDataSetChanged();
        ... 생략...
    }

네~ 로쓰님의 성실한 응대에 저도 감사드립니다.

1. 이 부분이 앞서 로쓰님과 했던 이야기의 키포인트입니다.

앞서 제가 했던 얘기와 MVVM, MVP 패턴 모두가 Model 과 View를 어떻게 추상화 할 것인가에 주안을 두고 있기 때문입니다. 그런 바탕 하에서 제가 봤을 때는, View의 상태 갱신을 Model의 update와 연결하는 의도 자체는 좋으나, 추상화가 되어 있지 않아 data가 view에 바로 바인딩 되는 형태기 때문에 커플링이 있는 것이라고 생각하는 것 입니다.

제가 안드로이드에서 adapter가 view를 반환하는 형식을 취하는 이유에 대해서 질의 했었는데,

그 이유가 여기 있습니다. update를 데이터 형식으로 취하는 것은 model의 데이터와 view 간에 공통된 data를 취급한다는 것은 커플링이 생긴 것이라고 말할 수 밖에 없습니다. 답변 중에 말씀하신 model이 viewmodel같은 역할이라는 표현하셨는데 전 전혀 공감할 수 없습니다. viewmodel은 제가 탐탁치 않아 하는 구조이긴 하지만 model 의 data를 view로 추상화 해야 하는 것을 잘 이해하고 있는데 올려주신 문서에서는 전혀 보이지 않는걸요. 미뤄 짐작해보건데 4번 답변을 보니 이에 대한 이해가 부족하신 것 같습니다. 그렇지 않다면 문서에서 다루지 않았을리 없겠다는 생각이 드네요.

2. MVVM 은 MVP의 단점을 해결하기 위해서 나온 것이 아닙니다. 같은 목표인 view의 추상화를 통한 model과 view간의 커플링 해소를 위해서 나온 것입니다. 그렇기 때문에 10년 뒤에 나왔다고 해서 더 우성(?)의 것이라고 단정할 수 없습니다. MVP와 MVVM을 비유해서 표현하자면, MVP는 아이폰이고 MVVM은 안드로이드 입니다. MVP는 MVC를 혁신하고 나온 것이과, MVVM은 MVP의 연장선 상에 있는 구현 방법론이라고 생각하면 됩니다. 그리고 제가 MVVM를 마음에 들어하지 않는 이유는 viewmodel이라는 것이 재사용성이 떨어지기 때문이라고 말씀드렸습니다. 이는 호불호가 있을 수 있으므로 더 이야기 하지 않는게 좋을 것 같습니다.

3. OnAttach 를 통해 Fragment에서 기본적으로 Activity를 인자로 넘겨주기 때문에 이런 식을 취한 것입니다.

또한 Activity여야하는 한계가 있다고 말씀하셨는데 이는 틀렸습니다. OnViewRequestListener는 통신을 위한 interface입니다.  setOnViewRequestListener 메소드가 필요하다는 말씀은 넘기겠습니다.

4. adapter를 제가 비유한 이유를 오해하시는 것 같습니다.

저는 계속 view가 추상화되지 않아 model 과의 커플링이 생기는게 문제라고 말씀드렸습니다.

이를 인지시키지 못한 것은 제가 잘못한 것이므로 넘어가도록 하겠습니다.

MVVM이 MVP의 단점을 보완하기 위해 나왔다는 말은 다시 생각해보니 잘못됐네요. 말씀하신대로 단점 보완이 아니라 비슷한 문제를 해결하기 위한 새로운 형태라고 이해하는 편이 맞는 듯 합니다. 적어도 MVP가 MVVM의 단점을 보완하는건 아니라는 얘기를 하고 싶었습니다 (말씀하시는 MVVM의 단점이 재사용성 저하라는 점도 전혀 이해가 안됩니다만..) 그리고 제가 이해하는 view-model은 'view의 data를 추상화한 model'인데 'model의 data를 view로 추상화한다'는 말씀은 완전히 제가 생각한 것과는 반대네요. 일단 data를 view로 추상화한다는 개념도 잘 이해가 안되구요.

'view가 추상화되지 않아 model과의 커플링이 생겨 재사용성이 떨어진다'는 것이 핵심인 것 같은데 구체적인 예를 들어주실 수 있을까요? 제가 발표한 구조는 재사용 역시 고려하여 만들어진건데 그렇지 않다고 말씀하시니 적절한 예를 들어주세요. [지금 구조는 이러이러한 상황을 구현하기 위해서는 기존의 코드를 재사용하지 못하는데, MVP 구조에서는 재사용이 가능해진다] 이렇게요. 아무래도 원론적인 이야기보다는 구체적인 예나 코드가 쓰여있는게 이해가 빨라서요..

(그리고 3번은 통신을 위한 interface을 onAttach에서 받아서 문제가 된다는 뜻입니다. setOnViewRequestListener가 없이 activity가 아닌 다른 OnViewRequestListener 구현체를 mCallback에 setting 할 수 있나요? 또한 OnViewRequestListener를 구현하지 않은 activity는 사용이 불가능해지고. )

아, 그리고 자료에 adapter쪽 내용이 없는건 시간이 부족해서.. -_-;;

MVVM 의 재사용성 저하는 어디까지나 제 생각이므로 무시하셔도 되는 부분입니다.

굳이 설명을 하자면 MVVM에서는 View의 표현을 android로 말하자면 layout을 inflate하는 형식과 유사하게 취하는데, 저는 이와 같은 방법이 재사용성이 있다고 생각하지 않는 입장이기 때문입니다. 객체지향 까는 사람들이 재사용성에 대해서 의문을 제기하는 것과 유사한 입장이라고 생각하시면 됩니다.

저는 계속 view가 추상화되지 않아서 생기는 문제를 얘기했는데 이를 주지시켜드리지 못했으니 죄송하게 생각합니다.

예를 들어 adapter에서는 getView()에서 model의 데이터를 바인딩한 View를 리턴해주는데, 바로 이 과정을 통해 ListView와 같은 AdapterView 하위 컴포넌트들은 Model의 스키마나 데이터 변동에 대해 어떤 의존성도 없이 자기 역할을 잘 수행할 수 있게 됩니다.

Request 요청으로 변동사항이 전달될때 이를 추상화한 View로서 parentView에 추가되는 형식이 아니라 View의 구성요소에 바로 data가 set되는 형태라면 해당 view는 model의 변동사항에서 자유로울 수 없기 때문에 커플링이 생긴다고 말씀드렸습니다. 이제와 생각해보면 시간이 적어서 생략되었을 수도 있다는 생각은 들지만서도, 올려주신 문서에서 이 부분이 빠져서는 안된다는 생각이 들었기에 지적을 할 수 밖에 없었습니다.

BaseLayout의 member로 private View view; 가 있구요

constructor에서 view = View.inflate(context, layoutResourceId, null); 로 view를 inflate하고

아.. 방금 깨우쳐서 수정하러 왔더니 이미 답글이.. 감사합니다.

저랑 같은 프로세스를 타셨군요 ㅋㅋ

어 이게 뭐지? 이렇게 하면되나? 하고 나니 맞음 ㅋㅋ

넵, 큰 그림만 설명하려다보니 BaseLayout, BaseModel쪽이 생략되어있어서 발표 자료만으로는 자세하게 파악하기 어려운 점이 있습니다 ㅠㅠ; 우선 ModelListener<T extends BaseModel> 라는 인터페이스가 있고 model의 update를 감지하고자 하는 클래스는 이를 구현[onUpdated(T model);]합니다.  model 에서 update() 를 호출하면 해당 model에 등록된 model listener의 list를 돌면서 listener.onUpdated(this); 를 호출해주는 방식입니다.

아, 그리고 퐁퐁님께서 이러한 방식의 단점을  한가지 지적해주셨는데, model 자체를 넘기면 view쪽에서도 model에 상태를 변경할 수 있는 메소드를 호출할 수 있는 위험이 있다는 점이었습니다. (예: fetch()) 이를 해결하기 위해서는 onUpdated(..) 메소드의 parameter를 해당 model이 아닌 해당 model에서 data만 가져오는 interface로 하면 됩니다. interface를 하나 더 선언해야한다는 번거로움이 trade-off 입니다.

참고가 되길 바랍니다~

로쓰님. 안드로이드 초보개발자입니다.

마플님과 로쓰님을 댓글내용은 초보인 저는 이해를 도통 모르겠네요 ㅠㅠ

저도 들은 얘기로  개발할때 mvc 패턴으로 개발한다고 들었는데 님 댓글은  mvc 패턴의 보안책으로  mvp가 더 낫다는건가요? ㅠㅠ

어떤 패턴이 낫다는건지 말씀해주실수 있나요? ㅠㅠ..주고받는 댓글 내용이 너무 어렵네요.