ライブラリを使わずにMV*の話(iOS)〜MVC, MVP, MVVM〜
話すこと アプリの責務の分け方 Model アプリ内で扱う状態・値を持つ Modelの外から指示を受け処理を行う 状態・値の変化をModelの外へ間接的に知らせる View/Whatever 画面の構築/表示 ユーザー操作の受付 アクションを定義する アクションの結果/途中経過を受け取る 内部表現を視覚表現へ変換する MV* の種類 View/Whatever間での仕事の分け方は複数ある (Model-View-Whatever 間の接続の仕方も複数ある) 分けた後のクラス連結の仕方 Commandパターン(直接指示する) Observerパターン(間接的に通知する) 対象読者 Fatなクラスを作りがちで困っている人 責務の分け方にはどういうものがあるのか知りたい人 分け方と分けた後のクラス間の接続がわからず困っている人 話さないこと ■ MV*の歴史的経緯 理由: どれが正史か判断する手
最近のアプリ界隈での「設計」の違和感 - なるようになるかも
アプリ界隈で「設計」の話をするときに MVC / MVP / MVVM のような「設計パターン」だけが語られるようになった気がする。 往々にして、「アプリの規模によってどれを採択すべきかは変わる」みたいなお茶を濁すような結論で終わることが多い。 私的な結論 「設計」と、「設計パターン」は別物だと思う。 「設計」のレベルを上げたい。 アーキテクチャシンドロームから抜け出して、価値のあるものを作りたい。 以下、思うところのメモ。 MVC は古い / 劣ったやり方か？ MVC は Model をどう構築するかについてとくに規定していない。 MVC への批判をするときに、FatVC が持ち出されることが多いのですが、FatVC を実装してしまうのは単に実装者の能力不足だと考えていて、MVVM を採用しても FatVM を作るだけだと思っている。 また、比較的新しめの Flux アーキテクチャは、良
RxSwift+CleanArchitectureで構成をキレイにしよう - Qiita
はじめに アプリケーションを開発しリリースした際に、当初は問題なくても時が経つにつれて綻びが出てきます。 仕様変更や機能追加やリファクタリングができない(後回しにしたまま)、開発に携わる人の理解や嗜好による統一感の喪失などなど。 そうするとこんなことが起きることもしばしば。 ViewControllerの肥大化 責任範囲がぶれたクラスの誕生 Model/Helper/Libraryが人の解釈に依存するディレクトリ・ファイルの散見 ViewModelとModelの扱いがごっちゃになっている こうなるとどんどん作りが複雑化し、気が付くと負の遺産が出来上がっています。 メンバーの理解度を上げる、チーム内でルールを決めるという解決する手もあるのですが できればもう少し役割がはっきりしていて、共通認識持ちやすいアーキテクチャがないかなーと思っていてたところ…それはありました。 それがCleanArc
モバイルアプリアーキテクチャ勉強会 - Qiita
public class MainActivity extends Activity { @Override public void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.activity_main); Log.d(msg, "The onCreate() event"); } } つまり M-VC iOS も Android も View と Controller がまとめられてる M-VC なコードになる Model, ViewController という関係性 テストがかけない... だから設計談義が盛り上がる アーキテクチャを導入する目的 保守性の高いコード FatController にしない テストのかきやすい構成へ 考え
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
