MVP化が完了しました。
工程記録も7回目になってしましましたが、無事に目的であったMVPアーキテクチャへの移行を完了させる事ができました。
という訳でfeature-MVPブランチをmasterへMergeさせたPRは以下になります。
前回の記事ではスワイプ削除をMVP化を完了させましたが、残りのリスト入れ替え機能はこちらのコミットにて実装させました。(ついでにPrimaryKey生成時のbugも潰してます)
ビフォー & アフター
ではせっかくなのでMVP化対応前と対応後のUML図を比べてみましょう。
まずは工程記録・1で公開した最初のUML図になります。
FragmentでがっつりRealmDBを操作していたあの頃が懐かしいですね。
そしてこちらがMVP化対応後のUML図です。
ひと目でクラスが随分と増えた感がありますが、注目したいのが
PersonRealmHelper を操作しているのが PersonRepositoryという点です。
Fragmentは担う仕事はViewのイベントを拾う事と、Adapterへとリストデータを受け渡すだけに専念しました。もう、DB操作をする事はないのです。
指揮者・Presenter
もう一点、新しい登場人物がいます。PresenterはViewが拾ったイベントをRepositoryがどんなDB操作をするべきか、指揮してあげます。RepositoryはあくまでPresenterの要求に従ってデータの追加や削除を行うのに専念するのです。
MVP化を行った事によって、それぞれの仕事が明確に分割されるようになりました。
そして忘れてはいけないのがContract interfaceです。
public interface PersonContract {
interface Presenter {
}
interface View {
}
interface Model {
}
MVPで仕事は分割されましたが、あくまでも一連の機能を分割しているだけです。
PersonContractでグルーピングすることによって、一つの機能である事を明示的に実装させているのです。
終わりに
全七回に渡り、リスト表示するという一つの機能を、MVPアーキテクチャ化する工程を説明してきました。
そもそもが自分の記録のために始めた本記事でありますが、
「どうやってMVP化を進めたらいいか分からない」、「MVP化の利点が分かりにくい」
といった方の助力にもなれば幸いです。
MVP化工程記録は今回で終わりますが、日記アプリの制作は続けていきますので
また別のシリーズが始まるかもしれません。
終始RealmDBにかき乱された事もいい勉強になりましたが、
RxJavaでの実装は行わなかったので、今後はそこらへんが記事になる可能性もあります。
何はともあれ、ここまで読んで頂きましてありがとうございました！