オブジェクト指向

1. はじめに

皆さん、こんにちは。私はオージス総研でオブジェクト指向技術を用いたSI、コンサルティングを業務とする、プロの仕事を目指す、一介のUMLシルバーレベル¹のプログラマ²です。ソフトウェア業界では、オブジェクト指向も、もはや普通の技術として認知されています。有名なマイクロソフトのVB、VC++をはじめ、現在使用している開発環境のほとんどは、すべてオブジェクト指向をサポートしているといってもよいでしょう。オブジェクト指向を知らない人でも、気が付かないうちにオブジェクト指向している、なんてこともあるようです。

でもオブジェクト指向は、単にソフトウェアをより良く作るための手段のひとつですから、上手く利用しないと、そうするつもりはなくても、とんでもないソフトウェアを作ってしまうことになりかねません。悲しいことに、オブジェクト指向は結構敷居が高いと思います。オブジェクト指向のメリットである(といわれている)「理解性」、「拡張性」の高い「再利用」可能なソフトウェアを作ることは簡単ではありません。実際に、私は未だ到達しておりません (オイオイ(^^;;)。

本記事では、特に構造化手法なんてしらない/必要ないと思っているオブジェクト指向エンジニアの方向けに、構造化手法の「凝集度と結合度」を紹介し、オブジェクト指向においても有効であることをお伝えしたいと思います。

2. ソフトウェア開発の難しさ

2.1. システムの問題点 ～ 複雑さ(complexity) ～

ソフトウェア開発の難しさって何だと思いますか？要求あるいは仕様が曖昧だったり、使用する技術自体が新しく不安定だったりなど、いろいろあると思います。なかでも、複雑さがソフトウェア開発を難しいものにしていることは間違いありません。ではその複雑さってなんでしょう。最近、組込み業界では要求の複雑さが問題になっており、がぜんオブジェクト指向に脚光が浴びせられています。

他にも複雑さはありませんか？エンジニアの方なら分かるでしょう。そう、人の書いたソフトウェアを保守する方ならいつもお悩みの種になっている、開発するソフトウェアそのものの複雑さです。

つまり、ソフトウェア開発においては、さまざまな複雑さがあって、開発を困難なものにしている訳です。

2.2. オブジェクト指向の難しさ

また、「はじめに」のところでオブジェクト指向は敷居が高いといいましたが、皆さんにとって、オブジェクト指向って難しくありませんか/でしたか？

私が勉強をはじめた頃のナイーブなオブジェクト指向の世界では、システムの振る舞いを記述するためのユースケースなんてものはなく、顧客からの要求文を元に、いきなりクラスを抽出してクラス図なるものを作成するというものでした。「だって、オブジェクト指向なんだもん。そりゃ勿論システムの機能も大事だけど、拡張性や再利用性を考えるならオブジェクト(モノ)に局所化することが大事なのさ」というような著者の声が聞こえてきました。

また、「オブジェクト指向は現実世界をモデル化したものだから(お客さんにも)分かりやすいのさ」ともありましたね。だけど、そういうオブジェクト(モノ)を発見し、定義していくのは難しいです。そこに登場するオブジェクトが適切なモノでなければ、ソフトウェアの複雑さは増してしまいます。では、どうやって適切なオブジェクトを定義すればよいのでしょうか？

理想は、誰が見ても明らかな、つまり適切な責務を持ったオブジェクトが書かれたクラス図です。それぞれ人によって、システムあるいはソフトウェアを眺める視点が違いますので、唯一の正解はありませんが、これを作成するのはなかなか難しいと思います。適切なオブジェクトを定義するための、また、それを評価するための「ものさし」が必要だったのです。

ユースケースでシステム要件を記述することが、なかば当たり前になった現在においても、オブジェクト指向の中心的存在であるクラス図については、これを書くのは(特に良いものを書きたい場合には)難しいものであることは変わっていないようです。ユースケースを実現するようなオブジェクトを見つけるといわれてもやはり難しいですし、ユースケースからBoundary、Controller、Entityの役割を持ったオブジェクトを抽出するロバストネス分析もありますが、これでもなかなか上手くいきません。

次の章では、今述べた、プログラムの難しさに対処する方法として、「凝集度と結合度」が有効であることを紹介します。

3. プログラムの複雑さに対処する方法

前章で、プログラム開発を難しくしている要因の一つとして挙げたプログラムの複雑さですが、これに対処する方法として、プログラムの複雑さを計る「ものさし」となる凝集度と結合度について紹介します。また、この凝集度と結合度を、オブジェクト指向による開発で一番重要な、オブジェクト(モノ)への適切な責務の分配に適用した例として、『実践UML』のGRASPパターン(General Responsibilities Assignment Software Pattern)を紹介します。

それでは、順に見ていきましょう。

3.1. 凝集度と結合度(『ソフトウェアの複合/構造化設計』より)

凝集度と結合度の話しをはじめる前に、混乱を避けるため、用語の問題を片付けておきましょう。「凝集度」はコヒージョン(cohesion)ですが、凝結度、凝集性などと使われることもあります。私が参照した本では、強度(strength)と呼んでいます。本記事では、まことに勝手ながら、これらを意味する用語として凝集度を使用します。理由は、私がはじめて目にした用語がこれだったからです。いつかこれ(凝集度のこと)を制覇するのが私の夢でしたので、他の用語ではダメなのです(^^;;。

もう一つ、凝集度と結合度を計る対象として「モジュール」という用語が使われています。『複合/構造化設計』では以下のようにモジュールを定義しています。

「プログラム構造の基本単位はモジュールと呼ばれる。モジュールは実行可能なプログラムの命令の集合であり、つぎの基準に合致する必要がある。

1. 閉じたサブルーチンであること
2. プログラム内の他のどんなモジュールからも呼び出すことができること
3. 独立してコンパイルできる可能性をもっていること

2、3の基準については、あくまで“可能性”についていっているものである。モジュールは他の全てのモジュールから呼び出されなければならないとか、独立してコンパイルしなければならないことを意味している訳ではない。」

長い引用でしたが、結局のところ、プログラムの断片です。C言語で書かれたプログラムの場合、モジュールを関数と置き換えても良いのですが、オブジェクト指向では、クラス、クラスの持つメソッドとして考えるのが良さそうです。もちろん、責務を持つパッケージやサブシステムも含めて考えましょう。ではいよいよ、凝集度と結合度にいきましょう。

モジュールの独立性を高くするための、2つの側面として凝集度と結合度という尺度を用います。

1. 各モジュール内の関連性を最大にすること ・・・凝集度
2. モジュール間の関連性を最小にすること ・・・ 結合度

3.1.1. 凝集度

凝集度とは、単一モジュール内の要素間の関連性についての一つの尺度です。プログラムの構造の"良さ"あるいは"悪さ"を評価する尺度として用いることができます。凝集度は、望ましいものから順に、以下のように分類されます。

1. 機能的凝集度と情報的凝集度
2. 連絡的凝集度
3. 手順的凝集度
4. 時間的凝集度
5. 論理的凝集度
6. 暗合的凝集度

暗合的凝集度は、機能を定義することすらできないモジュールのことです。何を根拠にモジュールになっているのか説明できないような、論外の状態です。暗合的凝集度の問題点としては、複雑さを増すという点で長いスパゲッティコードよりも悪いものです。

論理的凝集度は、関連したいくつかの機能を持っていて、呼び出しモジュールによって選択され、実行するモジュールのことです。イベントによる処理の振り分け制御などが該当します。

時間的凝集度は、関連の少ない幾つかの機能を逐次的に実行するモジュールのことです。ここで逐次的とは、特定のタイミングで動くことを意味しています(ちなみに、本家の「構造化設計」では、一時的凝集度と呼んでいます)。初期化処理や終了処理ではよくあるケースですね。

手順的凝集度は、仕様によって定められた、関連の少ない複数の機能を逐次的に実行するモジュールのことです。

連絡的凝集度は、データに関連のある複数の機能を逐次的に実行するモジュールのことです。これらはどれも、複数の機能を逐次的に実行するものですが、データに関係があるものからないものまでを細かく分類したものです。

機能的凝集度は、１つの固有の機能を実行するモジュールのことです。Simple is best! ですね。

情報的凝集度は、概念、データ構造、資源などを1つのモジュール内に隔離したモジュールのことです。特徴として、多重入口点(複数のメソッド)、各入口点は単一の機能、機能のすべてはモジュール内に収められた概念、データ構造、資源に関連するもの、というものです。これはオブジェクト指向のカプセル化に他なりませんよね。

3.1.2. 結合度

結合度は、主に、モジュール間の関連性についての尺度です。結合度を小さく保つために、モジュール間の不要な関連性をなくすことと、必要とされる関連性の強さをできるだけ小さくするという、2つの面から考えることが必要です。結合度は、望ましいものから順に、以下のように分類されます。

1. 非直接結合 ・・・ 何も関係ない(分析において使用する)
2. データ結合
3. スタンプ結合
4. 制御結合
5. 外部結合
6. 共通結合
7. 内容結合

内容結合は、一番良くない関連で、2つのモジュールで、1つが他の内部を「直接」参照するケースなどです。これはカプセル化を破るものとして、論外と言えるでしょう。

共通結合は、グローバル(大域的)な、データ構造を参照するモジュールのグループの間で生じるものです。グローバルデータを使用することの問題点については以下のようなものがあります。

1. プログラムの可読性を低下させてしまいます
2. はっきり関連していないモジュール間に依存性を発生させる原因となってしまうため、修正時の予期せぬ影響を発生させてしまいます。
3. グローバルデータを使用しているモジュールの再利用性がなくなってしまいます
4. 必要以上のデータをモジュールにさらしてしまいます
5. データ・アクセスの管理と制御が上手くできなくなってしまいます

なにより、「システムを必要以上に複雑にし、拡張性をそこない、デバッグを難しくしてしまう」という問題が大きいです。

外部結合は、内容結合でも共通結合でもなく、単一のグローバルデータを参照しているものです。共通結合との違いは、共通結合ではデータ構造と関連しているのに対して、外部結合は単一のデータと関連していることです。共有メモリを使ったアクセスなどはこれらに該当します。グローバルデータに関連しているというのは、あまりお勧めできません。グローバルオブジェクトの場合、メソッドを介してのアクセスとなるため、再利用性については問題ありますが、アクセスの制御を行うことは可能です。

制御結合は、1つのモジュールが他のモジュールの論理をはっきりと制御する関連です。制御されるモジュールの凝集度は、おそらく論理的凝集度になり、パラメータとして渡される制御要素としては機能コード、制御スイッチなどがあります。システムイベントの実行を振り分ける主制御などは、これを用いた方が良いケースもあります。

スタンプ結合は、2つのモジュール間でやり取りするデータがグローバルではないものです。ただし、データ構造などで不必要なデータを含んでいるケースです。スタンプ結合の問題点は、グローバルデータの問題点を除いた共通結合と同様です。

1. 渡されるデータ構造に依存するため、無関係なデータ構造の変更にも影響を受けてしまいます
2. 他のプログラムで「再利用」することが難しくなってしまいます
3. モジュールに必要以上のデータをさらしてしまいます

この結果、「モジュールの複雑性を増加させ、結果としてエラーを増加させる」ことが問題になります。

データ結合は最も良い関連で、モジュール間のインタフェースデータが単一のデータであるものです。「データ結合は、モジュールの独立性、モジュールの再利用性、エラー傾向、拡張性、保守性、テストの容易さといった面に有益な効果をもっている」ということになります。

スタンプ結合かデータ結合のどちらを採用するかについてはトレードオフがあります。不必要なデータを渡さないという意味ではデータ結合の方が、モジュール間の関連は良いのは分かりますが、データオブジェクトとして、適切なオブジェクトを引き渡す場合にはスタンプ結合でも十分だと思います。

3.2 GRASPパターン(『実践UML』より)

一方のオブジェクト指向では、凝集度と結合度について論じた本は少ないのですが、重要な責務の割り当ての原則として、これを明記した本があります。『実践UML』では、「システムを成功させる決定的な鍵は、究極のスキルとして責務の割り当ての方法を会得すること」と言い切っています。理由としては、責務の割り当ては避けて通れない作業であり、ソフトウェアコンポーネントの頑強さ、保守性、再利用性に最も大きな影響をもつものだからです。

ちなみに、『リファクタリング』(M. Fowler著)では、これ(責務の割り当て)は難しいが、リファクタリングによって後で改善することが可能と述べられていますが、私は枕詞に「ある程度までは」が必要だと思います。

さて、GRASPパターンを見てみましょう。

□ GRASP(General Responsibility Assignment Software Pattern)パターン

オブジェクトへの責務割り当てに関する基本原則をパターンの形式で記述したものです。オブジェクト指向ソフトウェア設計を成功に導くにはこれらの原則のgrasping(理解)が重要である、ということを捩ったものだそうです。

GRASPパターンは、以下の9つの基本原則から構成されています。

1. Expert(エキスパート)
2. Creator(生成者)
3. High Cohesion(高い凝集度)
4. Low Coupling(疎な結合度)
5. Controller(コントローラ)
6. Polymorphism(多様性)
7. Pure Fabrication(純粋架空物)
8. Indirection(間接化)
9. Don't Talk to Strangers(未知の存在には話しかけない)

思い切り端折りますが、以下では、1 から 4 までについて見ていきます。

3.2.1 Expert(エキスパート)

Expertとは、責務を割り当てるときの最も基本的な原則です。「責務の遂行に必要な情報を持っているクラス、すなわち情報エキスパートに責務を割り当てる」ことです。ここで注意すべきは、必ずしも単一のオブジェクトが責務を遂行するのではないということです。

「つまり、当該のタスクにおいて多数の「部分的な」エキスパートが協調する」ということなのです。これは、複合/構造化設計においても全く同じで、機能的凝集度の記述で単一の機能を実行するものとありますが、これも単一のモジュールではなく、従属モジュールを含んでいても構わないのです。

ちなみに、Peter Coad氏は、これを「自分で行う」(Do it Myself)戦略」と呼んでいるそうです。つまり、ソフトウェアオブジェクトは自分の知っている情報に関連した何かを行うということです。これをオブジェクト指向設計における「アニメ化 (animation)原則」といいます。ピンときませんけど(^^;;。

Expertによる責務の分担のメリットとしては、以下のことが挙げられます。

1. カプセル化が維持され、頑強で保守性の高い、低い結合度(low coupling)を支援します
2. 複数のクラスに振る舞いが分散されるため、より高い凝集度の軽量クラスの定義が促進されます

3.2.2 Creator(生成者)

Creatorはインスタンスを生成する責務を持つクラスを決めるための原則です。

オブジェクト生成に関する責務の割り当ての指針としては、「生成されたオブジェクトと何らかのイベントにおいて接続する必要性のある生産者を見つけ、これを生産者として選定する」ことです。メリットは、結合度を低く保てることです。

3.2.3 High Cohesion(高凝集性)

これは凝集度のことで「凝集度を高く維持できるように責務を割り当てる」ための原則です。

オブジェクト指向においては、凝集度は、クラスの責務がどの程度強く関係し、集束しているかを示す基準になります。凝集度の低いクラスは、関係のない仕事をこなしたり、仕事が大量になったりしてしまいます。こうなると、理解性、再利用性、保守性に乏しく、脆弱で変更による影響が大きくなってしまいます。

Grady Booch氏曰く「高い凝集度は、あるコンポーネント(クラスなど)の要素が「協力し合って、適切な境界のある何らかの振る舞いを行う」ときに存在する」もの。

『実践UML』では機能凝集度の段階を以下のように分類しています。前述の凝集度の分類とは異なりますが、これは関数を視点とするものとクラスを視点とするものとの違いと考えられます。これについては、既に触れましたが、構造化手法では「関数」を単位としているのに対し、オブジェクト指向では、クラス、クラスのメソッドの両方(更にはパッケージ、サブシステムまで)を含んでいるという違いがあります。これを意識しないで作った(低い凝集度の)クラスの例として、何も考えずに機能を集めてしまった「肥満児」アンチパターンなどが有名です。これは、VBなどGUI形式のRADツールを使って設計もなしに開発を行っていると、気が付いたときにはFormクラスがそうなってしまっていたりしますね。

1. 非常に低い凝集性：機能が大きく異なる複数の分野で多くの作業の責務を単独で負うクラス
2. 低い凝集性：1つの機能分野での複雑なタスクの責務を単独で行うクラス
3. 高い凝集性：1つの機能分野で適度の責務を持ち、タスクを遂行するために他のクラスと協調するクラス
4. 中程度の凝集性：論理的にクラスの概念に関係するが、相互には関係していない、少数の異なる分野での単独の責務を負う、軽量なクラス

3.2.4 Low Coupling(疎結合性)

これは結合度のことで「結合性を疎に保つように責務を割り当てる」ための原則です。

低い結合度は、変更の影響の少ない、より高い独立性と、高い生産性につながる、より高い再利用性をもつクラスの設計の助けとなります。特に結合度を考慮するポイントとしては、再利用する単位で捉えると良いでしょう。コンポーネントとして再利用するパッケージの単位や、インタフェースを必要とする箇所で、詳しく検討するべきです。低い結合度のメリットは、他のコンポーネントの変化に影響されない、分離して理解しやすい、再利用性が高くなるといったことが挙げられます。

□ 販売時点管理(POS)端末アプリケーションの例

POS端末(POST)、支払い(Payment)、販売(Sale)の3つのクラスがあります。ここで、Paymentのインスタンスを生成し、それをSaleと関連づける必要があるとします。このための責務を負うのはどのクラスが良いのでしょうか？

現実世界の領域では、POS端末(POST)が支払い(Payment)を記録するため、Creatorパターンによれば、POSTがPayment生成の責務を担当する候補になります。POSTインスタンスは次に、新しいPaymentをパラメータとし、addPaymentメッセージをSaleに送ります(図1を参照して下さい)。

別の方法として、POS端末(POST)が依頼することによって、販売(Sale)が支払い(Payment)を生成し関連づけるものがあります(図2を参照して下さい)。

責務の割り当てを基準として考える場合、どちらの設計が高い凝集度、低い結合度という目標に適っているでしょう？どちらの設計でも販売(Sale)が最終的には支払い(Payment)への知識に結び付けられている点は同じです。

図1では、POS端末から支払いへの結合を追加してあるのに対して、図2では結合を強めていません。結合度の観点からは、全体的に低い結合度になっている図2の設計の方が望ましいといえます。

一方、図1では支払いの責務をPOS端末(POST)に置いています。つまり、POSTはmakePaymentという操作を遂行する責務の一部を担当します。この例(支払いを行う)だけなら問題ありませんが、POSTクラスの責務をさらに多くの操作に広げていくと、POSTクラスの負担が大きくなってしまいそうですよね。すべてのPOS操作(のシステムイベントメッセージ)が、POSTクラスによって受け取られて処理されることを想像してみれば、POSTクラスが不相応に膨張した凝集度の低いものになってしまうことはいうまでもないでしょう。ここで問題となるのは、責務割り当て全体を大きく見たときに凝集度が低い方向へ進んでしまう傾向が生じることです。

図2では、支払い(Payment)生成の責務を販売(Sale)に委ねています。この方法は、POSTの凝集度を高くします。凝集度の観点からも、図2の設計の方が望ましいといえます。よって、高い凝集度と低い結合度を満たす図2の方が望ましいと判断できます。

このように、単にCreatorの原則だけで責務を分配するのではなく、凝集度、結合度についても常に検討することで望ましい結果を生みます。

4. 最後に

本記事で紹介した、凝集度と結合度は、プログラムの複雑さに対処するための、プログラムの独立性を計る「ものさし」です。一方のGRASPパターンは、これを用いて責務を分配するための手順をまとめたものです。この難しい責務の分配にも、凝集度と結合度は有効でしたね。

他にも要求(要求/仕様のたび重なる変更)など、複雑さはいろいろあります。これらに対処するためにも、それぞれ、ものさしとしての尺度が必要です(例えば、要求ならファンクションポイントだとか、変更なら変更回数のメトリクスなど)。きっと、良いものは、時代を超えて良いものであり続けます。Myers氏の例(情報的強度)もあり、きっとそういう技術がベースになって、既存の問題点を改善した新しい技術が生まれているのです。オブジェクト指向で、凝集度や結合度について触れている本が少ない(というか、ほとんどない)ですが、それはきっと、当たり前のこと(技術)として考えられているのでしょう。

さあ、あなたも古き良き「ものさし」を使って、もっと良いソフトウェアを作りましょう！

5. 参考文献

本記事では、以下の書籍(特に1)と2))を参考にしています。本記事を読んで興味を持った方は、是非とも以下の書籍を読んで、正しい技術を身に付けてください。

1. 1) 『実践UML：パターンによるオブジェクト指向開発ガイド』(Craig Larman著)依田光江 訳、今野睦、依田智夫 監訳、プレンティスホール、ISBN4-89471-077-3
   • オブジェクト指向の原点は、適切にオブジェクトに責務を与えることです。これを考えるためのものさしとしてGRASPパターンは秀作です。
   • またこの本は、繰り返し開発がどんなものなのかを知るのにも役立ちます。実際に章立てが2回のイテレーションに分かれており、どんな違いがあるのか具体的に示されています(もちろん、現実の開発では、いろいろな条件でイテレーションごとの目的は異なったものになります)。
