「オブジェクト指向すぎる」

私は強力なオブジェクト指向のバックグラウンドから来ており、コードはJavaで書かれていますが、以前よりも優れたオブジェクト指向設計にあまり重点を置いていない組織で働き始めました。私は「あまりにも多くの抽象化」を導入し、代わりに常に行われている方法をコーディングする必要があると言われました。これはJavaの手続き型です。

TDDもここではあまり実践されていませんが、テスト可能なコードが必要です。大きな「神クラス」の静的プライベートメソッドにビジネスロジックを埋め込むことは（このチームの標準と思われます）、あまりテストできません。

私は自分の動機を同僚に明確に伝えることに苦労しています。OOとTDDを使用するとコードのメンテナンスが容易になることを同僚に納得させる方法について、誰かアドバイスがありますか？

技術的負債に関するこの質問は私の質問に関連しています。ただし、他の問題がカバーする事実の後に返済するのではなく、そもそも借金の発生を回避しようとしています。

あなたはそれが維持できないことについて不平を言ったのではなく、あなたの好みだけではありません。それが意図的なスタイルの選択である場合、それは単に調和の取れない創造的な違いのケースである可能性があり、あなたはあなたのスタイルに合うように調整するか、あなたの好みのスタイルに合う場所を見つける必要があります。

人々は、モジュール化された、効率的で、抽象化された、比較的バグのないコードをいつでも手続き型で記述できます。Javaはそのような店にとって奇妙な言語選択ですが、たとえばAndroid向けに開発する必要があるなど、外部要因が言語を決定した場合、Javaが発生することがわかります。

誰もが天才です。しかし、木に登る能力によって魚を判断する場合、それは愚かであると信じて一生生きます。- アルバート・アインシュタイン

意図的な選択だった場合、オブジェクト指向の優れた設計原則をどれだけ順守しているかを実際に判断することはできません。手続き型の優れた設計原則をどれだけ順守しているかを判断し、それに応じてリファクタリングする必要があります。Javaでは、クラスの外部でコードを記述することはできません。したがって、単に存在するからといって、モジュールがオブジェクト指向であることを意図しているわけではありません。

一方、コードがいずれかのパラダイムで混乱している場合は、おそらく損失を削減する必要があります。

あなたの質問を読んで、私は本Pragmatic Programmerの1つのヒントを思い出しました。

そのヒントの1つはBe a Catalyst for Change次のとおりです。

何をする必要があり、どのようにそれを行うかを正確に知っている状況にあるかもしれません。システム全体が目の前に表示されます。正しいことはわかっています。しかし、すべてに取り組む許可を求めてください。そうすれば、遅れと空っぽの視線に出会うでしょう。人々は委員会を形成し、予算は承認を必要とし、事態は複雑になります。誰もが自分のリソースを守ります。これは「スタートアップ疲労」と呼ばれることもあります。

石のスープを作る時間です。合理的に求めることができるものを考え出す。よく開発してください。一旦それを手に入れたら、人々に見せて、彼らを驚かせましょう。次に、「もちろん、追加した方が良いでしょう…」と言います。重要ではないふりをする。座って、最初に必要な機能を追加するように求められるのを待ちます。人々は、継続的な成功に参加する方が簡単だと感じています。彼らに未来を垣間見ると、あなたは彼らに集まってもらうでしょう。

したがって、OOとTDDの知識を使って良い仕事を始めたら、すぐに彼らはあなたの仕事を見て尋ねるようになるでしょう。

新しい働き方を売り込むには、明らかなメリットを示す必要があります。明確な利点はないがあいまいな「抽象化の層」をさらに書くと、「将来にとって有益になる可能性があります」が機能しません。

ファクトリーが複数のタイプのオブジェクトを作成するファクトリーを作成します。すぐに利点を示す依存性注入を使用します。実際に複数のクラスによって実装されるインターフェイスを作成します。

「本当のオブジェクト指向」でよく見かけるのは、高度な技術を使用して、非常に単純な問題を過度に複雑な方法で解決することです。

同じオブジェクトを作成するだけの場合、ファクトリーの利点をどのように示すことができますか？コード内で高度な技術の恩恵を受け、そこからポイントと作業を示す問題を見つけます。

戦争は一度に1戦闘で勝利します。

ほんの少しのコードを引き受けて、TDDとより良いOOプラクティスを実装して利点を実現することによってのみ、それらを納得させることができます。素敵なポストカードを見せてくれるだけでなく、約束の土地に連れて行ってくれました。

確かに、今日の多くのコードベースで過剰な抽象化が使用されている場合があると思います。必要なものだけを入れてください。それには抽象化も含まれます。