デザインパターン

デザインパターンはとは、書籍「オブジェクト指向における再利用のためのデザインパターン」において、所謂GoFと呼ばれる先人たちが、ソフトウェアに導入にしたオブジェクト指向におけるプログラム設計のパターンです。

これらのデザインパターンを使用してクラス設計することで、開発チーム内の用語統一化が進み、意思統一が図りやすくなります。

GoFのデザインパターンでは、23のデザインパターンが用意されています。

生成に関するパターン

• Singletonパターン
• FactoryMethodパターン
• AbstractFactoryパターン
• Builderパターン
• Prototype パターン

構造に関するパターン

• Adapterパターン
• Bridgeパターン
• Compositeパターン
• Decoratorパターン
• Facadeパターン
• Flyweightパターン
• Proxyパターン

振る舞いに関するパターン

• ChainOfResponsibilityパターン
• Commandパターン
• Interpreterパターン
• Iteratorパターン
• Mediatorパターン
• Mementoパターン
• Observerパターン
• Stateパターン
• Strategyパターン
• TemplateMethod パターン
• Visitorパターン

Singletonパターン

Singletonパターン(シングルトン)を使用する場合、そのクラスのインスタンスが1つしか生成されないことを保証することができます。

Singletonパターンでは、様々なクラスから呼び出しが可能となります。

ただし、ステートフルに実装してしまうと、グローバル変数のように、プログラムの依存性が煩雑化し、構造が悪化するケースがあります。

安易にシングルトン化することは、非常に危険な行為ですので、十分に考慮する必要があります。

実装例

• コンストラクタはprivateで定義する。
• staticで、かつprivateで自分のインスタンスをもつ。
• staticメソッドでgetInstance()メソッドを定義する。

---


public class MySingleton {
private static final MySingleton singleton = new MySingleton();
private MySingleton(){}
public static MySingleton getInstance(){
return singleton;
}
}


---

誤った実装例

以前、以下のような中途半端なSingletonを見たことがあります。

---


public class MySingleton {
private static MySingleton singleton;
private MySingleton(){}
public static MySingleton getInstance(){
if(singleton == null){
singleton = new MySingleton();
}
return singleton;
}
}


---

上記の実装を行った場合、getInstance()が非同期呼び出しに対応できていません。

そのため、getInstance()をsynchronizedする必要が出てきます。もし、synchronizedした場合、呼び出し単位で同期をとるため、性能への影響が発生します。

ハーバード白熱教室

マイケル・サンデルさんの東京大学での講義がNHKでやってるのを見ました。

以前も海外バージョンで放送されているのを見た覚えがありましたが、今回の講義は、日本を取り巻く具体的問題を取り上げているため、非常に面白い。

「正義」を以下の３つの考えを元に議論を進めていた。

• イギリス功利主義哲学者ベンサムの「最大多数の最大幸福」
• ドイツ哲学者カントの「人間の尊厳に価値をおく」
• 古代ギリシャ哲学者アリストテレスの「美徳と共通善をたたえ育むこと」

３人の船員と１人の給仕「リチャード・パーカー」が救命ボートに乗り、気分が悪くなった若い給仕を殺して、その肉を食べて生き延びたという事例から、議論を行い、道徳観を浮かび上がらせている。

そして原爆と謝罪。コミュニティに対する考え。非常に楽しくテレビを見れたわけです。

インパール作戦―最初からデスマーチ―

野中郁次郎さんの講演を聴く機会があったのですが、いくつかの深い話を聞けて感心したわけです。まさに賢人と言っても、過言ではないと思います。そんなきっかけから、以前買った「失敗の本質」を読み直したわけです。この日本的な組織作りに関して、いかにも野中さんらしさのある、非常に鋭い考察がされている。

さて、私がこのまえまで進めていたプロジェクトが10月に完了し、やっと一息つける状態になったわけですが、乗り越えてみたものの様々な反省点がある。何と言っても、プロジェクト当初からデスマーチ化することを予想し得るほどの、超短納期なプロジェクト計画に無理があった。本来は、納期というものは大概プロジェクトを担当する人間が、本来計画するもの。ただし、今回は部門の長が先に納期を決めてしまった。

たしかに、最近の市場の要求の早さから、納期をより短くしたいという経営者の考えは分かるが、とは言っても無理は禁物である。やはり、その中で様々な構造の問題を抱えたままの出荷となり、今後のメンテナンスでそれらを改善するしかない。

さて、今回のプロジェクト計画における、意思決定プロセスがいかにもインパール作戦の牟田口司令官の意思決定と類似していたことが、非常に関心深かった。様々な参謀が「司令官が言ったことだし。しょうがない」という空気を読んで、作戦を下していくという雰囲気も、似ているに違いない。そして、そんな無茶な目標に対して、帰納的計画を設定し、そして兵隊をデスマーチに送り込む。

誰が牟田口司令官を止めることができる？

それは、彼の直近の部下が死ぬ気になって止めること。

帰納的計画ではなく演繹的計画のもとに、精神論ではなく論理的な考えのもとに、机上ではなく現場主義で。そんな覚悟のある人が、牟田口司令官を止めることができるのでしょう。

課題の先送りについて

課題に対峙する姿勢が人それぞれに異なる。その中で重要なことは、決断できないは課題として再度「先送り」し、解決できる課題を先に実現することが重要となる。

プログラムの設計作業を行う中で、様々なパターンを仕様書に落とし込んで、「このケースの場合には解決できません、なのでこの設計では進めません」と作業を止めてしまい、ただひたすらにその課題に対して「あーでもない、こーでもない」と一人考え込むプログラマによく出会う。

私はそういった状況におちいった人に対しては、課題を最小化するよう、要件を大幅に減らすことにしている。最小限の課題に絞り込まれた場合、プログラマは安心して開発を進めることになり、通常のパフォーマンスを取り戻すことになる。

「先送りした課題が残ったままではないか？」と思われるかもしれないが、他のメンバーを含めて検討したり、システム全体を見回して課題解決の方法を探った方が、よりシンプルで簡単な解決方法を見つけられるものである。

上記で重要な点は、最小化された課題解決が「必ず解決すべき課題」であることを、プログラマに対して信じ込ませることである。粘り強くプログラマとコミュニケーションをとり、お互いの信頼関係を強くすることにより、初めて各個人のパフォーマンスが最大化されると考えます。