tsucchi’s diary(元はてなダイアリー)

はてなダイアリー(d.hatena.ne.jp/tsucchi1022)から移行したものです

Composed Method

昨日、mさまにいただいたコメントです。

おおざっぱに言えば「関数を使って、機能を分割する」はプログラマの壁かもしれませんが、本当はSEというか分析や設計者の分担ではないかと。

確かにそのとおりで、本来は分析設計フェーズで機能は分割されているべきだとは思います。

けれども、僕の意図としては、たとえばある処理が 300行で書けるとしたら、10〜30行くらい(オブジェクト指向ならもっと短く)の「論理的なカタマリ」に分割するべき。そうすることで、たくさんのメリットが得られる。けれどもそれを実行しているプログラマは意外と少ないので、これも大きな壁なのかなと思った、ということです。

で、つらつらそれを説明しようと思ったら、ちょうど今日読みはじめた本の一番最初で取り上げられてた。

ケント・ベックのSmalltalkベストプラクティス・パターン―シンプル・デザインへの宝石集

ケント・ベックのSmalltalkベストプラクティス・パターン―シンプル・デザインへの宝石集

  • 作者: ケントベック,Kent Beck,梅沢真史,皆川誠,小黒直樹,森島みどり
  • 出版社/メーカー: ピアソンエデュケーション
  • 発売日: 2003/03
  • メディア: 単行本
  • 購入: 7人 クリック: 94回
  • この商品を含むブログ (55件) を見る
(しまった!会社に置いてきたから、引用はできんorz)
これの一番最初、「Composed Methodパターン」です。

うろ覚え解説ですが、

  • メソッドはなるべく短く書くこと
  • 長いメソッドは分割すること

基本的にはこれだけ。

こうすることによって、

  • 長い処理でも概略をつかみやすい
  • 重複した処理や似た処理を見つけることができ、これをまとめることでコードが簡潔になる
  • スーパークラスの抽出がしやすくなる

と言ったメリットがあります。ポリモーフィズムと関数ポインタは友達みたいなものなので、手続き型でも当てはまると思います。

# これから全パターンを紹介するのだろーか...。