パターンとは？
|
パターンとは、日本語にすると「型」と言う意味ですから、設計するときの型ということになります。プログラミングを例に取ってみますと、処理内容は100件のデータを読み込んで、そのデータをソートソートすることです。プログラム言語には、C言語を使います。さて、プログラマはどのようにプログラムを考えるのでしょうか。たぶん、次のような思考をめぐらします。「まずデータの格納用に配列を取りforループで100回まわしてデータを読み込む、その後にクイックソート、バブルソートなどのアルゴリズムを使ってソートを行う。読み込みはfor文で、ソートはアルゴリズムを使って・・・」ということが、まさにパターンにあたるのです。 デザインパターンは、プログラム設計する時には、定石に従って作成するということである。デザインパターンは、この定石をパターンとして、カタログ化している。そして、必要な時にカタログからパターンを引き出して、適用していれば、間違いないプログラムが作成できます。 デザインパターンは、実装を適用した設計に必要不可欠な技術であると同時に、オブジェクト指向の設計なくしては、出来ないと言っても過言ではありません。 アンチパターンとは、デザインパターンが設計をする為の、パターンであるのに対し、何度も繰り返される失敗や駄目な解決方法をパターン化したもの。失敗をパターン化して、そうならない一般的な解決方法を、示そうとしている。パターンをテンプレートとして利用する事で、失敗を繰り返さないで解決策を得られる。テンプレートには、アンチパターンの背景説明、一般形式、兆候と結果、根本的な原因、解決策と解決する為の実施例が含まれている。アンチパターンとして、溶岩流(LavaFlaw)、配管システム(StovepipeSystem)などがある。 アナリシスパターンは、オブジェクト指向に基づいて、汎用的な業務ドメインを言語的な実装に依存せず、オブジェクト指向モデルで実現しパターン化したものです。 ２．data[i]のように配列にアクセスするので、iが100より大きい値になると実行時エラーとなる。 このコードでは、データ数、配列のインデックスもでてきません。エラーの少ない洗練されたコードです。このデータ構造を継承を使って、拡張することができます。hasMoreElemenets()、nextElement()をサブクラスとして継承して、さらに独自のデータ構造を持つようにすればよいのです。 ここでのConcreateIteratorというクラスがIteratorを継承しながら、データ構造などを拡張したものです。 Observerパターンは、あるオブジェクトに変化が起きたとき、そのことを関連するオブジェクトに通知します。具体的には、図１のようにユーザは表示されているグラフG1、G2を見ています。センサが変化を関知すると、このグラフのデータを更新して書き直すように通知します。センサオブジェクトがどのオブジェクトに通知を送るかを知っている必要があります。このために、グラフオブジェクトG1、G2はセンサオブジェクトに登録してあるのです。 このように、通知を受け取る側のグラフオブジェクトをObserverと呼びます。それでは、ここで例をあげて説明していきます。図２のようなアラームシステムを考えます。構成要素は、アラームとディスプレイです。アラーム内で変化が起きた場合に、アラームはディスプレイにそのことを通知します。 ディスプレイは、TextDisplayとDigitalDisplayと２種類があります。プログラムではアラームオブジェクトの内部的な変化は、Notify()によっておこり、通知はUpdate()メッセージでディスプレイオブジェクトに送られます。これをオブジェクト図によって表すと図３のようになります。 通知される側のTextDisplay、DigitalDisplayオブジェクトが生成された後に、通知の関連を作成するために、Alarmオブジェクトに登録します。ここでは、Attach()メッセージが登録に当たります。インターネットで例えると、加入したいメーリングリストにsubscribeのメールを送って登録するのと同じことです。これにより、Alarmオブジェクトは通知すべきオブジェクトのリストを持つことができます。内部的な変化が起きると、Update()メッセージでリストに登録してある各オブジェクトにメッセージを送るのです。また、通知されるオブジェクトが必要なくなった場合は、Detach()によって、リストから削除します。これも、メーリングリストからunsubscribeのメールによって削除できるのと同じです。それでは、このObserverパターンのクラス図をみてみましょう。 変化を関知する側のクラスには、汎用的なSubjectクラスを作成しておきます。そのサブクラスとしてAlarmクラスを実装します。 図５のクラス図と一緒にJavaのコードも見ていきます。通知するオブジェクトを格納するリストには、Vector型でsubscriberを作成します。リストへの登録には、Attach()の中でsubscriber.addElement()ACEとします。配列などのリストを取り扱うときには、前回説明したIteratorパターンを思い出してください。削除の時は、Detach()でsubscriber.removeElement()になります。 この中で、while(e.hasMoreElements())によって、通知するオブジェクトのリストをループさせて、((Display)e.nextElement()).Update(this)で、通知メッセージを送っています。このUpdate()はリストの中のオブジェクトのメソッドなので、TextDisplayかDigitalDisplayのオブジェクトのメソッドになります。既にお気づきかもしれませんが、ポリモーフィズムを用いて、オブジェクトによってメソッドの実装を切り替えているのです。 次に、通知される側のクラスをみてみます。こちらも汎用的なDisplayというスーパークラスを作成します。そして、サブクラスとして、種類の違うTextDisplayとDigitalDisplayを作ります。通知用のメソッドのUpdate()のロジックは違う実装をしたいので、ここではサブクラスにUpdate()のコードを書きます。TextDisplayクラスを見てみますと、オブジェクトが生成されたときは、Attach(this)によって、引数で渡されてきたSubjectオブジェクト（実際にはAlarmのオブジェクト）に登録を行います。自分自身のthisを引数にすることで、自分自身に登録できるようにします。それから、Update()については、サンプル的なプログラムなのでTextDisplayとDigitalDisplayクラスの違いは、単純なprintln()のメッセージだけにしてあります。 Proxyは代理、委任という意味なので、 Proxyパターンとは、オブジェクトへのアクセスする際に代理のオブジェクトを使うようなデザインパターンです。Proxyという用語はインターネットで使われているProxyサーバを連想させます。NetscapeやIEなどのWebブラウザから直接Webサーバへアクセスするのではなく、代理であるProxyサーバを通して行います。Proxyサーバの目的は、ネットワークのセキュリティ機能やキャッシュによるネットワーク負荷を下げるためです。 remote proxyは、分散オブジェクトのようなネットワーク上の別のサーバのオブジェクトにアクセスする場合に、IPアドレスやプロトコルなどのネットワークに関連した情報を隠して、プログラムからあたかもローカルなオブジェクトのように扱うことようなパターンです。 virtual proxyは、オブジェクトを生成するときに、オブジェクトのサイズが大きいなどの理由により、実体をロードしたくない時に、仮にProxyとして実体なしでオブジェクトを作成しておきます。例えば、画像イメージを扱うWebブラウザのようなプログラムで、はじめにイメージを表示させる必要がないとします。この場合は、ページ内のイメージオブジェクトをProxyとして生成させるだけでイメージを表示させるモードに替わったり、イメージがクリックされた時に、実体をロードして表示します。これにより、ページの初期表示のスピードの向上やプログラムのメモリ消費の節約になります。 protection proxyは、オブジェクトへアクセスするセキュリティの問題を解決します。アクセスしたいオブジェクトが直接すべてのオブジェクトからアクセスされたくない場合に、Proxyとしてアクセス用のオブジェクトを作り、このオブジェクトだけがアクセスをできるようにします。Apple社（旧Next社）OpenStep環境のInterfaceBuilderのdelegate機能などがその例です。Proxyによるアクセス制御は、クライアント／サーバ・システムなどの分散環境では、最も重要な要素です。それでは、例をあげてProxyパターンを見ていきます。 virtual proxyの例で説明したWebブラウザと同様に、ワープロのアプリケーションが文書を開いたときには画像は表示せず、画像モードをONにしたり、画像をクリックしたときに表示を行います。文書中に画像があった場合はイメージProxyオブジェクトだけを生成して実体であるイメージオブジェクトは生成しません。画像を描画するときにはじめて、実体のイメージオブジェクトを生成してファイルをロードする仕組みです。 このプラグラムではJavaのGUIフレームワークAWTをつかっているので、イメージクラスのスーパークラスはAWT のPanelクラスになります。Panelクラスのpaint()をImageDisplay、ImageDisplayProxyクラスではオーバーライトしています。JavaのAppletプログラミングでは、init()、start()、stop()、run()、paint()、update()などのメソッドの使い方が決められているので、それにあわせたコードを書かなければいけません。Javaでのプログラミングは、Java言語を習得するというよりも、これらのメソッドで構成されているフレームワークを使いこなさなければいけません。Java言語は簡単で理解しやすいと言われているわりに、Javaプログラマの数が少ないのは、このハードルを越すのが難しいからではないでしょうか。この連載は、Javaプログラミング講座ではないので、話をもとに戻します。さらに、Javaのコードも見ながら、説明していきます。 update()の中で、paint()を呼びだし、さらにその中ではgetImage().paint()としています。ここがポイントで、getImage()はimgpがまだ生成されていなければ、new ImageDisplay()で実体をロードしてきます。imgp == nullという条件があるので、二重にロードすることは起こりません。そして、getImage()のリターンであるImageDisplayオブジェクトのpaint()メソッドを呼び出しています。このpaint()内で、drawImage()、paint()によりApplet上で描画が行われるわけです。この例はvirtual proxyでしたが、Proxyパターンは、CORBA、ActiveX、RMIなどの分散オブジェクトでアプリケーションを開発する時にはとても有効で、米国では盛んに使われています。 状態をハンドリングするのがStateパターンです。実際に、Javaでのプログラムロジックを見ながら説明していきます。状態をハンドリングする一般的なロジックは以下のようになります。 これは、CASE文によってオペレーションを呼び出して、状態変数(state）によってハンドリングしています。Cなどの非オブジェクト指向言語では、よく使われる手法です。取り得る状態が多い場合などは、状態のテーブルを持ったりして、さらに複雑化してしまいます。これと比較して、Stateパターンはどうなるのでしょう。 ここでの例は、エンジンボックスというプログラムで、ギアをアップ、ダウンする機能を持っています。状態としては、待ちと動作中があります。 状態モデルは図２のようになります。非常にシンプルな例です。この状態である、Idle、Runningをそれぞれ、EngineStateのサブクラスにします。そのサブクラスに、それぞれの状態で行う振る舞いをメソッドとして記述します。それでは、実際にJavaのコードにするとどうなるでしょう。 コードの説明をしていきますと、EngineBoxクラスの初期状態は図２の状態モデルよりIdleになります。これは、state = new EngineIdle();で行えます。また、Up()を見てみますと、EngineBoxのオブジェクトであるthis （自分自身）をパラメータとして渡しています。これは、Up()の中から、EngineBoxのメソッドChangeState()を呼び出しているためです。この時、状態を変えるために、new EngineRunning()として、IdleからRunningに状態を変更しているのです。EngineIdle、EngineRunningには、Up()、Down()にぞれぞれの振る舞いをコーディングしてあります。OOPはパズルを解くようにトリッキーなので、皆さんもこのプログラムを動かしながら、ロジックを考えてみましょう。メイン部分の呼び出しは、単純で、次のようになります。 イベントによって、ebox.Down()またはebox.Up()を呼び出します。ここで、仕様を変更して、稼働中の状態にもうひとつ追加して、ローとハイにしてみましょう。Stateパターンでは、柔軟性があるので、サブクラスに少しの変更を入れるだけですみます。メインのEngineBoxクラスに変更はありません。 Stateパターンを使わないコードに新しい状態を追加すると、CASE文が多くのソースコードに散らばっているので、修正作業に手間がかかり、バグを作りやすくなります。これに比べて、Stateパターンでは、追加したい状態のサブクラスを作り、その状態にあった振る舞いにメソッドを変更すれば済みます。EngineBoxクラスのコードに修正を加える必要はないのです。 このようにStateパターンは、状態によって同じメソッド名で内容を変えたい場合に、有効に機能します。デメリットとしては、状態が多くなるとその分だけ、サブクラスを作成しなければいかんくなることです。 Stateパターンで、修正前のコード内に、メッセージの表示用のオブジェクトprを毎回作成しているのに、気づいた方もいられるでしょう。これでは、メモリーを無駄に消費する可能性があります。このために、常にひとつのオブジェクトしか持たないクラスがあれば、便利です。このクラスのパターンをSigletonと呼びます。 インスタンスの数だけをコントロールするので、クラス内ではstaticで持っています。それでは、実際のJavaコードで見てみましょう。 このように、instance()が呼ばれたときに、すでに_instatnceが生成されていれば、そのオブジェクトを返して、そうでなければ、new PrintPanel()で生成します。 newで生成するのではなくて、PrintPabnel.instance()として、オブジェクトをもらうようにします。Singletonパターンのインスタンスの数は二つ以上にも拡張できます。実用上は、今回のEngineBoxと同様に、他のパターンと組み合わせて使うことが多くなるでしょう。 リアルタイムシステムで多く使われているWatchdogパターンです。Watchdogとは、装置を監視したりするプログラムで、他のプログラムから一定の間隔でポーリングや電文の応答を行う機能です。Watchdogプログラム内で、装置のエラーや電文シーケンスのアンマッチなどを見つけると、これらの送り手であるプログラムに通知を行います。通知は、サービスのリセットやシャットダウンなどが考えられます。組み込み系のプログラミングテクニックとしては、定番になっています。それでは、具体的にサンプルを見ていきます。この例では、サービスを受けるクラスをChannel、監視を行うのはWatchdogとしました。図１のクラス図からわかるように、Channelオブジェクトは複数存在できる仕様にしたいので、多重度を使用して表現しています。実際のJavaのコード上では、わかりやすくするためにひとつしか生成していません。 WatchdogオブジェクトからStart()メッセージをChannelに送り、サービスを開始します。その後にRequest(1)としてシーケンス番号（１）の電文を送り、番号（２）の電文も続けます。また、Watchdogオブジェクトでエラーを検出したときには、error()によりRestart()メッセージをChannelに送り、サービスをリセットします。実際のJavaのコードは次のようになります。 Watchdogオブジェクトがメイン部分で生成されると、ChannelオブジェクトもWatchdogの中で作られます。サービスの開始を始めたいので、この場合はwd.Connect()を呼び出して、その中でStart()メッセージをChannelに送っています。そうすると図２のシーケンス図の通り、Request(1)、Request(2)として電文をシーケンス番号を付加して送ります。この時の送り先のWatchdogオブジェクトは、Start(this)として、引数で渡してやります。ここでは、電文を受け取ったWatchdogオブジェクトは、単純にRequest()の中でシーケンス番号のチェックをしているだけです。さらに、メイン部分でWatchdogオブジェクトにエラーが起きた場合は、wd.error()として、このerror()の中でChannelオブジェクトにRestart()を送り、リセットを行います。このように、装置を監視するようなオブジェクトがある場合に、Watchdogパターンを有効に使うことができます。このWatchdogパターンは、「REAL-TIME UML」Addison -Wesley刊で解説されています。 |
[ 14] Technologic Arts Incorporated--推進技術
[引用サイト] http://www.tech-arts.co.jp/oo/pattern.html
|
パターン認識などとして使われるときは、規則性、体系などの意味で使われている。パターン認識は事象の特徴を認識して体系化して、理解することである。 繰り返し行い、誰が行っても結果に大差が無い行為について、手本のことをパターンと言う場合がある。 ただし、習字や絵、車の運転といった、常に結果が（ほぼ）異なる行為をあらかじめ見せる場合は「手本」と言うのが一般的である。 模様として使われる絵柄は繰り返しのつる草模様など見飽きることのない日常の装飾に使われる。このことは、人間の見たものを理解・認識・記憶などの、事象の抽象化の結果でもある。 また、抽象化された模様を見続けると異常反応を起こすなど、意識にかかわるような重大な影響を与える場合がある。有名なものでは渦巻き模様が一定の速度で回転するものや、5円玉を糸で吊るして揺らすのを延々と見続けると一種の催眠状態に陥る人もおり、極端に簡略化された模様が画面いっぱいに表示されるとき、テレビなどでは該当するシーンが放送される直前に注意がされる場合がある。 デザインを型にしてゆく作業or型紙でこれを起こす職業の人をパタンナーと言う。 ファッションデザイナーのパートナー的役割。 主にコンピュータゲームにおいて使用される。たとえば敵キャラの出現や攻撃のタイミングが決まっている場合、それによって、より楽にゲームを展開させることができる自機の操作や動きが場面ごとに特定される。これが「パターン」と呼ばれる。 パターンを考案し、それを実践することを「パターン化する」「パターンに入る」「パターンにはまる」などと言う。パターン化しやすいかそうでないかは「パターン性が強い/弱い」と表現される。パターンを使うことによって攻略や点数稼ぎの難易度が大きく変わるゲームは「パターンゲー（パターン+ゲーム）」と呼ばれる。アクションゲームやシューティングゲームなどはこの傾向が強い。 似た状態で、格闘ゲームなどでは「ハメ技」（対戦相手に一方的に攻撃を当て続けることができる状態）というものもある。 パターンの有無やその内容は、開発者が意図したものではないことが多い。ゲームシステムなどを逆手にとったもののほか、バグを利用したもの、「電源パターン」（電源を入れて一番最初のプレイにのみ適用できるパターン）なども存在し、これらは裏技の一種ともいえる。 パターンを覚えれば楽に攻略ができるため、上達度合いが分かりやすく、個人の素質による向き不向きが少ない。 パターン化するためにはある程度のやり込みが必要なため、アーケードゲームなどではその間の収入が見込める。 対戦をしたりハイスコアを競う形のゲームにおいては、パターンを知っているプレイヤーとそうでないプレイヤーの間に差が生じる。これは一種の情報格差といえる。 アーケードゲームの場合自分で料金を払ってのやり込みではなく、他人のプレイを見てパターンを覚える（いわゆる「パターンをスパる」）行為が発生しやすく、これを不快と感じるプレイヤーも多い。 |
[ 15] パターン - Wikipedia
[引用サイト] http://ja.wikipedia.org/wiki/%E3%83%91%E3%82%BF%E3%83%BC%E3%83%B3
|
第6回は「名前のない品質とパターン言語」と題して、建築家アレグザンダー（Christopher Alexander）の「名前のない品質」“QWAN―Quality Without a Name”を紹介しました。この名前のない品質を建築の世界でどのように実践すればよいか、アレグザンダーはそのための1つの技法として「パターン言語」を提唱しました。このパターン言語のアイデアに注目し、ソフトウェアの世界に持ち込まれたのが、1つはデザインパターンをはじめとする「ソフトウェアパターン」の潮流です。もう1つの流れはケント・ベックが提唱したXP（eXtream Programming）をはじめとする「アジャイル開発」の潮流です。 パターンやパターン言語とオブジェクト指向とはまったく異なる概念ですが、ソフトウェアパターンはなぜかオブジェクト指向開発の世界に入ってきました。今回は「パターンとパターン言語入門」と題して、ソフトウェア開発の2大潮流の基となったパターンとは何か、パターン言語とは何かについて解説したいと思います。 「複雑系 科学革命の震源地・サンタフェ研究所の天才たち」（M・ミッチェル・ワールドロップ著、新潮社）という数年前話題になった書籍があります。ノーベル賞級の最先端の頭脳が１カ所に集まって共同研究をするというサンタフェ研究所のユニークな記録です。 この本には経済学者ブライアン・アーサー（*1）がアルプスのチロル地方に行ったときの体験が記されています。彼によると、街は至る所チロル地方特有の家々が立ち並んでいるということです。つまり、チロルには“チロルのパターン”というものがあるのですが、オーストリアとイタリアの国境を一歩でも越えると、チロルの面影は消滅します。異なる街並みのパターンが出現するわけですね。「何年もかかって、2つの文化はどちらも、互いに異なる、しかし一貫したパターンにたどりついたのだ」とアーサーは本書で述べています。 2つの地方はどちらも雪に強い建築構造、街並みを目指してきましたが、同じ問題に対してそれぞれ異なる解決策に到達したというわけです。 パターンという言葉は日常生活でもよく使います。ある状況で、ある結果が出た場合、過去に何度も同様の状況で同様の結果となっていたならば、それは「いつものパターン」と呼びます。パターンという言葉の意味は、広辞苑（第5版）によると、“型。類型。様式。「ワン・パターン」。図案。図像。「テスト・パターン」”とあり、プログレッシブ英和中辞典（第3版）から主要な意味を抜粋すると「pattern」は“［1］型、様式。［2］（同じ図形が繰り返し現れる）模様。［3］模範、見本、雛形”というように説明しています。 例えば囲碁や将棋の定石はパターンといえます。定石とは、ある局面における対戦者双方にとっての最善の手筋であり、模範的な決まった型であって、patternの［3］の意味になります。定石は過去の事例を研究し尽くして抽出したものなので、これを利用すれば対局のたびに最初からいちいち攻め（守り）の手順を考え出す必要がなくなります。双方の指し手が対局のときに考えなければならないのは、その局面に適用できそうな定石から1つを選択することです。定石をどの程度使いこなせるかは、囲碁や将棋の技能の向上に大きな影響を与えます。 もう1つパターンの例を挙げてみましょう。洋服の型紙もパターンです。この例もpatternの意味の（3）です。型紙に合わせて生地を切って縫い合わせると洋服ができます。生地が違っても同じ型紙からは同じ形の洋服を仕立てることができます。 パターン言語で使用されるパターンという言葉は、次のようにもう少し特別な意味で使用します。すなわち、 「パターンとは、ある文脈で繰り返し起きる問題と、フォースと呼ばれる制約条件およびその下での問題の解決策の組」 です。1つの問題に対する解決策は必ずしも1つとは限りません。例えば先の囲碁や将棋の世界でも、定石には複数の選択肢があり得ます。この場合、戦略や周りの状況が、（解決策となる）定石の選択条件となります。これらの選択条件がフォースです。洋服の型紙も何通りかの選択肢があり得ます。この場合、男性用または女性用、フォーマルまたはカジュアルなどの条件がフォースで、その制約により解決策となる型紙が限定されます。 上述のパターンの定義はアレグザンダーが提唱したもので、ソフトウェアの世界でもほぼこの定義を継承しています。しかし、ピーター・コードが「戦略とパターンによるビジネスオブジェクトモデリング」（ピーター・コードほか著、ピアソンエデュケーション）の中で反論しているように、英語のpatternにはこのような意味はありません。ちなみにピーター・コードの定義は、 です。たくさんあるパターンからなぜ特別にそのパターンを選び出して模倣しなくてはならないのでしょうか。いま考えている問題の解として、それが最適だからでしょうね。結局、アレグザンダーのパターンの定義がソフトウェアの世界で認知されたのもこういう理由からだと思います。ゆえに、本稿ではアレグザンダーのパターンの定義に従って解説を進めます。 繰り返しますが、パターンとは「ある文脈で繰り返し起きる問題に対して、フォースと呼ばれる制約条件の下での解決策」です。パターン言語（Pattern Language）はある文脈でのパターンの集まりです。パターンの集合をなぜパターン言語と呼ぶのかちょっと分かりづらいので、自然言語と比較してみましょう。 個々のパターンは、自然言語の最小構成要素である単語に対応するものです。パターンはその記述方法が決められています。個々のパターンは孤立して存在するのではなく、相互に関係します。その関係もパターンで表現します。この関係は自然言語では文法に対応するものです。ある文脈で使用されるこれら複数のパターンからなる構造を持った集合がパターン言語です。 この「言語」（language）という言葉ですが、ちなみにUMLも「統一モデリング言語」という言語です。UMLは1つしかありませんが、パターン言語はいくつでも作ることができます。自然言語には日本語、英語、フランス語、……といろいろあるように、パターン言語もいろいろ作ることができるわけです。アレグザンダーの書籍「パタン・ランゲージ―環境設計の手引」（クリストファー・アレグザンダー著、鹿島出版）のタイトルも“A Pattern Language”でパターン言語の冠詞は定冠詞“The”ではなく不定冠詞“A”が使われていますので、1つのパターン言語という意味です。これがUMLという言語との大きな違いです。 アレグザンダーのパターン言語には街や建物、建設に関する253のパターンがまとめられています。これは中埜博著「パタン・ランゲージによる住まいづくり」（井上書院）に分かりやすく紹介されています。そこからいくつか紹介します。番号はアレグザンダーのパターン言語の番号です。 建物の中で、自分がどこにいるのか分からなくなってしまうのはストレスがたまる。要所要所に目印が欲しい この例は個々のパターンを簡略化して表現しましたが、アレグザンダーのオリジナル書籍にはそれぞれ「問題＋フォース＋解決策」という形式で数ページにわたって詳細に記述されています。オリジナルにはすべてそのパターンを示唆する写真が最初のページに添付されていることも特徴です。 家を建てるとき、住む人にとっては間取りが基本ですが、それ以外に依頼主はさまざまな注文を付けます。例えば自然光が入るようにしてほしい（107 光の入る棟）、土地が狭いので屋上に庭を造ってほしい（118 屋上庭）、部屋の一部を独立性を持たせて人に貸せるようにしてほしい（153 貸せる部屋）、……など数え上げるといろいろ出てきます。繰り返し出されるこれらの要求に対してその解決策をパターンとしてすでに用意しているわけです。253パターンの中には街のレベルから個人の家のレベルまでさまざまなパターンが挙げられています。家を建てる建築家（アーキテクトビルダー）はこれらのパターンをあらかじめ用意しておけば依頼主の要求にすぐに応えることができるわけです。ちなみに中埜博さんはこのような技法を実践されている日本では数少ない建築家です。一味違う注文住宅ができそうですね。 ソフトウェア開発の世界でも注文住宅と同じで、依頼主からさまざまな要求が挙げられます。繰り返し挙げられる要求に対してはあらかじめ対応策を用意することが可能です。そのアイデアがソフトウェアパターンです。 ソフトウェア開発の世界で、パターンはさまざまな局面で現れます。要求レベル、分析レベル、設計レベル、コーディングレベルあるいは基本的骨組みであるアーキテクチャ設計レベルなどにソフトウェアパターンが適用できます。要求レベルのパターンも当然あってしかるべきですが、まだ未整備でこれからの課題であると考えています。 アーキテクチャレベルのパターン。レイヤー、MVC、パイプとフィルタなど古くから知られているパターンの集大成 ソフトウェアそのものではなく、ソフトウェア開発プロセスにもパターン言語の考え方が適用できます。アンチパターンは開発プロセスに焦点をあて、失敗に陥るパターンに注目して類型化し、その対応策を示すものです。しかし、開発プロセスの問題はそんなに簡単に解決できるものではありません。これは単独のパターンではなく複数のパターンから構成されるパターン言語の適用分野です。 RUPやXPといった開発プロセスはベストプラクティスがベースになっています。RUPは6つ、XPは12〜14程度のプラクティスがプロセスの基本原則になっています。これらのプラクティス1つ1つはある問題に対する解決策でパターンと考えることができます。これらのパターンの相乗効果を生み出すのがパターン言語です。実際RUPもXPもすべてのプラクティスの実践による相乗効果を目指しています。 アレグザンダーは名前のない品質（QWAN）を建築で実践するための技法として「パターン言語」を提唱しました。第6回「名前のない品質とパターン言語」ではこのQWANについて、今回はパターンとパターン言語の概要についてお話ししました。ソフトウェア開発の2大潮流となったデザインパターンなどの「ソフトウェアパターン」とケント・ベックのXPをはじめとする「アジャイル開発」のルーツは、実はこのアレグザンダーのパターン言語だったのです。 次回は話題を変えて「分析と設計」について考えてみたいと思います。オブジェクト指向分析・設計では分析と設計は隣り合わせですが、「分析（analysis）」と「設計（design）」はまったく別の概念でこの間には無限のギャップを感じています……。 なお、筆者主催のオブジェクト指向教育オープンコースを開催しています。詳細は有限会社オブジェクトデザイン研究所のホームページをご参照ください。皆さまとお会いできることを楽しみにしています。 ・M・ミッチェル・ワールドロップ著、「複雑系 科学革命の震源地・サンタフェ研究所の天才たち」、新潮社 ・クリストファー・アレグザンダー著、「パタン・ランゲージ 環境設計の手引」、鹿島出版 ・F・ブッシュマンほか著、「ソフトウェアアーキテクチャ ソフトウェア開発のためのパターン体系」、近代科学社 ・エリック・ガンマほか著、「オブジェクト指向における再利用のためのデザインパターン」、ソフトバンク パブリッシング ・マーチン・ファウラー著、「アナリシスパターン―再利用可能なオブジェクトモデル」、ピアソンエデュケーション ・ハンス＝エリク・エリクソン、マグヌス・ペンカー著、「UMLによるビジネスモデリング」、ソフトバンク パブリッシング ・ピーター・コードほか著、「戦略とパターンによるビジネスオブジェクトモデリング」、ピアソンエデュケーション ・W・J・ブラウン ほか、「アンチパターン ソフトウェア危篤患者の救出」、ソフトバンク パブリッシング 大阪大学理学部数学科卒業、日本ユニシス株式会社にてメインフレームのOS保守、性能評価の後、PCのGUI系基本ソフト開発、クライアント／サーバシステム開発を通してオブジェクト指向分析・設計に携わる。 オブジェクト指向の本質を追究すべく1998年に独立後、有限会社オブジェクトデザイン研究所設立、理論と実践を目指し現在に至る。ビジネスモデリング、パターン言語の学習と普及を行うコミュニティ活動に参画。ホームページ「オブジェクト指向と哲学」 。 『JavaデベロッパーのためのUML入門』（監修）。著書は『まるごと図解 最新オブジェクト指向がわかる』『まるごと図解 最新UMLがわかる』（共に技術評論社）、『明解UML−オブジェクト指向＆モデリング入門』（秀和システム）。 JavaやUMLといったソフトウェア開発の話題とは少し離れて、オブジェクト指向そのものの哲学的意味を考えてみたいと思います 情報マネージャのための「今日のひと言」 - 2007/11/28『人脈』 自分1人の力ではどうにもならないことがあります。そういうときに頼りになるのは……>>続きはクリック 技術者としての力量を数値で把握していますか？ITSSレベルを無料で判定、12月25日（火）まで ホワイトペーパー利用者に「Amazonギフト券」を抽選で100名様にプレゼント！――TechTargetジャパン リニューアル・キャンペーン ＠IT情報マネジメント トップ｜アーキテクチャ トップ｜会議室｜利用規約｜プライバシーポリシー｜サイトマップ |
[ 16] ＠IT：オブジェクト指向の世界 （7）
[引用サイト] http://www.atmarkit.co.jp/farc/rensai/column/world07/world07.html
