読者です 読者をやめる 読者になる 読者になる

レガシーコード生産ガイド

私に教えられることなら

デザインパターンと学び方

Smalltalkについて調べている最中に見つけて、ウォード・カニンガムHyperCardの話が載っているということで気になっていた「パターン、Wiki、XP」を読みました。

パターン、Wiki、XP ~時を超えた創造の原則 (WEB+DB PRESS plusシリーズ)

パターン、Wiki、XP ~時を超えた創造の原則 (WEB+DB PRESS plusシリーズ)

デザインパターンが提唱される元になった、建築家クリストファー・アレグザンダーの「パタン・ランゲージ」などから解説されていて、かなり深くまで掘り下げた本です。

デザインパターン

デザインパターンについては、ポール・グラハムの以下の文章がずっとひっかかっていました。

技術野郎の復習

私が自分のプログラムにパターンを見付けたら、それはどこかがおかしいというサインだ。 プログラムの形は、それが解くべき問題のみを反映すべきだ。 その他の繰り返しがコード中に現れるということは、少なくとも私にとっては、 十分な抽象化を行っていないということを意味する。大抵の場合、それは マクロを書くべきコードを手で拡張して書いているということになる。

その「十分な抽象化」のためにマクロを書く事がLispでのデザインパターンの一つでは無いか、と考えています。マクロの書き方にもデザインパターンが現れるでしょう。

そういう視点で読みましたが、また少し違う印象を受けました。特に重要だと思ったのがデザインパターンのフォーマットです。Wikipediaの解説では特定の規約に従ってカタログ化したものである。と簡単にしか触れられていませんが、その特定の規約こそが肝心だと思います。

特に欠かせないのが、状況→問題→解決策 の3つの繋がりです。まずある状況において特定の問題が繰り返し発生することを説明し、よく登場する・現時点では一番ましな解決策を提示する、という流れです。(参考:暗黙知の共有に効く?パターンランゲージの可能性

デザインパターンの目的は、この状況→問題→解決策の繋がりに名前をつけて、共有することにあります。開発時のコミュニケーションのために名前を共有する、という目的もあると思いますが、もっと重要なのはまだそれを知らない人に伝えること、つまり教育だと思います。

学び方

ここからは話のスコープをぐっと絞り、私個人についてです。

プログラミングに限らず、何かを学ぶときに一番辛いのは解決策だけ与えられて、状況や問題がいつまでもわからないときです。ゴールが決まってないマラソンを走らされている気分になります。

逆に状況がはっきりしていて、何か解決したい問題が具体的に伝えられ理解できると、解決策が喉から手が出るほど欲しくなり、吸収する準備が完全に整います。これについてはScratchのミッチェル・レズニックのTEDトークが印象的で度々思い出します。(和訳文のみ)

これと似たゲームをScratchで作っている 13才の少年がいました。(略) 彼は得点をつけて大きな魚が小さな魚を食べる度に得点が上がるようにしたいと思っていました。でもどのようにすればいいのか分かりませんでした。そこで彼にScratchでは変数というものが使えることを教えました。(略) 彼をビクターとしておきましょう。ビクターはこのブロックで得点が加算できることが判るとどうすればいいかを理解しました。(略) 彼は興奮して私の手を握ると「ありがとう ありがとう」と言いました。その時思ったのは先生が変数を教えて生徒に感謝されることなんてどのくらいあるのだろうかということでした(笑)

私自身も同じような経験があります。友人にプログラミングを教えていて、本人が必要とするまで配列を教えるのを我慢していました。連番で管理された大量の変数名(chara1...chara10)を毎回書くのが面倒だ、と相談されて初めて配列を教えたところ、興奮して「これは何かに使えそうだ!」と熱心にいろいろ試し始めたのをよく覚えています。

このように状況→問題という準備が整ってから解決策を得ると、精神的に負担無く、それどころか楽しく学べる事が多いと感じます。また、それを追体験できるように試行錯誤の過程が書かれた文書は、単に成功する手順が書かれたものよりも、解決策が記憶に残りやすいです。

そのように「解決したい」という欲求を刺激してくれる書き方がされた本ばかりなら嬉しいのですが、紙面の都合上か、なかなかありません。最近は本やドキュメントをそのまま読むのをやめて、解決したくなるような問題・達成したくなるような課題を内容から作り、それに取り組むようにしています。私にはかなり効果があるので、同じような人のために、そういったスタイルの文書を残せないかと考えています。

GoF以外やOOP以外でのデザインパターン

再びデザインパターンの話に戻ります。

ある状況において特定の問題が繰り返し現れ、それに対するよくある解決策があるならば、それが摘出すべきデザインパターンだと言っていいのではないでしょうか。解決策が短かったりエレガントだったり、メタに解決したりと違いはあっても、どのプログラミング言語・スタイルにも存在するはずです。

そして上記のような状況→問題→解決策という書き方なら少なくとも私にとっては学びやすく、デザインパターンとはそういったスタイルの情報、という意味で定着して欲しかったと思います。

しかしデザインパターンと言えばOOP、その中でもGoFの23パターン、というイメージが強くなってしまった以上はなかなか用語を変えることは難しいでしょう。(同じように定着してしまった用語のイメージに苦戦してるSmalltalkOOPを思い浮かべます)

とりあえずデザインパターンという言葉は置いておいて、創造力を発揮しやすい文書に取り組みたいところです。

広告を非表示にする