プログラムの設計の学習方法を教えてください
解決済
回答 3
投稿
- 評価
- クリップ 3
- VIEW 241
メッソド・関数の分け方、クラスの継承の使い方、どういったクラス構造にするかなどの思想というかプログラム構造の考え方、効率のよい書き方に悩んでいます。
こういった考え方というのは、たくさんの開発経験を通じて、自分なりの考え方で学習していくものなのでしょうか。
それとも基本的な設計思想(CSSでいうBEMやSMACSS)みたいなものがあるのでしょうか。
-
気になる質問をクリップする
クリップした質問は、後からいつでもマイページで確認できます。
またクリップした質問に回答があった際、通知やメールを受け取ることができます。
クリップを取り消します
-
良い質問の評価を上げる
以下のような質問は評価を上げましょう
- 質問内容が明確
- 自分も答えを知りたい
- 質問者以外のユーザにも役立つ
評価が高い質問は、TOPページの「注目」タブのフィードに表示されやすくなります。
質問の評価を上げたことを取り消します
-
評価を下げられる数の上限に達しました
評価を下げることができません
- 1日5回まで評価を下げられます
- 1日に1ユーザに対して2回まで評価を下げられます
質問の評価を下げる
teratailでは下記のような質問を「具体的に困っていることがない質問」、「サイトポリシーに違反する質問」と定義し、推奨していません。
- プログラミングに関係のない質問
- やってほしいことだけを記載した丸投げの質問
- 問題・課題が含まれていない質問
- 意図的に内容が抹消された質問
- 広告と受け取られるような投稿
評価が下がると、TOPページの「アクティブ」「注目」タブのフィードに表示されにくくなります。
質問の評価を下げたことを取り消します
この機能は開放されていません
評価を下げる条件を満たしてません
質問の評価を下げる機能の利用条件
この機能を利用するためには、以下の事項を行う必要があります。
- 質問回答など一定の行動
-
メールアドレスの認証
メールアドレスの認証
-
質問評価に関するヘルプページの閲覧
質問評価に関するヘルプページの閲覧
checkベストアンサー
+4
プログラムの設計の学習方法を教えてください
設計の本を読むとか、いろいろあるでしょうが、
ここでは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
他の人のプログラム(Githubなどで公開されているコードなど)を見て僕は自分なりの書き方を見つけました。
他にもプログラムを見やすく書くための本なども公開されています。
あと、C++ですが、C++のためのAPIデザインという本もおすすめです。
投稿
-
回答の評価を上げる
以下のような回答は評価を上げましょう
- 正しい回答
- わかりやすい回答
- ためになる回答
評価が高い回答ほどページの上位に表示されます。
-
回答の評価を下げる
下記のような回答は推奨されていません。
- 間違っている回答
- 質問の回答になっていない投稿
- スパムや攻撃的な表現を用いた投稿
評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。
+1
とりあえず、知識や考え方として確立したものを知りたいなら
「デザインパターン」「凝集度・結合度」あたりをキーワードに検索、ですかね
知識なしに色々好き勝手にやってても
保守性を考えながらやってれば割と必要に迫られます
何か拡張・変更・流用などがあったとき
「ああしておけばよかった」や「こうしておいてよかった」の
経験の積み重ねると自然「凝集度・結合度」の考えは持つことになりますし
いくつかの「デザインパターン」はその名前を知る前にたどり着くことになるはずです
逆に「デザインパターン」は単にどういうものかを知っているだけでなく
「どういうときにいいものなのか?」「なぜそうした方がいいのか?」を
多少経験として知っていないと割と知識として片手落ちです
投稿
-
回答の評価を上げる
以下のような回答は評価を上げましょう
- 正しい回答
- わかりやすい回答
- ためになる回答
評価が高い回答ほどページの上位に表示されます。
-
回答の評価を下げる
下記のような回答は推奨されていません。
- 間違っている回答
- 質問の回答になっていない投稿
- スパムや攻撃的な表現を用いた投稿
評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。
15分調べてもわからないことは、teratailで質問しよう!
- ただいまの回答率 91.06%
- 質問をまとめることで、思考を整理して素早く解決
- テンプレート機能で、簡単に質問をまとめられる
2017/12/23 02:04
各項目ごとの仰っている内容は理解できるのですが、知識量が足りないせいか、
自分の知識体系の中のニューロンが結びつかず、東洋哲学的な悟りというか「分かった」にいたらず、
もやもやーとしている状態です。
しかし、ご教示いただいたことの感覚は理解できます。
大(図解)・中(クラス図・関数)・小(実装)の大と中で設計/構造を理解するという感じしょうか。
なんか訳の分からない文章表現のコメントで申し訳ないです。
アドバイス頂いたことを羅針盤にして、理解できるように勉強を進めていきます。
ありがとうございました!
2017/12/23 05:15
設計では、実装と見方を変える必要があるということです。
デザインというか絵画などの美術系の知識に相当することで言えば、
たとえば、デッサンの狂いを見るために、紙を裏返して蛍光灯に透かしたり、
普通に描くときとは、違う見方をすることがあるかと思います。
また、絵の表層には直接現れないけれど、解剖学や遠近法の知識を使い、
深層の構造を把握することで、絵が写実的になっていくと思います。
ここで、プログラムの設計の話に戻ると、設計要素もデッサンと同じで、
全体のバランスが狂いやすいし、それが見落としやすく、気づきにくいんです。
だから、UMLなどを使って、違う見方をすることが有効なんです。
>大と中で設計/構造を理解する
本文の要約としては、おおむねそういうイメージです。
「全体を見る視点」が重要だということです。
ただ、これはかえって混乱させてしまうかもしれませんが、さらに言うと、
シンプルで上手い設計は、たいてい「再帰的」な構造をしています。
つまり、小さいものを組み合わせて大きいものを作ります。
そのさい、フラクタル図形みたいに、小さいスケールと大きいスケールで相似形にします。
こうすると、プログラムの規模が大きくなっても単純化できます。
どういうことかというと、作るプログラムが大きくなるときに、
単純に部品の関数やクラスを大きくすると、複雑になって分かりにくい。
そこで、小さいオブジェクトを組み合わせて、大きいプログラムを作ります。
だから、より正確にいうと、全体と部分を両方見る視点、
「木を見て森も見る」視点というのが、重要になります。
これは抽象度が高い話で、分かりにくいかもしれず、申し訳ないのですが、
再帰的に構成する設計手法が理解できると、設計力に自信がつくと思います。