「アプリケーションアーキテクチャ設計パターン」を読んだ

オブジェクト指向で組んだらレビューで弾かれた

業務で実装をオブジェクト指向でおこなった。
(そもそも、自分がオブジェクト指向をマスターできているかは置いておいて)

レビューにて、
「この単純な機能の実装にこのコードは複雑すぎやろ」

たしかに、classが結構たくさん出来てしまったが、自分的にはそれぞれ存在させる理由があり、どれも必要に思えていた。

示された修正方針の一つに「データの入れ物として使うだけのclassの定義」があり、
オブジェクト指向で学んできた僕としては「??」となった。

なぜなら僕の中では、オブジェクト指向ではclassとはデータと処理が定義されているものなので、
データだけのclassなど存在する理由がなかった。

エンジニアはみなオブジェクト指向でコードを組んでいるのではないのか??

オブジェクト指向以外の書き方は悪だとwebに教えてもらっていたので、勉強していなかった

上記のように思っていたのは、主にwebでプログラミングを勉強していると
「オブジェクト指向で書くべき」
「手続き型は良くない。古い書き方でデメリットが多い」
という印象を持つので、
今はみんなオブジェクト指向でプログラムを書いているのだと思っていた。

いまさら手続き型など勉強する必要もないと思っていた。

しかし、今回求められているのは明らかにオブジェクト指向ではないので、
それしか知らない僕はどうやってコードを書けばいいのか解らなくなってしまった。

で、「アプリケーションアーキテクチャ設計パターン」を読んだ。

オブジェクト指向以外にも設計パターンはあり、それぞれメリットもあるということがわかった

Transaction Scriptというパターンがあることを知った。
手続き型に近い感じでコーディングしていくパターンで、
メリットとしては、シンプルで解りやすいコードになる。
デメリットとしては、機能が込み入ってくるとコードの重複など、今までも言われている問題が溢れてくる。
というような内容だった。

おそらく今回求められていたのはTransacrion Script型のコーディングだった。

今回の場合はオブジェクト指向はふさわしくなかった

既存のプロダクトへの機能追加で書いたコードだったが、
結果的にオブジェクト指向で書くのはふさわしくなかった。

理由としては以下。

・既存のコードもTransaction Script型でかかれていた。

急にオブジェクト指向でコードを書かれても、再利用出来るものもないし、今回書いたclassもおそらく今後も使われないであろう。(今後追加される機能もTransaction Scriptで書かれるため)

 

・他の開発者のスキルがそれほど高くないため

オブジェクト指向は理解するのにある程度のスキルレベルが必要なので、
他の開発者のスキルが低い場合に、理解できないコードとなってしまう。

既存の流れに沿わないことは、よっぽどのメリットがなければ導入する理由にならない。

設計パターンをいくつか理解しておき、ケースバイケースで組めるようにならないといけないと感じた。

コメントを残す

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