2. 2) 『ソフトウェアの複合/構造化設計』(Glenford J. Myers著)国友義久、伊藤武夫 訳、近代科学社、ISBN4-7649-0052-1
   • 構造化設計で凝集度と結合度といえば、Yourdon/Constantine両氏でしょうが、翻訳本が入手困難である現在、この本を読まずしてはいられないでしょう。
   • しかも、Myers氏はYourdon氏たちにはない、情報的強度(凝集度)を機能的凝集度に並ぶ良いものとして掲げています。この人は、この時代からオブジェクト指向で考えていたに違いありません。未だ現役ばりばり良書の一冊。
3. 3) 『構造化設計のためのテキスト・ブック(凝集度/結合度)』 ((株)システムクリエイツ 清水吉男 著)
   • 未出版物のため入手困難です。
   • かつて、私がはじめて凝集度、結合度という用語に出会ったのはこのテキストからでした。当時 (現在でも!?)、全く理解できずにいたことは言うまでもありませんが(^^;;

ご興味のある方のために、Webページを紹介しておきます(気をつけて行ってらっしゃい(^o^)/~)。

• ソフトウェアエンジニアのためのホームページ： https://homepage3.nifty.com/koha_hp/
• SCだより(「ソフトウェア開発201の鉄則 設計の原理73 カップリングとコピージョンをつかえ」)： https://homepage3.nifty.com/koha_hp/SCNews/hpblock96/SCNews96.html#anchor830805
• キーワード(凝集度と結合度)： https://homepage3.nifty.com/koha_hp/KeyWords/KW.Coupling.html

その他、凝集度と結合度に関して書かれた文献としては、

1. 4) "Structured Design" Yourdon/Constantine, Prentice Hall, 1979
   • これが原典だそうです。残念ながら翻訳本である『ソフトウェア構造化設計技法』(日経BP)は既に廃刊となっており、入手は困難のようです。
