フロントエンドのつくりかた
フロントエンドの特定技術について語る解説は多くあれど、そもそもフロントエンドのつくりかたについて語った解説は多くないのではないでしょうか。 フロントエンドという大きな領域ですので恐れ多くもありますが、私が GUI プログラミングに携わった経験をもとにお話した内容のスライドとその補足をここでしたいと考えます。 スライド スライドのページ数は多いですが、差分がほとんどですので、それほど構える必要はないです（カーソルキーに負担がかかるという問題を除いて）。 補足解説 大きなテーマごとに補足をしていきます。 スライドで取り上げているテーマは次の４つです。 GUI アーキテクチャパターン データの同期 エラーハンドリング コンポーネント構造 「GUI アーキテクチャパターン」はいわゆる MVC や MVP といわれるものがどういったものかを解説する章です。 「データの同期」は画面と実際のデータが離れ
ライブラリを使わずに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 アーキテクチャは、良
DCI (data context interaction)
DCI アーキテクチャという設計についての考え方がある。数年前から scala 界隈で盛り上がっていた記憶があるが、最近は ruby/rails 界隈でも盛り上がっている模様。 先日の札幌 ruby 会議で角谷氏が発表を行っている。 rubykaigi http://sapporo.rubykaigi.org/2012/ja/schedule/details/79.html スライド http://kakutani.com/20120916.html#p01 そこからたどって以下のような資料があるのも発見した。 objects on rails （書籍の無料公開) http://objectsonrails.com/ Clean Ruby http://clean-ruby.com/ 書籍サイト。ベータ版書籍が購入可能。$42なので電子書籍にしてはかなり高い。 DCIの講演 tog
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ページを開く
