プログラムの設計の学習方法を教えてください

プログラムの設計の学習方法を教えてください

設計の本を読むとか、いろいろあるでしょうが、
ここでは3つ、ひとりでは気づきにくいポイントを挙げましょう。

ひとつ目は、全体を見る方法。

設計の学習には図解が有効です。
フローチャートとかUMLとかです。

なぜ、図解が有効なのかというと、
そもそも設計は実装よりも大きな単位なので、
実装のことをいったん忘れる必要があるからです。

UMLなどの図だと実装が省略されているから、
全体がかえって見えてきやすいのです。
航空写真より地図の方が、全体像は把握しやすいようなものです。

たとえば、デザインパターンのクラス図を見ていると、
ストラテジーとステートは同じような構造だなとか、
いろいろ発見があると思います。

ふたつ目は、外側から見る方法。

関数やメソッドの処理よりも、
名前や引数、返り値に注目します。

function add(str arg_a, str arg_b){
// 処理
return str result
}

たとえば上記は、特定の言語を想定したものではない疑似コードですが、
関数名をパッと見て「引数の和を返すのかな？」と思ってしまうかもしれません。

でも、引数と返り値の型が文字列なので、計算ではないはずです。
中の実装を読むまで、何をやっているのか分からない関数です。
しかも場合によっては、読んでも分からなくて、使う場所を探す必要があったりして。

function get_full_name(str first_name, str last_name){
// 処理
return str full_name
}

そこでこれなら、姓と名前を引数に取って、氏名を返す関数だと、
実装を見なくても想像がつきますね。

実装を読まなくても使えると、使いやすいモジュールになります。
言語の標準ライブラリなどを使うときは、実装を読まないと思います。

いかに読む量を減らせるか、覚える量を減らせるかが設計力です。
疎結合とか単一責務などの設計原則も、それに沿っています。

さらに、この発展で、抽象クラスや（Javaの）インターフェイスに、
注目することは有効だと思います。それらに実装はないけれど、
プログラムの骨格になっているので、設計上重要な要素です。

みっつ目は、長期に見る方法。

設計の善し悪しは長期的に評価する必要があります。
しかし、書き捨てのプログラムでは分からない。

そこで、ライブラリやAPIを自作すると、
長期的に使うので、評価しやすいと思います。
ライブラリ作成は大変なので、小物を多く作るといいです。

また、RubyやJavaなど、普段使っている
言語の標準ライブラリを学ぶのも、参考になると思います。

言語の開発元は、その言語がよく分かっているので、
クラスの分け方など、多くの場合で参考になる点が多いと思います。

とくに、オブジェクト指向が真価を発揮するのは、
長期的に使われるクラスライブラリやフレームワークです。
たとえば、引数が少ないと使いやすいです。

オブジェクト指向で作るときには、多少複雑になったりしますが、
使う側に回るとシンプルで使いやすいです。それがメリットです。
だから、設計するときは、利用側の視点が欠かせません。

1. 図解を通じて、全体を見る
2. 引数や戻り値を通じて、外部から見る
3. ライブラリを通じて、長期に見る

まとめると、上記の三点が設計力の向上に有効です。

要は、「木を見て森を見ず」にならないように、
大きな構造を認識するためのポイントです。

他の人のプログラム(Githubなどで公開されているコードなど)を見て僕は自分なりの書き方を見つけました。
他にもプログラムを見やすく書くための本なども公開されています。
あと、C++ですが、C++のためのAPIデザインという本もおすすめです。

とりあえず、知識や考え方として確立したものを知りたいなら
「デザインパターン」「凝集度・結合度」あたりをキーワードに検索、ですかね

知識なしに色々好き勝手にやってても
保守性を考えながらやってれば割と必要に迫られます

何か拡張・変更・流用などがあったとき
「ああしておけばよかった」や「こうしておいてよかった」の
経験の積み重ねると自然「凝集度・結合度」の考えは持つことになりますし
いくつかの「デザインパターン」はその名前を知る前にたどり着くことになるはずです

逆に「デザインパターン」は単にどういうものかを知っているだけでなく
「どういうときにいいものなのか？」「なぜそうした方がいいのか？」を
多少経験として知っていないと割と知識として片手落ちです