C#でデザインパターン　ネタ作り中 - SE（たぶん）の雑感記

前の記事で、「EDINET見る」とか言っていましたが、それより
「デザインパターンの復習したかったんだよなー」という思いが強かったので、急に方針転換しました。
勝手ながら、言語はC#です。

構想

手順として、

GoFの各パターンの整理
ここでは、パターン説明だけでなく、新規作成やリファクタリングについても言及する
サンプルソースの作成
各パターン間の関連
新たな情報との関連付け（書籍等紹介しながら）

といった感じで考えていました。
情報源は、とりあえずWikipediaだけでいいや、と考えていましたが…

元ネタ：デザインパターン (ソフトウェア) - Wikipedia

ぶち当たった問題点

陳腐化

GoFのデザインパターンだけ考えていると、

これ古いだろ…

というものや、

例示が意味分からん…
（例が陳腐化した、と考えてもらえると）
というものがありました。
Wikipediaには、「サンプルコードは、実装例に過ぎない。」と書いてあるものの…あまりにも。

利用例を示そうとすると、「そもそも使わない」という、本末転倒な結論に至ってしまったり…

サンプルの作成

そもそも、デザインパターンは、特定の問題を解決するために、良いと考えられているパターンのことです。

しかし、単独でパターンを適用する、ということはあまりありません。
普通は、複数を組み合わせます。

そうなると、単独のパターンで記述したソースは役に立ちません。
実際、Abstract Factoryパターンのソースを書きましたが…意図が伝わらないだろうと、悲しくなりました。

例えば、こんな感じになりました。

using Practice.Patterns.AbstractFactory.Parts;

namespace Practice.Patterns.AbstractFactory {
    /// <summary>
    /// 車の各部品の生成機能を返します。
    /// </summary>
    public interface ICarFactory {

        /// <summary>
        /// 車体を作成します。
        /// </summary>
        /// <returns></returns>
        CarBody CreateBody();

        /// <summary>
        /// エンジンを作成します。
        /// </summary>
        /// <returns></returns>
        CarEngine CreateEngine();

        /// <summary>
        /// タイヤを作成します。
        /// </summary>
        /// <returns></returns>
        CarTire CreateTire();
    }
}

これで、「実装したファクトリによって、返す部品とかが違うんだよ！」と書いても…
→「誰が組み立てるんだよ！」という疑問（Abstract Factoryにその責務は追わせないほうが良い）
→それをやるのが、Builderだとすっきりする
→要求されて部品作らんだろう
→じゃあ、返すのは部品じゃなくてRepositoryじゃね？（部品なかったら、発注か作成指図）
→それ、GoFのデザインパターンに入ってない…

という具合に、作ってもしょうがない状態に陥りました。

継承は良くない、という考え

あまり様々なプログラミング言語に精通していませんが、オブジェクト指向言語においては、

ソース共有を目的とした継承は極力避けるべき

という風潮があると思います。
私もそれには賛成です。
ただ、デザインパターンの多くの例は、継承に触れており、それをインターフェイスに置き換えると、

「それって元のやつと違うじゃん！」

と考えられても仕方ないと思いました。

展望

利用例すら思い浮かばないものは、説明だけ行う、というのもありかと思います。
そして、単独パターンにこだわらず、複数のパターンを適用したソースを公開すべきでは、と今は考えています。

あと、継承はやはり避ける方向でいきます。
C#なら、インターフェイスはとても使いやすいので、問題ないかな…と考えています。
（前職でDelphiやってたけど、いろいろ絶望した記憶がある）

下のようなメモ書きながらネタ作りしています。
まとまったら公開したい…！

f:id:hiroronn:20170228214315p:plain