Composed Method
昨日、mさまにいただいたコメントです。
おおざっぱに言えば「関数を使って、機能を分割する」はプログラマの壁かもしれませんが、本当はSEというか分析や設計者の分担ではないかと。
確かにそのとおりで、本来は分析設計フェーズで機能は分割されているべきだとは思います。
けれども、僕の意図としては、たとえばある処理が 300行で書けるとしたら、10〜30行くらい(オブジェクト指向ならもっと短く)の「論理的なカタマリ」に分割するべき。そうすることで、たくさんのメリットが得られる。けれどもそれを実行しているプログラマは意外と少ないので、これも大きな壁なのかなと思った、ということです。
で、つらつらそれを説明しようと思ったら、ちょうど今日読みはじめた本の一番最初で取り上げられてた。
ケント・ベックのSmalltalkベストプラクティス・パターン―シンプル・デザインへの宝石集
- 作者: ケントベック,Kent Beck,梅沢真史,皆川誠,小黒直樹,森島みどり
- 出版社/メーカー: ピアソンエデュケーション
- 発売日: 2003/03
- メディア: 単行本
- 購入: 7人 クリック: 94回
- この商品を含むブログ (55件) を見る
これの一番最初、「Composed Methodパターン」です。
うろ覚え解説ですが、
- メソッドはなるべく短く書くこと
- 長いメソッドは分割すること
基本的にはこれだけ。
こうすることによって、
- 長い処理でも概略をつかみやすい
- 重複した処理や似た処理を見つけることができ、これをまとめることでコードが簡潔になる
- スーパークラスの抽出がしやすくなる
と言ったメリットがあります。ポリモーフィズムと関数ポインタは友達みたいなものなので、手続き型でも当てはまると思います。
# これから全パターンを紹介するのだろーか...。