2017年2月8日水曜日

オブジェクト指向を活かすための戦略 ~ 文章的プログラミング

 オブジェクト指向らしい設計や実装をするための第一歩は、命名にあると私は考える。

名前は?
名前は?

 開発環境が未成熟の頃、タイピング量を減らすためにこんな変数名をつけたことはないだろうか?

 dKeiyaku

  これは契約日を示すものと思われるが、確認するためには命名規約等を参照しなければならない。しかし、

 契約日

 となっていれば、他のものを参照しなくても変数の意味を理解することができる(もちろん、追加のコンテキストが必要な場合もある。例:賃貸借契約日、売買契約締結日)。このような意味のある言葉、業務で使われている言葉で命名することは、オブジェクト指向を活かすための基礎である。特に、パッケージ名、クラス名、プロパティ名、メソッド名は、命名についてしっかりと検討する必要があり、この検討とは設計そのものである。

 具体例を見てみよう。

 ①
 ColSyohin.Zaiko(Syohin)
 ColSyohin.KakakuUpdate(KakakuUpdateList)
 ColSyohin.Add(Syohin)

 ②
 販売情報.在庫数(商品)
 販売情報.価格を変更する(価格変更リスト)
 販売情報.追加する(商品)
 
 ③
 取扱商品.在庫数(商品)
 取扱商品.価格を変更する(価格変更リスト)
 取扱商品.追加する(商品)

 上記の違いが名前だけだとすると、機能要件はいずれも満たしているわけだが、わかりやすく表現されているものはどれだろうか? あるいは、業務の言葉で表現されているものはどれだろうか?
 ①は古き時代の作法であり、今日的ではない。
 ②はそう悪くはないが、「追加する」メソッドが販売情報に何を追加するのかメソッド名だけでは分からない。
 ③はどれも適切な情報を名前から読み取ることができる。

 私の場合は、実際のコードも日本語で命名しているが、このような命名方針によって設計・実装すると、クラスは機能的凝集度を高める方向に自然と向かうはずだ。なぜならば、そのクラスに実装することが不適切なデータやロジックが不自然な文脈として表れてくるからだ。

 取扱商品.本日の売上金額

 取扱商品の責務が売上金額の集計というのは不自然だ。販売された商品とその代金が売上伝票に記録されるのならば、売上伝票のコレクションクラスが売上金額の集計責務を負うべきだろう。例えば、売上帳簿、販売台帳など、実際に業務で使用されている言葉があるはずだ。

 売上帳簿.本日の売上金額

0 件のコメント:

コメントを投稿