KISS原則のためのデザインパターン

　デザインパターンは今までに至るまで作られてきたコーディングの際のパターンです。大体これは複数ファイルにまたがるつくりになっており、とてもとても複雑な問題をなるべくシンプルにされたパターンを知るだけで解決できるようにします。図は増補改訂版Java言語で学ぶデザインパターン入門 ｜ 結城 浩 ｜本 ｜ 通販 ｜ Amazonから引用したFacadeパターンのクラス図です。

　KISS原則はKeep is simple stupidの略で「単純な作りを保て」という意味です。短くて意味が明確だと読み解きやすいものです。原則というだけあり、デザインパターンもとてもとても複雑な問題に対してこの原則を実現するために作られていることが多いです。
　KISSの原則 – Wikipedia
　デザインパターンの実現よりも原則の実現を優先すべきです。語弊がある文なので補足ですがコーディングで最も優先すべきは要件の実現です。動くきれいなコード＞動く汚いコード＞動かないきれいなコード、です。
　Gitのソースコードでも業務範囲でもこの二つについてのアンチパターンに本末転倒なパターンが時折見られます。簡単な作りで済むのにデザインパターンを適用したばかりに読み解くのが面倒になります。例えば、Facadeパターンなら次のようなものです。

// 極端にやってしまったパターン
function client() {
    $fasade = new Fasade()
    $fasade->echoA();
    $fasade->echoB();
    $fasade->echoC();
    $fasade->echoD();
}

class Fasade {
    use EchoA, EchoB, EchoC, EchoD;
}

trait EchoA {
    function echoA() {
        echo 'a';
    }
}
trait EchoB {
    function echoB() {
        echo 'b';
    }
}
trait EchoC {
    function echoC() {
        echo 'c';
    }
}
trait EchoD {
    function echoD() {
        echo 'd';
    }
}
// これで十分だったパターン
function client() {
    echo 'a';
    echo 'b';
    echo 'c';
    echo 'd';
}

　無暗にクラスを分けたせいで複雑化しています。例は極端ですがアクティブレコードのみで十分なのに、コントローラ->コマンド->リポジトリ->モデル->SQL文発行、の様な段階が過度に多いものはままあります。簡単な問題を複雑にしていないか、本当にそこまで大がかりなものを用意する必要があるのか、都度考えてコーディングしたいものです。