2. 5) 『コードコンプリート』(Steve McConnell著)、石川勝 訳、アスキー(マイクロソフトプレス)、ISBN4-7561-0210-7
   • 設計者、プログラマには今でもお勧めの一冊です。特に、エンジニアとしてのこだわりを大切にする人なら、この本を読んで、理論武装すると良いでしょう。また、レビューのチェックリストやコーディングルールを作らなければならない人にもお勧めです。規律を作るにはしっかりした理由が必要だからです。
3. 6) 『ソフトウェア開発201の鉄則』(アランM.デービス 著)、松原友夫 訳、日経BP、ISBN4-8222-9002-6
   • この本の 「設計の原理73 カップリングとコヒージョンを使え」に書かれています。その他、ソフトウェア開発の失敗を防ぐノウハウが201個の原則（鉄則）としてまとめられた良書です。時々、立ち止まってこの本に帰るのが鉄則(らしい(^^;;)です。

番外編：読者へのメッセージ

いかがだったでしょうか？腕に覚えのあるエンジニアの方から「そんなの当たり前じゃん」という声も聞こえてきそうですけど・・・。実は私自身が凝集度と結合度について軽視していたのかもしれません。

番外編として、最後に私からのメッセージです。

「仕事は楽しく」やりましょう。

この業界、エンジニアリングとしては未成熟だというのが大方の見解ですが、そんな業界に身を置いているからこそ、どんどん良い方向へ「変化」しているわけですし、常に新しい発見ができるのです(と私は思っています)。なんて楽しい業界でしょうか。

エンジニアリングは俗人性を排したものだとして、たとえ、ソフトウェア開発がエンジニアリングに到達したとしても、やはり、人間らしく(人生の半分も費やしている)仕事を楽しみたい、というのが私の本音です。ちなみにエニアグラム(9つの性格)によれば、私は「タイプ4：夢見る人」です。いつも、隣の芝は青く見えます(^^;;。次に寄稿する機会があれば、今回の続編や、「ナイーブなオブジェクト指向への招待」、「好きなデザインパターンに見る人間像」または「デザインパターン占い」、「コンサルタントってどんな仕事？」なども書いてみたいと思っています。なんと統一感のないことか(^^;;。

今回、記事を書いてみて、だらだら長くなってしまった割に、狙っていた技術的な話題にあまり触れることができませんでした(複雑さを増した暗合的凝集度な記事なのかもしれません(^^;;)。本記事に不足するものは、参考文献を参照していただき、読者自身で補って下さい。

またこの記事の、こんなところが良かったとか、そんな訳ないだろうとか、何でも結構ですので、ご意見、ご感想を是非お聞かせ下さい。批判であっても反応があることは筆者には望外の喜びです。こんな記事よりもっと良い方法があるぜ、という方。あなたは正常です。だってプロなんですから。

Let’s enjoy “object” programming!