2人のプログラマがパンを焼いた方法

私は長年プログラマーとして働いていましたが、その間、奇妙なことに、私は常に何かをプログラミングしてきました。 そして、私が気づいたなんて興味深いことです。1か月前に書いたコードで、私はいつも何かを少し修正したいと思っています。 6か月前のコードを大幅に変更したいのですが、2、3年前に書かれたコードは私をエモに変えます。私は泣いて死にたいです。 この記事では、2つのアプローチについて説明します。 最初のおかげで、プログラムのアーキテクチャは混乱を招き、メンテナンスは不当に高価になり、2番目はKISSの原則です。



したがって、2人のプログラマーがいると想像してください。 そのうちの1人は賢く、Habréに関する一連の記事を読み、 GoFカタログを心得て知っています。 もう1つはすべてをシンプルにします。 たとえば、最初の名前はBoris N.、2番目の名前はMarkus Pです。もちろん、名前は架空のものであり、実際の人々やプログラマーとの偶然はすべてランダムです。



そのため、プロジェクトマネージャーは両方に来て（ PMがあなたの宇宙のプログラマーのところに行かなければ、何か別の名前、たとえばBAやleadに電話しても、本質は変わらないでしょう）と言います：

-みんな、パンを作る必要があります。



まさにそのとおり、生産方法を指定せずに「完了」しました。



プログラマは何をしますか？







Borisは最初の抽象化であるProductクラスを作成し、そこからBreadクラスを継承し、クラスのファクトリメソッドProductFactory-createProduct（）をインスタンス化します。



マーカスもほぼ同じです。 ファクトリのcreateBread（）メソッドを使用して、BreadクラスとManagerクラスを作成します。



違いは最小限ですが。 プロジェクトマネージャーは、顧客のニーズについてもう少し深く理解しているようです（そう思われますが、そうです）。

-パンを作るだけでなく、オーブンで焼く必要があります。



そしてすぐに、パンが真空で焼かれているのではなく、オーブンで焼かれていると言うことは不可能でしたか？ さて、プログラマは何をしますか？







BorisはProductFactoryクラスの名前をOvenに変更し、抽象化-AbstractOvenを強調表示します。 完全に美しくするために、彼はcreateProduct（）メソッドの名前をbakeProduct（）に変更します。 したがって、ボリスは「抽象化の抽出」を使用して初めてリファクタリングを実行し、文献に記載されているとおりに「抽象ファクトリ」テンプレートも実装しました。 よくやった、ボリス。



しかし、マーカスは何もしません。 彼の観点からは、すべてがとても良いです。 まあ、おそらくcreateBread（）の実装をわずかに変更する価値があります。



月の満ち欠けが変わり、マネージャーが3度目のプログラマーのもとにやってくる。 彼は言い​​ます：

-さまざまな種類のストーブが必要です。



そうですね。







ボリスは喜んで手をこすり、AbstractOvenの3つの相続人、ElectricOven、MicrowaveOven、GasOvenを作成します。 そして、彼は不必要にオーブンクラスを削除します。



マーカスもプログラムに変更を加えています。 createBreadメソッドに整数パラメーターオーブンタイプを追加します。



4回目は、マネージャーがプログラマーのところに来ます。 彼はシリーズ「I Know the World」の本の1つを読んだばかりです。 新しい情報とPMBoKの干渉により、予期しない結果が生じました。 マネージャーは言います：

「ガスなしでは焼けないようにするにはガスストーブが必要です。」







ボリスは、ガスの供給源は1つしかないと考えています。 そして、そのような場合には、 私たちのお気に入りのテンプレートが常にあります 。 彼はGasSourceSingletonのみを作成し、接続性を減らすために、GasOvenのGasSourceインターフェイスを介して実装します。 やあ、彼はセッターを通して依存性注入を適用した！



本質的に控えめなマーカスは、Managerクラスに実際のプライベートgasLevelフィールドを作成します。 当然、createBreadメソッドのロジックをわずかに変更する必要がありますが、何ができるのでしょう！



しかし、数日後、マネージャーは5度目に来て、唇をなめます。

-オーブンでパイ（別々に-肉、別々に-キャベツ）、およびケーキを焼くことができるようにする必要があります。



プログラマーも食事をしたいので、仕事に取り掛かります。







