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

Question

メッソド・関数の分け方、クラスの継承の使い方、どういったクラス構造にするかなどの思想というかプログラム構造の考え方、効率のよい書き方に悩んでいます。

こういった考え方というのは、たくさんの開発経験を通じて、自分なりの考え方で学習していくものなのでしょうか。
それとも基本的な設計思想(CSSでいうBEMやSMACSS)みたいなものがあるのでしょうか。

Answer 1

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

設計の本を読むとか、いろいろあるでしょうが、
ここでは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. ライブラリを通じて、長期に見る

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

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

Comments

[退会済みユーザー]

抽象度の高いアドバイスありがとうございます。
各項目ごとの仰っている内容は理解できるのですが、知識量が足りないせいか、
自分の知識体系の中のニューロンが結びつかず、東洋哲学的な悟りというか「分かった」にいたらず、
もやもやーとしている状態です。

しかし、ご教示いただいたことの感覚は理解できます。
大(図解)・中(クラス図・関数)・小(実装)の大と中で設計/構造を理解するという感じしょうか。

なんか訳の分からない文章表現のコメントで申し訳ないです。
アドバイス頂いたことを羅針盤にして、理解できるように勉強を進めていきます。
ありがとうございました！

[LLman]

＞「分かった」にいたらず、もやもやーとしている状態
設計では、実装と見方を変える必要があるということです。

デザインというか絵画などの美術系の知識に相当することで言えば、
たとえば、デッサンの狂いを見るために、紙を裏返して蛍光灯に透かしたり、
普通に描くときとは、違う見方をすることがあるかと思います。

また、絵の表層には直接現れないけれど、解剖学や遠近法の知識を使い、
深層の構造を把握することで、絵が写実的になっていくと思います。

ここで、プログラムの設計の話に戻ると、設計要素もデッサンと同じで、
全体のバランスが狂いやすいし、それが見落としやすく、気づきにくいんです。
だから、UMLなどを使って、違う見方をすることが有効なんです。

＞大と中で設計/構造を理解する
本文の要約としては、おおむねそういうイメージです。
「全体を見る視点」が重要だということです。

ただ、これはかえって混乱させてしまうかもしれませんが、さらに言うと、
シンプルで上手い設計は、たいてい「再帰的」な構造をしています。

つまり、小さいものを組み合わせて大きいものを作ります。
そのさい、フラクタル図形みたいに、小さいスケールと大きいスケールで相似形にします。
こうすると、プログラムの規模が大きくなっても単純化できます。

どういうことかというと、作るプログラムが大きくなるときに、
単純に部品の関数やクラスを大きくすると、複雑になって分かりにくい。
そこで、小さいオブジェクトを組み合わせて、大きいプログラムを作ります。

だから、より正確にいうと、全体と部分を両方見る視点、
「木を見て森も見る」視点というのが、重要になります。

これは抽象度が高い話で、分かりにくいかもしれず、申し訳ないのですが、
再帰的に構成する設計手法が理解できると、設計力に自信がつくと思います。

Answer 2

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

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

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

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

Comments

[退会済みユーザー]

AS、JS、PHPなどのWeb系言語が頻繁に使う言語で、
「デザインパターン」というとJAVAの本が多い印象で、JAVA使わないし、サンプルコードが分からないなーと、
敬遠していましたが、ネットで調べたらWeb系の言語を使ってのハウツー記事がありました。
これを気に「デザインパターン」を掘り下げて勉強しようと思います。
次のステップへの道筋が見えました。ありがとうございます！

Answer 3

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

Comments

[退会済みユーザー]

「C++のためのAPIデザイン」という本、良さそうですね。
LLmanさんが仰っているいるようにAPIやライブラリ、デザインパターンの作成やリーディングは敷居が低くて始めやすそうです。
良いアイデア、ありがとうございます!