■

オブジェクト指向のプログラミング。
大抵の本では小難しくかかれている。
たまに本に目を通すと、
(;´-`).。oO(オブジェクト指向ってなんなんだろ・・・)
っと迷ってしまうことがある。

ぶっちゃけクラス設計は、役割分担作業だと思うのだ。
きっちりと分業できるような体制を作るのが目的なのだ。
みんな仲良く同じことをやるのではなくて、
誰かがキッチリ自分の作業だけやりゃいいって関係を築く作業だと思うのだ。
たまには専門用語をつかって言うと、
凝集度は「機能的凝集」を目指し、
結合度は「データ結合」を目指すってことなのだ。（参考URL）

設計は最初に完璧であるのが望ましいが、実現は不可能だ。
ゆえに実装中に再設計〜再実装の手順は当然踏むことになる。
一番最初に決めた方針だけはそのままに、
シンプルな構造、シンプルなロジックを保つ。
設計思想は変えずに実装を変えると言い換えたほうがいいかも。

もし。
最初の設計通りに実装しようと思ったら。
この言葉がふさわしい。
( ・ω・)o[無理を通せば道理が引っ込む]

いびつなクラス同士の関連性は更なる無理無茶無謀しか生まない。
構造が複雑化するのだ。
複雑な構造の理解には時間がかかり、修正と確認にさらに時間がかかる。
再設計、再実装を行わなければこれらの時間がちょくちょく必要になり、
時間をかけたところで複雑さの解消にはならない。
複雑なところを改善しないのだから、
結果の辻褄あわせを行うような修正をやってしまう。
これは構造の更なる複雑化に結びつく。
えらいこっちゃ。

こんな手法でも、世の中にこれだけはびこっているだけの理由がある。
「何はともあれ動くものが出来上がる」
これだ。
製作から改善保守に仕様追加変更まで考慮した際に、
まず始めのスタートラインとも言える「製作」にかかる時間は短くなる。
が、その後全ての作業の時間を無駄に必要とすることになる。
後々にワリを食わしているのだ。
そしてそのワリを食うのは明日の自分かもしれないのである。
おいしくなさそうだ。
ってかおいしくはなかったぞ。

よく見かけるソース。
ああ。こりゃだめだヽ(´ー`)ノって思うソース。
きっと頭じゃ「こうしたほうがいい」って思われているかもしれないけれども
そうはなっていないソース。
おいらがクサレソースという全てのソースに共通することがある。
(..゜Д゜)＜ロジックが場当たり的すぎ

ソースが上から下まで流れていく間に、
メソッドで仕分けられてはいない。ゆえにムダに長い。
どこかで見かけたソースがそこにもある。ゆえに共通化など行われてはいない。

実行速度にこだわった記述ではなく。
管理手間軽減のために書いてあるソースでもなく。
垂れ流しで記述されたロジックは見た目でわかる。
ロジックっというか、処理のストーリーっていうか、なんつーか。
一貫性が無いのだ。
なんでもかんでも一緒にやろうとして、結局なにがやりたいのかわからなくなったってソースは
書いたこともある経験上わかる。
オブジェクト指向プログラミングでも構造化プログラミングでもない。
クラス間において、メソッド間において、お互いの作業分担ができてない。
擬人化すると、
「おいらが出来ることは他の誰かでもできる。」これは×だ。
「おいらはこれだけしかできないけれども、おいらにしかできません。」これが( ・ω・)bグッ
「これはヤツにもできるが・・・・・まいっか。こっちでやろっと」これは( ・ω・)qビッ
プログラマにとってこの「まっいっかヽ(´ー`)ノ」は「やらなあかんこと」に等しい。
きっちり分担作業を決めなおさなきゃいけないのだ。
(´-`).。oO(やってるときはすんげーめんどいと思うけどね。)