ReSwiftのサンプルコード程度であれば、RxSwiftの機能を使って自前で実装ができてしまうのでは、と考えたので実際にやってみました。不必要に依存ライブラリを増やしたくないという気持ちがモチベーションとなっています。まずは ReSwift のサンプルコード的なものを確認するところから始めます。
ちなみにこの記事は ReSwift を使い始めて数時間の人間が書いているので、間違っている可能性が大いにあります。嘘を嘘と見抜きながら読んでいただけると幸いです（そして、コメント欄で刺してください）。
Redux の Swift 実装らしいです。そもそも Redux がよくわからないのですが、そんなものわかってなくても動くコードはかけそうでした。ということで、とりあえずコードを書いて読んでから、小難しい記事を読んで理解してく方針にして、Redux および ReSwift の解説は他の記事に譲ります。 ...
Read MoreModel-View-Controller に分離するパターンを見ていくが、クラスに分割するだけが分離に相当するわけではない
MSDNの記事がわかりやすかったのでまとめた
**Single Responsibility Principle（単一責任の原則）**は、Tom DeMarco の "Structured Analysis and Systems Specification" と、Meilir Page-Jones の "The Practical Guide to Structured Systems Design" で説明されている。この原則は次のようなものだ。
クラスを変更する理由は複数存在してはいけない
役割が単一なクラスの仕様要求が変化した場合、その変更部分は浮き彫りになり、どのように変化したのかわかりやすい。これは、ほとんどの人が納得するはなしではないだろうか。
しかし、役割が複数あると、その 1 つ 1 つが変更理由になってしまう。複数の変更理由によってクラスが変更されると、変更部分がぼやけてしまう。また、ある理由により変更した部分が、他の役割に影響してしまい、連鎖的に変更が必要になるなどといったケースが生じうる。これは もろい設計 にあてはまる。もろい設計がソフトウェア開発に...
Read MoreSOLID原則良いなぁ（←適当）...と思いつつ、それが書かれているアジャイルソフトウェア開発の奥義を読んでいなかったので、最近ちらちらと読み始めた。開発プロセスのあたりにはあんまり興味がわかないので、さらさらと軽い感じに読み飛ばしている。開発プロセス関連のはなしはなるほどなぁとは思うし、全員が内容を理解した上でやっていくと意味はありそうなんだけど、現実的にそんなことは起こり得ないと思っていて、学習コストが必要になる開発プロセスに意味はあるのか...とか偉そうなことを思っている。まあそんなことはどうでもよくて、第２部からのアジャイル設計の部分は本当に参考になるなぁ...と思いながら読んでる。
注意：この文章はポエムです
本によると、アジャイルはソフトウェアを少しずつ開発する手法だそうだ。基本的にラビットハウスでは完成させたソフトウェア（完成とは...という話になるが）を納品するようなお仕事ではなく、ソフトウェアを少しずつ拡張していくスタイルなので、まさに合致している。
UIの相互作用を3つの明確な役割に分割するパターンを「モデルビューコントローラ」とよぶ。
<img src="http://53ningen.com/wp-content...
Read Moreウェブブラウザベースのユーザーインターフェースには、特別なクライアントソフトウェアをインストールしなくてよい、UIに対して共通のアプローチをすることができる、世界中からの...
Read Moreレイヤ化は、複雑なソフトウェアのシステムを分割するために使用される技法です。コンピュータの構造やネットワ...
Read Moreウェブ界隈でエンジニアとして労働活動に励んでいる @gomi_ningen 個人のブログです。