ボリスはすでにそのようなことを感じ始めていますが、彼はもうやめられません。 ストーブは、調理に必要なものを正確にどのように知るのですか？ 明らかに、彼女はコックが必要です。 そしてボリスは、長くない（あるいは長くない）思考でクッククラスを作成します。 彼は、入力として抽象オーブンを使用する調理方法を使用します-クック（owen：AbstractOwen）：製品。 結局のところ、これは論理的です-料理人はオーブンを取り、その助けを借りて料理します。 その後、BorisはProductクラスのさらにいくつかの子孫-Cake and Pastyを作成し、PastyからMeatPastyとCabbagePastyを継承します。 そして、製品の種類ごとに、BreadCook、PastyCook、CakeCookという別個のクックを作成します。



まだ普通のように思えますが、createBreadメソッドに別の整数パラメーター、breadTypeを追加しただけのMarcusよりも時間がかかりました。



6回目は、マネージャーが来ます。 ところで、彼が今求めていることは顧客の要求ではなく、これは彼自身のイニシアチブです。 しかし、誰もそれを知りませんよね？

-さまざまなレシピに従って、パン、パイ、ケーキを焼く必要があります。







「うーん」と、ボリスは「ビルダー」テンプレート（もちろん「無料のインターフェイス」も含む ）を言い、思い出します 。 彼はRecipeクラスを作成し、ビルダーRecipeBuilderを作成します。 彼はsetRecipeセッター（レシピ：Recipe）を使用して、ストーブにレシピを（突然！）注入します。



そして、マーカス（信じられないでしょうが）createBreadに別の整数パラメーターを追加します-レシピ。



最も興味深いのは、いつものように、コンピューターから離れていることです。 つまり、開発の開始後初めてマネージャーが顧客と会い、最終的に彼がストーブを必要とした理由を理解します。 彼（マネージャー）は、プログラマーに7回目に来て、こう言います：

「レンガをオーブンで焼く必要があります。」







ボリスにとって、これはマネージャーとの最後のミーティングですが、それでも彼は力を尽くしてアーキテクチャを変更しています。 抽象クラスAbstractHeatingSmth-何かを加熱する抽象クラスを強調しています。 彼のために、彼はHeatingFactoryファクトリーを作成します。 AbstractHeatingSmthから、ProductOvenとFuranceを継承します。 後者には、ブリックオブジェクトをインスタンス化するファクトリmakeBrickメソッドがあります。 しかし、何も機能しません。 読者は、独自にアーキテクチャの誤りを見つけるように招待されています。



マーカスもそれほど滑らかではありません。 彼は3番目（！）の行クラスを作成する必要があります。 彼はそれをBrickと呼び、makeBrickメソッドを自分のマネージャーに追加します。



もちろん、MarcusはcreateBreadメソッド内でAdとIsraelを作成していると主張できますが、実際はそうです。 しかし、 テンプレートメソッドテンプレートを使用すると、混乱を構造化できます。 そして、豊富な工場と抽象化を理解するには、もう少し複雑です。



私がしたい結論は、おそらく少し予測可能です。



ボリスのアプローチは、システムのほぼすべての部分を分離してテストでカバーできるという点で優れています。 しかし、非常に多くのクラスを作成するには不当な時間が必要であり、要件が変更されるたびに、コードが連鎖的に変更されます。 顧客の希望を予期して、アーキテクチャを柔軟にする試みは通常失敗します。アーキテクチャは間違った場所で曲がります。 結局のところ、ご存じのとおり、「世界は想像以上に素晴らしいものではありません。

彼は私たちが想像できる以上に素晴らしいです。」 そして、次の変更要求を受け取ったプログラマーは、これを他に類を見ないほど確信しています。



もちろん、マーカスのアプローチはユニットテストの使用を許可しませんが、一方で、結果をはるかに高速に提供し、変化はより少ない血でもたらされます。 このアプローチは、すべてのストライプの新興企業が非常に必要とする非常に迅速なスタートです。 そして、奇妙なことに、そのようなコードは単純なので理解しやすいです。



そして、もしそうなら、すべてを新しく書き直すために-それは常に時間内になります。



^{ここから写真を撮りました}



UPD。 記事が非常に多くの応答を受け取ったことは非常に楽しいです。 ここでは、たとえば、Haskellでのこの問題の解決策がリストにあります。



UPD.2そして、これはC＃バージョンです。 他に誰？



UPD.3 マーカスと ヤグニの パン