iPhone 6を買ってよかったが未だどうか悩んでいる。 経緯はこうだ。 iPhone 6を購入した。 やはり大きい。 iPhone 5sに戻す。やはり、小さい方が使い易い。 しかし、電車の中では本を読みたいが満員電車の中でiPad miniはでかい。 仕事でNexus 5にストラップ…
iPhone6をまだ買っていない。理由はアルミフレームが出揃っていないからだ。 幾つ出ているがネットで眺めてもいいか悪いかわからない(以前買って失敗したし)。 色々店に出向いて眺めると質感がいいか、かっこいいか?悪いかがある程度わかる。 ただ、実物に…
UMLツールや一頃流行った?MDAという技術にモデルからコードを自動生成というのがある。 効率云々はともかく、オブジェクト指向開発に習熟していくと、クラス構成とコーディングを自由に行き来したくなってくる。 で上記のモデル駆動ツールであるが、結局は…
オブジェクト指向(というか抽象データプログラミング。そう言い方はしないのでオブジェクト指向)はクラス(ネーティブ型もここではクラス)を秩序を保ってまとめ上げて新しいクラスを作り上げるにすぎない。 それらがいろいろ再帰的に合成されて、基盤ライ…
はじめに SmalltalkerのケントベックやThoughtWorksの中の人が暗に提唱し、最近いろんな識者がネットや本で語っている*1*2、バリューオブジェクト、小さな部品、小さなクラス、小粒クラス、粒度の小さいクラス、スモールオブジェクトプログラミングと言われ…
オブジェクト指向プログラミングはオブジェクト間の通信によって世界が構築される。 上から降ってくる仕事は、小さなタスクに分割されてどんどん包含されているオブジェクトに移譲される。 一方、If文の使用はオブジェクト指向プログラミングで良くないとさ…
いろんなOSSを調べた結果です。 ・アプリの場合はクラス記述ぐらいしか書かない。使い方の自由度が限定されているので。 ・世に公開された汎用的なフレームワークはコメントをきっちり書く。まあ、使い方の自由度が高いし、公開されているメソッドが多い、内…
良い設計するには、優れた設計を調査、研究するのが一番です。 で、優れた設計というとアップルやマイクロソフト等のAPI、OSS等が対象になるとおもうですが、その場合の私なりの注意点として、一つだけ軽く?あげます。 いわゆるAPIというものは汎用的な用途…
DDDの読書会?です。 実装時にもドメインモデルを維持するようにします。熟練のオブジェクト指向プログラマーもクラスに属性やメソッドを追加する毎にクラス名の適切さやクラス構成が適切かをチェックします。ただ、これは言葉でわかっていても難しいです。 …
メソッド中でインスタンス変数が毎回生成される形で関わりあいを持つクラスは関連ではなく依存になる。なぜならばその生成する方のの状態に影響を与えないからだ。 しかし、それがシングルトンとなると話は変わる。呼ばれる時にそのシングルトンがどういう状…
オブジェクト指向についてよく言われる責務について、Mac付属の英英辞典で調べると以下の意味がある。 the state or fact of having a duty to deal with something or of having control over someone: women bear children and take responsibility for ch…
作るドキュメントは最小限にしようというのは、アジャイル系プロセスの考え方ですが ドメイン駆動では正確な指針を提供しています。。 ドキュメントはコードや会話での表現を補うために作る 既にコードで表現できているものは書かない。まあ、綺麗に設計実装…
ドメイン駆動設計の勉強です。 開発側で統一するのはもちろんの事、ドメインエキスパートと開発側で一つ用語を使います。さすがにクラス名やメソッド名とかに使う英語は使わないと思いますが。 ただ、以下の理由で現実には難しいかな? (設計、実装の段階に…
クラス合成とタスク合成 - 概念構築メモ クラス合成とタスク合成 - 概念構築メモ のつづき 最近、クラスは可能な限り細かく分けるべき方向に変わって来た。所謂、スモールオブジェクトプログラミングとかいう奴ですな。 ただ当たり前だけど、それだと何処か…
関連(集約もそうだけど)、インスタンス変数を持つ事によって示される。 依存は引数経由のみで関わる場合が該当する。後、メソッドの内部で生成されて関わりを持たずに消滅するクラスも依存関係に属する。 関連はクラスの一部そのものでその状態をつかさどる…
昔、組み込みやっていて組み込み系の設計技法については多少知っているいるけど、その中の一つにタスク合成という手法がある。具体的にはリアルタイムOSでの設計ではタスクを分ける事によって並列処理を行なうが、逆にタスクを分けすぎると各タスクの構造化…
引き続き読書、オブジェクトデザイン 3.5 候補を記述するについてです。 名前とロールの実際の役割の整合性について評価します。ステレオロールタイプを当ててクラス候補を性格づけてみます。ステレオロールタイプについてですが、厳密に従う必要性はなくあ…
モデリングに限らず言語化するのは需要。書籍「UMLセルフレビューノート」や「ストリームラインオブジェクトモデリング」でも声に出す事を奨励している。 関係ないけど、このブログも色々駄文を書いて曖昧にしていた事が色々理解できた。ただ、声に出しては…
はじめに UIViewとUIViewControllerの役割分担は難しいと思います。全部UIViewControllerに仕事させると UIViewの再利用性が著しく下がったり、UIViewに全部仕事を任せると連携が複雑になったり。 まあ、自分視点でざっと整理してみます。 UIViewのお仕事 簡…
ドメイン駆動設計のユキビタス言語の所を読んだ結果です。 ドメインモデルとメンバーとの間で使う用語を合わせる。 モデルをユキビタス言語の骨格に使う。 使うユキビタス言語が変わる場合、ソースをリファクタリングする。 ユキビタス言語が変わる場合、モ…
引き続きオブジェクトデザインです。 クラス名は大事です。クラス名によってどういう知識と行動を持たせるべきかが理解できます。また、 クラス名を言葉につねに表現する事によってどういう役割を果たすべきか自覚するようになります。 ただ、これが難しい。…
オブジェクトデザインの第3章 オブジェクトを見つけるについてです。 設計ストーリー 以下の観点で設計ストーリーを書きます。 ユースケース、要求、アーキテクチャ、ユーザー、予算責任者等様々な視点 アプリケーションが行なうべき事。 アプケーションで…
ドメインモデル貧血症についてのその後 - 概念構築メモ ドメインモデル貧血症についてのその後 - 概念構築メモ エンティティデータの変換問題について突き詰めて行くと。 まず、外部システムが扱うデータへの変換 モデル⇔ネットワーク(あるいは別システム) …
「オブジェクトデザイン」の第6章、制御スタイルを読んだ感想です。 6.2制御スタイルの選択肢の記述、「実際は集中型、委譲型、分散型のスタイルを結ぶ何れかに解決策があります〜」について。 部下の管理とおなじで単に仕事を委譲させるだけでは緊急時等、…
最も使えそうなパターンの割に、いままで誤解していたBridgeパターンについていろいろ可能性を探ってみます。 まず、図のようにAbstractionがImplementorの差し込み以外全部ファイルメソッドかつImplementorの具現クラスが全部ファイナルクラスの場合は継承…
3階層の継承関係を見直す - 概念構築メモ 3階層の継承関係を見直す - 概念構築メモ について。 改めて勉強し直すとブリッジパターンですね。GOF本の例ではXウィンドウやらMacやらの違いを吸収するフレームワーク云々書いていたので、プラットホーム依存層…
iOSアプリでのドメイン貧血症について - 概念構築メモ iOSアプリでのドメイン貧血症について - 概念構築メモ のついて悩みに悩んで、とある開発会社のコラムに似たような事が書いてあった。端的にいうとこれ。 モデル⇔ビュー、モデル⇔ネットワーク、モデル⇔R…
クライアント/サーバーの関係で考えてみると理解しすい。 直接呼び出す場合だとクライアント側のインスタンス変数及びプライベートメソッドを公開するか、サーバーから呼ばれるメソッドを作るらざるえない。 1に関連して、メソッドを的確に定義できるならオ…
オブジェクトの生成処理は長くなりがちです。1箇所だけしか呼ばれていないのに作るのは過剰設計じゃないかと思っていた時期も有りましたが、ドメイン駆動設計等、いろいろ文献等を読みあさった結果、以下の理由により、それでもファクトリーメソッドとして…
はじめに 名前のとおり何かを供給するクラスです。というかプロトコルが多いです。〜erの名前のとおり役割系のクラスだからかな? NSItemProvider UIActivityItemProvider IKFilterCustomUIProvider NSTextLayoutOrientationProvider QCPlugInOutputImagePro…