ソフトウェア開発メモ

日々のソフトウェア設計、実装で考えている、気づいた事を書いています。それが真実か否かは保証しません。悪しからず。

iPhone 6を買ってよかったが未だどうか悩んでいる。

iPhone 6を買ってよかったが未だどうか悩んでいる。 経緯はこうだ。 iPhone 6を購入した。 やはり大きい。 iPhone 5sに戻す。やはり、小さい方が使い易い。 しかし、電車の中では本を読みたいが満員電車の中でiPad miniはでかい。 仕事でNexus 5にストラップ…

iPhone6とアルミフレーム購入検討〜要求獲得の難しさ。

iPhone6をまだ買っていない。理由はアルミフレームが出揃っていないからだ。 幾つ出ているがネットで眺めてもいいか悪いかわからない(以前買って失敗したし)。 色々店に出向いて眺めると質感がいいか、かっこいいか?悪いかがある程度わかる。 ただ、実物に…

Swiftにみるモデル駆動開発の将来

UMLツールや一頃流行った?MDAという技術にモデルからコードを自動生成というのがある。 効率云々はともかく、オブジェクト指向開発に習熟していくと、クラス構成とコーディングを自由に行き来したくなってくる。 で上記のモデル駆動ツールであるが、結局は…

オブジェクト指向のデータ構造的意味論。

オブジェクト指向(というか抽象データプログラミング。そう言い方はしないのでオブジェクト指向)はクラス(ネーティブ型もここではクラス)を秩序を保ってまとめ上げて新しいクラスを作り上げるにすぎない。 それらがいろいろ再帰的に合成されて、基盤ライ…

スモールオブジェクトプログラミングについて〜クラスはより小さくする

はじめに SmalltalkerのケントベックやThoughtWorksの中の人が暗に提唱し、最近いろんな識者がネットや本で語っている*1*2、バリューオブジェクト、小さな部品、小さなクラス、小粒クラス、粒度の小さいクラス、スモールオブジェクトプログラミングと言われ…

条件分岐とメッセージパッシングの差異について。移譲型制御についての考察の続き

オブジェクト指向プログラミングはオブジェクト間の通信によって世界が構築される。 上から降ってくる仕事は、小さなタスクに分割されてどんどん包含されているオブジェクトに移譲される。 一方、If文の使用はオブジェクト指向プログラミングで良くないとさ…

クラス、パブリックメソッドのコメントを書く基準について調べた。

いろんなOSSを調べた結果です。 ・アプリの場合はクラス記述ぐらいしか書かない。使い方の自由度が限定されているので。 ・世に公開された汎用的なフレームワークはコメントをきっちり書く。まあ、使い方の自由度が高いし、公開されているメソッドが多い、内…

(Objective-Cの)カテゴリーと責務

オブジェクトの責務*1は職場社会同様、周りの環境によって決まる。 例えば、iOSが提供する各クラスのメソッドは典型的なアプリの用途を想定して公開している(はず)。しかし、アプリ開発ではそれでは足りないケースが多々有る。その場合にカテゴリーを使っ…

API調査の注意点

良い設計するには、優れた設計を調査、研究するのが一番です。 で、優れた設計というとアップルやマイクロソフト等の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…

書かれた設計ドキュメント

作るドキュメントは最小限にしようというのは、アジャイル系プロセスの考え方ですが ドメイン駆動では正確な指針を提供しています。。 ドキュメントはコードや会話での表現を補うために作る 既にコードで表現できているものは書かない。まあ、綺麗に設計実装…

1つのチームに1つの言語

