オブジェクト指向とコモンセンス
はぶにっき [Java]教えてとよろしくより
--
伝票はしゃべらないし飛ばないよ(w 椅子は歩いたりしないよ。パッシブリソースとアクティブリソースの区分けをしないと、何でも生命持っちゃうから話がややこしくなるだけです。
--
ビール瓶とビールの例題で、ビール瓶クラスに「あといくらビールが入っているか問い合わせる機能」を追加しよう、なんてのは本で読んだ気がする。
このモノを主役としてしまう考え方は、オブジェクト指向ではわりと一般的のようだ。仮想的な部品が能動的に強調して動くということを考えると、エンジニア的になんとなくいい感じがする。
しかし、職場でチームでプログラムをしている時に果たして、顧客や上司やチームメンバに正しく気持ちが伝わっているか、と言われると甚だ疑問に思う。
プログラムというのものは、勝手にルールを決めてしまえば、何でもできてしまうため、ある程度現実世界に即した設計を心がけないと、いろんな人の概念が混ざってしまい、本質的に理解できないソフトウェアになりかねない。
その意味で、伝票は自分で計算するよりも、誰かに渡して計算してもらうような設計の方が万人にわかりやすい。少し冗長かもしれないが、顧客にも仕様を理解してもらいやすいほうが、後戻りも少なくなると考えられる。
これがゲームプログラムだったら、伝票が飛んだり、椅子が歩いたりしてもなんの問題もないわけだが。ソフトウェアの設計もTPOを考えないとだめだ、ということなのかもしれない。
--
伝票はしゃべらないし飛ばないよ(w 椅子は歩いたりしないよ。パッシブリソースとアクティブリソースの区分けをしないと、何でも生命持っちゃうから話がややこしくなるだけです。
--
ビール瓶とビールの例題で、ビール瓶クラスに「あといくらビールが入っているか問い合わせる機能」を追加しよう、なんてのは本で読んだ気がする。
このモノを主役としてしまう考え方は、オブジェクト指向ではわりと一般的のようだ。仮想的な部品が能動的に強調して動くということを考えると、エンジニア的になんとなくいい感じがする。
しかし、職場でチームでプログラムをしている時に果たして、顧客や上司やチームメンバに正しく気持ちが伝わっているか、と言われると甚だ疑問に思う。
プログラムというのものは、勝手にルールを決めてしまえば、何でもできてしまうため、ある程度現実世界に即した設計を心がけないと、いろんな人の概念が混ざってしまい、本質的に理解できないソフトウェアになりかねない。
その意味で、伝票は自分で計算するよりも、誰かに渡して計算してもらうような設計の方が万人にわかりやすい。少し冗長かもしれないが、顧客にも仕様を理解してもらいやすいほうが、後戻りも少なくなると考えられる。
これがゲームプログラムだったら、伝票が飛んだり、椅子が歩いたりしてもなんの問題もないわけだが。ソフトウェアの設計もTPOを考えないとだめだ、ということなのかもしれない。