ソフトウェア開発メモ

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

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

 オブジェクトの責務*1は職場社会同様、周りの環境によって決まる。

 例えば、iOSが提供する各クラスのメソッドは典型的なアプリの用途を想定して公開している(はず)。しかし、アプリ開発ではそれでは足りないケースが多々有る。その場合にカテゴリーを使ってメソッドを追加する。

 つまりアプリという特定の職場社会に特化したサービスを提供するようにメソッドを追加するのである。この感覚がクラスの責務という本来の意味にしっくりくるかと思う。始めに戻るけど責務は周りの環境によって変わる。環境とはアプリ、使うフレームワーク等等である。

 ついでに。カテゴリー自体はSmalltalk由来の機能である。Smalltalkは自分で好き勝手にシステムを拡張する形でプログラミングする事を考えればこの考えは間違ってないと思う。

*1:ここでいう責務は他のオブジェクトに対して提供するサービス(=メソッド、プロパティ)として定義する。

API調査の注意点

 良い設計するには、優れた設計を調査、研究するのが一番です。

で、優れた設計というとアップルやマイクロソフト等のAPIOSS等が対象になるとおもうですが、その場合の私なりの注意点として、一つだけ軽く?あげます。

 いわゆるAPIというものは汎用的な用途のために作られているので、公開されているメソッドが多い。したがって、一つのアプリ内でしか使わないライブラリやフレームワークを設計する場合は、これらのAPIをそのまま参考にせずに、最低限必要なメソッド、プロパティだけ公開する事。

例えば、UITableViewCellには各Viewがぶら下がっていて、自由にアクセスできます。ただ、通常、アプリで使う色やフォントは決まっているので、丸ごとViewを公開するケースは少ないはずです。

 経験で言うと、アプリ内で使い回すViewクラスやサービス的なクラスのメソッド数、大抵は5以下、 多くて10以下ぐらいなると思います。

モデルと実装を結びつける。

DDDの読書会?です。

実装時にもドメインモデルを維持するようにします。熟練のオブジェクト指向プログラマーもクラスに属性やメソッドを追加する毎にクラス名の適切さやクラス構成が適切かをチェックします。ただ、これは言葉でわかっていても難しいです。

ついつい部分最適を指定してしまう。個人的にも修正をしくじったり、ソフトウェアの構造が歪みはじめるのはクラス図、オブジェクト図を書かずに部分最適、コーディングで直してしまった場合でした。

というわけで、破綻の危険性を感じた時、モデルレベルまでもどって考え直す必要があるのですが、再度言いいますが改めて難しい。サッカー戦術のように?モデル〜コードの切り替えを体で覚える必要があります。

なお、DDDではUMLツールのラウンドトリップ機能を使って行えば便利と言っているようです。

依存、シングルトン、隠れインスタンス変数

メソッド中でインスタンス変数が毎回生成される形で関わりあいを持つクラスは関連ではなく依存になる。なぜならばその生成する方のの状態に影響を与えないからだ。

しかし、それがシングルトンとなると話は変わる。呼ばれる時にそのシングルトンがどういう状態かわからないからだ。

シングルトンを呼び出す時は、実質関連として機能しているか否か注意しないといけない。

オブジェクトの責務について

オブジェクト指向についてよく言われる責務について、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 child care.

訳すると「何かを扱ったり、誰かをコントロールする義務を持つ状態。」。

クラスでいうとバリューオブジェクトを扱ったり、コラボラレータに指示を与える義務ということだろう。

そこに機能を示す意味はないと思う。ロールと責務の違いはそこにある。

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

 作るドキュメントは最小限にしようというのは、アジャイル系プロセスの考え方ですが ドメイン駆動では正確な指針を提供しています。。

  • ドキュメントはコードや会話での表現を補うために作る

    • 既にコードで表現できているものは書かない。まあ、綺麗に設計実装する必要がありますね。少なくともぱっとソースを読んで即答できる形で。。。
  • ドキュメントはプロジェクト進行の役にたつもので、最新の状態をを常に保ち続ける事。

    • 既にドキュメント更新は開発プロセスに取り込む必要があります。基本設計書はどうするんだろう? OSSによくついているピラ一枚程度ので十分かな?

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

ドメイン駆動設計の勉強です。

開発側で統一するのはもちろんの事、ドメインエキスパートと開発側で一つ用語を使います。さすがにクラス名やメソッド名とかに使う英語は使わないと思いますが。

ただ、以下の理由で現実には難しいかな?

  • (設計、実装の段階において)開発者のスキルによっては英語の意味する所が全く分からない。

  • ドメインエキスパート(会社でいう企画や顧客)が用語を縛られるのを嫌う。

それでもできるだけ合わす事が重要かなと思います。教科書的なオチですが。