プログラム設計に拘りすぎで・・・

レスが遅れて申し訳ありません。

回答者様のURLを拝見していて、各工程の認識が甘かったように思いました。
今までを振り返ってみますと、漠然とした思いつきで拡張性や再利用性、保守性などと考え、本来の要求とはかけ離れたところで悩み続けていました。
いずれにしろ「何を」「どうしたいのか」が明確になっていなければ、設計も実装も出来なくて当然ですよね・・・。いったい何を勉強していたんだか・・・。

＞クラス設計なども、複雑な所のみ入念に考えていけばいいのでは、と思います。
確かにその通りかもしれません。
初めから端から端まで考える必要など無く、要所となるところを抑えていって、必要が生じればリファクタリングや再設計を行った方が現実的ですね。

少しクラスやオブジェクト指向といった概念だけに囚われすぎていたかもしれません。
プログラムはクラス関係を記述することだけが唯一の手法ではないし、OOPは手段の一つだと言うことを思い出しました。
もう一度初心に返り、本質を見極められるような勉強をし直そうと思います。

ありがとうございました。

ネーミングも難しい問題ですよね。
ネーミングにしても設計にしても、他人(あるいは未来の自分)が読める(変更できる)ソースを書こう、というところに根底があると思うのですが、
それに囚われて、ソースを書き上げるとこまで持って行けないというジレンマがあります。
良いネーミングも、良い設計も、それらが簡単ではない、という事は理解しているつもりですが、もしかしたらそれは私の理解より遙かに難しいことなのかもしれません。

貴重なお話ありがとうございました。

マインドマップモデリングというのは初めて知りました。
参考にさせていただきます。
ありがとうございました。

回答ありがとうございます。
ご指摘の通り、設計を考えてからコードを書くのは、一人で書いているアマチュアにとっては必要のないステップかもしれません。
最初にある程度設計をキッチリ決めておいた方が、コードがしっかり分割されて、
設計が気に入らなくて修正するにしても変更の影響を受ける箇所が少なくて済む、という思い込みがあったのですが、
思い返せば、実際は設計を決めてもコードを組み始めると予想外の事項が絡んできて、再設計・・以下ループ。というスパイラルに陥ってました。

プロの方でも、それが許されるならば、一度何も考えずプロトタイプを組んでから俯瞰的に見渡して修正、または１から作り直した方が、むしろ早いのでしょうか。

「適用できる」のニュアンスを「構造がこうであれば、このようなクラス関係で構築した方がよい」という意味と誤解していたかもしれません。

>ＯＯＰは手段であって目的ではありません。
耳が痛いです。
例えば状態遷移を書くとしても、無理にステートパターンを当てはめるのではなく、
状態遷移の規模や求められる性質によって、オーソドックスなswitch文やテーブルでの実装も検討した方がよいかもしれません。

ありがとうございました。