GoFとMVCパターンと、ソフトウェア工学のデザインパターンのその後を私見で

せっかくなので、ソフトウェア工学における私がみつけたパターンをいくつか書いておきます。

原著の「Design Patterns」

いわゆる「GoF本」です。「デザパタ」と略されることもあるのですが、巷のデザインパターンの本と区別が付きづらいので「GoF本」で通しています。

日本語訳でもいいのですが、手元には原著のKindle版があります。Kindleってことは、だいぶん後に買ったので、当時(1994年)に読んだわけではありません。日本でのデザインパターンブームが2000年頃(だったっけ?)なので、原著(あるいは訳本)を読まないままデザインパターンを知った或いは覚えた人も多いと思います。私の入り口もそれですね。

ただ、それだけだとコード寄りになってしまうので、いったん原著にあたっておくといいです。が、中身がC++なのでC++が読めないと辛いです。確か、Javaへの翻訳本もあるはずなのですが、GoF本の発端自体が、C++あるいはMVCパターンによるアプリケーション開発の現場からの抽出なので、当時のC++の状況がわからないと読み込めません。いまのJavaやC#だと、GoFの各種パターンが言語仕様に組み込まれた状態になってしまっているので、そのまま読んでも「何でこんなややこしいことになっているの?」としか見えません。

2016年の自分のブログ記事ですが ふと GoF のデザインパターンを再考しておく で GoF パターンを C# で検証しなおしたものがあります。

同時期の Smalltalk best practice patterns

先の GoF 本と同時期に出たケント・ベック氏の書いた本です。買ったのは随分後なので、当時がどういう状況だったのかはよくわかりません。結構高いので、参考までに持っておくというので良いです。

GoF 本と同じく「パターン」と書かれていますが、GoF とは異なり、アレクサンダー氏の「パタン・ランゲージ」を元にしている訳ではありません。UMLのクラス図もありません。コードがSmalltalkで書かれているので、これに慣れていないと読み取れません。

という難点がありますが、ケント・ベックが書いたということと、オブジェクト指向(クラス構造であれメッセージングであれ)を語る上で Smalltalk は外せないので持っています。持っていますが、私としては Smalltalk でオブジェクト指向を語る気はありません。どちらかというと、クラス構造としてのオブジェクト指向(C++やJavaなど)寄りのところで過ごして来たので、別の流れもあるということですね。

ちなみに、メッセージングのほうのオブジェクト指向は Web APIの呼び出しにてかなり実現されていると考えられます。HTTPプロトコルのステータス無し、Cookie等によるステータスの付与、物理的時間的に遠地にあるファンクションのコールなど、Smalltalk の語るオブジェクト指向が別系統でも実現されつつあるかなぁと。つーか、それで十分ではないか、その先に行きましょうよ、って感じですね。

ちなみにその先のパターンに関しては後述します。

追記しておくと、冒頭にある MVCパターンの論文はここにあります。

https://ics.uci.edu/~dfredmil/ics227-SQ04/papers/KrasnerPope88.pdf

大本のデザインパターンとしての「パタン・ランゲージ」

デザインパターンブームの元ネタの「パタン・ランゲージ」です。ご存じ、アレグザンダー氏の著書で高いので、ひと苦労です。しかも、コードじゃなくて建築の話です。

これも2000年のデザインパターンブームのときには買わなかったのですが、のちに購入しました。やっぱり原点をあたってみないとわからないということで。

この中で書かれていることから読み取ると、

パターンの原点であるアレクサンダー著「パタン・ランゲージ」では、現在ある構造物(都市とか商店街とか)を観察すると、部分的な構造物が組み合わさって現在の良い状態があることわかる。逆に、部品の良い組み合わせ、つまりパターンを作っておけば、良い結果を得られやすいのではないか?という発想です。
なので、当時のMVC パターンで作られた数々の完成物、更に成功している製品を眺めた時に、内部構造としてGoFで書かれたようなパターンを見出す事ができた、故にGoFパターンを使うと成功しやすい、という帰納的解法と思われます。

というのが私の結論です。

なので、建築のパターンやソフトウェア工学のパターンを、構造物(あるいはクラス)作成の効率化や、アプリオリ的に構造物とその組み合わせ(≒パターン)をしておけば良い結果が得られる、という思いこみは間違いです。

歴史的に良い結果(建造物の寿命や商店街の活性化、ソフトウェアの寿命など)を得られてきたものを分解してみると、ところどころに良いパターンが潜んでいるということです。この良いパターンや組み合わせを使うことによって、最終的に良い結果が得られる可能性が高いということですね。ここは帰納法的な思考になります。「帰納法」を出して来たのは、ちょうど統計学再入門を読んでいるところなので、当時は「経験上、よくわからないがうまくいくパターンがあるので、温故知新を用いて使ってみよう」という具合です。