ドメイン駆動設計の勉強です。 開発側で統一するのはもちろんの事、ドメインエキスパートと開発側で一つ用語を使います。さすがにクラス名やメソッド名とかに使う英語は使わないと思いますが。 ただ、以下の理由で現実には難しいかな? (設計、実装の段階に…

単一責務とクラス分割〜分割と振る舞いのチューニング

クラス合成とタスク合成 - 概念構築メモ クラス合成とタスク合成 - 概念構築メモ のつづき 最近、クラスは可能な限り細かく分けるべき方向に変わって来た。所謂、スモールオブジェクトプログラミングとかいう奴ですな。 ただ当たり前だけど、それだと何処か…

依存と関連について

関連(集約もそうだけど)、インスタンス変数を持つ事によって示される。 依存は引数経由のみで関わる場合が該当する。後、メソッドの内部で生成されて関わりを持たずに消滅するクラスも依存関係に属する。 関連はクラスの一部そのものでその状態をつかさどる…

クラス合成とタスク合成

昔、組み込みやっていて組み込み系の設計技法については多少知っているいるけど、その中の一つにタスク合成という手法がある。具体的にはリアルタイムOSでの設計ではタスクを分ける事によって並列処理を行なうが、逆にタスクを分けすぎると各タスクの構造化…

オブジェクトデザイン 3.5 候補を記述するについて

引き続き読書、オブジェクトデザイン 3.5 候補を記述するについてです。 名前とロールの実際の役割の整合性について評価します。ステレオロールタイプを当ててクラス候補を性格づけてみます。ステレオロールタイプについてですが、厳密に従う必要性はなくあ…

ドメイン駆動設計「声に出してモデリングする。」

モデリングに限らず言語化するのは需要。書籍「UMLセルフレビューノート」や「ストリームラインオブジェクトモデリング」でも声に出す事を奨励している。 関係ないけど、このブログも色々駄文を書いて曖昧にしていた事が色々理解できた。ただ、声に出しては…

UIViewとUIViewControllerの役割分担

はじめに UIViewとUIViewControllerの役割分担は難しいと思います。全部UIViewControllerに仕事させると UIViewの再利用性が著しく下がったり、UIViewに全部仕事を任せると連携が複雑になったり。 まあ、自分視点でざっと整理してみます。 UIViewのお仕事 簡…

ドメイン駆動設計、読書

ドメイン駆動設計のユキビタス言語の所を読んだ結果です。 ドメインモデルとメンバーとの間で使う用語を合わせる。 モデルをユキビタス言語の骨格に使う。 使うユキビタス言語が変わる場合、ソースをリファクタリングする。 ユキビタス言語が変わる場合、モ…

責務駆動設計:オブジェクトの命名方法

引き続きオブジェクトデザインです。 クラス名は大事です。クラス名によってどういう知識と行動を持たせるべきかが理解できます。また、 クラス名を言葉につねに表現する事によってどういう役割を果たすべきか自覚するようになります。 ただ、これが難しい。…

責務駆動設計:オブジェクトの発見方法

オブジェクトデザインの第3章 オブジェクトを見つけるについてです。 設計ストーリー 以下の観点で設計ストーリーを書きます。 ユースケース、要求、アーキテクチャ、ユーザー、予算責任者等様々な視点 アプリケーションが行なうべき事。 アプケーションで…

ドメインモデル貧血症について、その後&その後

ドメインモデル貧血症についてのその後 - 概念構築メモ ドメインモデル貧血症についてのその後 - 概念構築メモ エンティティデータの変換問題について突き詰めて行くと。 まず、外部システムが扱うデータへの変換 モデル⇔ネットワーク(あるいは別システム) …

制御型スタイルについて。集中型と委譲型のバランスを取る。締める時には締める管理職

「オブジェクトデザイン」の第6章、制御スタイルを読んだ感想です。 6.2制御スタイルの選択肢の記述、「実際は集中型、委譲型、分散型のスタイルを結ぶ何れかに解決策があります〜」について。 部下の管理とおなじで単に仕事を委譲させるだけでは緊急時等、…

Bridgeパターンについて再考

最も使えそうなパターンの割に、いままで誤解していたBridgeパターンについていろいろ可能性を探ってみます。 まず、図のようにAbstractionがImplementorの差し込み以外全部ファイルメソッドかつImplementorの具現クラスが全部ファイナルクラスの場合は継承…

3階層の継承関係を見直す〜実はBridgeパターンだった。

3階層の継承関係を見直す - 概念構築メモ 3階層の継承関係を見直す - 概念構築メモ について。 改めて勉強し直すとブリッジパターンですね。GOF本の例ではXウィンドウやらMacやらの違いを吸収するフレームワーク云々書いていたので、プラットホーム依存層…

ドメインモデル貧血症についてのその後

iOSアプリでのドメイン貧血症について - 概念構築メモ iOSアプリでのドメイン貧血症について - 概念構築メモ のついて悩みに悩んで、とある開発会社のコラムに似たような事が書いてあった。端的にいうとこれ。 モデル⇔ビュー、モデル⇔ネットワーク、モデル⇔R…

オブジェクトの循環参照について

クライアント/サーバーの関係で考えてみると理解しすい。 直接呼び出す場合だとクライアント側のインスタンス変数及びプライベートメソッドを公開するか、サーバーから呼ばれるメソッドを作るらざるえない。 1に関連して、メソッドを的確に定義できるならオ…

ファクトリーメソッドを積極的に作る。

オブジェクトの生成処理は長くなりがちです。1箇所だけしか呼ばれていないのに作るのは過剰設計じゃないかと思っていた時期も有りましたが、ドメイン駆動設計等、いろいろ文献等を読みあさった結果、以下の理由により、それでもファクトリーメソッドとして…