デザインパターンはアンチパターンなのか

151213_popteamepic_01

Gakuです( ゚Д゚)

最近、Go言語でシステムを一本作成し、「家宝は寝て待て!」状態でしたので、時間を持て余しておりました。
そこであまりにも暇だったので、GoFのデザインパターン23手を組んでみました。
それがこれです。

Go言語が未熟なため、いろいろ試行錯誤が見えると思いますがあしからず。

さて、度々エンジニアの会話であがる「デザインパターンはアンチパターンであるか」問題ですが、少し考察してみたいと思います。

デザインパターンがアンチパターンであると主張する人の理由

1.最近の言語・フレームワークを使えば「デザインパターン」は必要がない

このように主張する人はいます。

確かにitaratorパターンなどはjavaであれば拡張for文、C#であればforeach文です。
itaratorパターンを理解せずとも、使用することが可能です。
また、FactoryMethodパターンでのDB接続なんかも(厳密にはFactoryMethodが使われているかは定かでないが、僕自身ならこのパターンを使用すると思うので)、フレームワーク上に組み込まれていれば「使用方法」を知っているだけで組むことができるはずです。

余程「大企業」でもない限り、各会社で「オレオレフレームワーク」を作成することはないと思われますし、業務を行う上ではこの主張は正しいと考えます。

2.わざわざ「デザインパターン」を勉強せずとも、普段の書き方で「デザインパターン」の何パターンかは実装している

このように主張する人はいます。

確かに、僕が今まで見てきた数少ない「業務システム」ですが、必ずと言って良いほどFacadeパターンが使われていました。
まぁ、オブジェクト指向を齧った人であれば自ずとFacadeパターンになると思うのですが、一応主張通り「デザインパターンを知らずともデザインパターンで実装している」という主張は正しいです。

業務を行う上ではこの主張は正しいと考えます。

3.デザインパターンで組んでいるコードは読めない人もいる

このように主張する人がいます。

確かに、デザインパターンと言わず、interfaceやabstractを使用し抽象度を上げるとコードを辿れなくなるため「いきなりコードが消失する」感覚に陥るはずです。
「システムはチームで開発するものです」「よって、プログラミング初心者でも読めるコードを心がけるべき」

業務を行う上ではこの主張は正しいと考えます。

反論

いや、まぁ、いいんだけどさ。

「それでいいの?」

って感じるわけですよ。
1の主張であれば「俺フレームワークなんて作らないし、今後も作る予定ないので。いいっす(*´Д`)」
そんな感じ。

2なんて典型的な「思考停止」している主張だし。
「Facadeパターン」しか使用してないってことは、それはデザインパターン23手の中の1手、つまり5%以下しか知らないわけだし。
良くそれで「デザインパターンの何パターンかは勉強せずとも書いている」と言えたものだなと。。。

極めつけは3ですよ。

「はい。3です!」

この主張する人は「デザインパターン」という言葉さえ知らない人が多いです。
読めないってwそれオブジェクト指向でさえ書いてねぇからw

おわりに

いろいろ書いてきましたが、確かに「デザインパターン」は古い技術であり、最近の関数型言語等々には合致しない点も多いかと思います。
ただ、今回Go言語で23手組んでみてGo言語での記述パターンの見通しが良くなったというか、気持ちよく書けるようになったのは事実です。

プログラミングにおいて
「書いてて気持ちいかどうか」
というのは非常に大切な要素だと思うので、結構鬼畜でしたが23手組んで良かったと思ってます。

デザインパターンをアンチ視する人もいることは事実です。
その際は「郷にいては郷に従え」精神でひっそり暮らします。

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です