私が、よく先人の知恵とか温故知新とか書くのはそれです。

GoF 本あるいはデザインパターンのその先へ

ここから本題です。いまさら GoF のパターンを学んでも仕方がないです。というか鵜呑みにしても、先に書いた通りプログラム言語仕様の中に組み込まれているものが多くて、原著を読んで C++ で読み込んでもたいして知識が得られるわけではありません。

個人的には、組み込みシステムや別途スマホアプリに応用が効くので、ひと通り知っておいて設計に活かすのがベターなのですが、C++ や Smalltalk を学び直して読み込む必要はないかなぁと思っています。

デザインパターンというと「アナリシスパターン」や「ドメイン駆動設計」あたりに走ってしまいがちになるのですが、実はもっとその先があります。

というかですね。アレクサンダーの著書である「パタン・ランゲージ」の派生を追っていくと、他の分野にも応用できると主張されている節がある。

実際、アレグサンダー自身が当時のソフトウェア業界(1994年)に講演をしているので、そこの別業界としての接点があります。

じゃあ、GoF の各種のコードあるいは周辺のデザインパターンのコードではなくて、もっと広い意味で都市計画とか商店街とか人の導線とかいう意味で、ソフトウェア工学に「パターン」は何を与えていたかというと、

「Garbage Collection」では、ガベージコレクションの世代交代が実装されている。今だとGC では当たり前なんだけど、単純な GC だと頻繁に配置側が発生していまうので、利用している世代を分ける。いわゆる、利用する頻度によって分類するという分け方です。これは、キャッシュとか予約発券システムとかに使われているパターン。 単純にキャッシュするのではなく、頻度に対して分布を作るところにパターンがある。

画像の深層学習で一掃されてしまったが「Toward Category-Lravel Object Recognition」というアイデアがあった。特徴量を導き出して、相互の距離を計測して画像認識に使う技で Google とかもやっていました。結果的に、隠れ層を使った7層程度の深層学習(Deep Learning)のほうが効率が良いことになったので、このあたりの実装はなくなってしまったのだが、特徴量的な考え方は統計学とか主要因分析にも応用されているし(おそらく、この当時の画像認識の研究が統計学の応用だろうし)、その後の報酬関数(フィードバックシステム)のパターンがこの当時からあります。生成AIもこのあたりの延長と言える。

こちらは工業デザインのパターンということで、ノーマン著「誰のためのデザイン」。現在は認知科学として捉えるべきなのか?単なるエモーショナルな流行デザインに過ぎないのか不明なんところではあるけど(いわゆるグローバルデザインの話になる)、それでも一種のパターンに従えば、利用者の落とし穴を防ぐことができる。これこそパターン・ランゲージの応用例と言える。
ソフトウェア工学として、一時期UIデザインにも取り入られた筈なのだが、iOS7からのフラットデザインから以降、それが本質的に誰のためのデザインなのかわからなくなっているところがある。個人的には、高齢者カスタムのかんたんスマホのUIとかはいいと思うんですけどね。設定がごちゃごちゃなのはいただけないが、ガラケーっぽいUIに揃えてあるのは、ガラケー主流だった高齢者にはよいデザインだと思う。誰が?という意味では、「高齢者」が使うわけですから。

「コンピュータの中の人口社会」に書かれているエージェントシステムは、ソフトウェア工学のなかで MVC パターンと同じぐらい重要なデザインパターンと思われる。全体を統括的に扱うのではなく、個々のオブジェクトを独立してプロセスやスレッドで動かすというパターン。まさしく、オブジェクト指向による「オブジェクト」の実現なわけだが、それぞれを独立して動かすことにより、相互の影響を環境値として与えることができるのがミソ。いわゆる、品質工学などでいう外乱を内部特性を区別できるシステムである。

エージェントシステムの発想は遺伝的プログラミングとか並列処理とかいろいろ発想が効くので知っておくとよいパターンです。

まとめとしてのパターン

そんな訳で、ソフトウェアにおけるパターンはなにもコーディングに限らないので、システム全体の構築やユーザーの利用動向、UIの作成、PMBOKによるプロジェクト管理、DevOpsやテスト駆動による価値の制御(スループットや計測)などいろいろな場面でパターンがあります。細かい単位のプラクティスではなくて、大局としてのパターン、つまりは軍事ドクトリンに近いのです。みなさま、応用しては如何でしょうか?

といういうブログパターンで〆てみるテスト。

カテゴリー: 開発 パーマリンク

コメントを残す

メールアドレスが公開されることはありません。 が付いている欄は必須項目です

*