彼らは矛盾していますか?
デカップリングは素晴らしいものであり、達成するのは非常に困難です。ただし、ほとんどのアプリケーションでは実際には必要ないため、高度に結合されたアプリケーションを設計でき、「コンポーネントを分離できない」、「単体テストは苦痛」などの明らかな副作用以外はほとんど変わりません。 arse」など。
どう思いますか?常に分離してオーバーヘッドに対処しようとしていますか?
彼らは矛盾していますか?
デカップリングは素晴らしいものであり、達成するのは非常に困難です。ただし、ほとんどのアプリケーションでは実際には必要ないため、高度に結合されたアプリケーションを設計でき、「コンポーネントを分離できない」、「単体テストは苦痛」などの明らかな副作用以外はほとんど変わりません。 arse」など。
どう思いますか?常に分離してオーバーヘッドに対処しようとしていますか?
デカップリングと YAGNI は非常に補完的な美徳のように思えます。(Rob の回答に気づきました。ここで同じページにいるようです。) 問題は、どの程度デカップリングを行うべきかということであり、YAGNI は回答を決定するのに役立つ良い原則です。(単体テストについて話す人のために-単体テストを行うために分離する必要がある場合、YAGNIは明らかに適用されません。)
私は、「常に」デカップリングを行うと言う人々を心から疑っています。たぶん、彼らはそれを考えるたびにいつもそうしています。しかし、抽象化の追加レイヤーをどこかに追加できないプログラムを見たことがありません。そのようなプログラムの自明ではない例が存在することを心から疑っています。誰もがどこかで一線を画します。
私の経験からすると、コードを結合したままにし、後で戻って変更しなければならなかったのと同じくらい頻繁に、コードを分離して追加の柔軟性を利用することはありませんでした。それが私がバランスが取れていることを意味するのか、それとも両方の方向に均等に壊れているのかはわかりません.
YAGNI は経験則です (宗教ではありません)。デカップリングは多かれ少なかれテクニックです (宗教でもありません)。したがって、それらは実際には関連していませんし、互いに矛盾していません.
YAGNI はプラグマティズムに関するものです。あなたがするまで、何かを必要としないと仮定してください。
通常、YAGNI を使用するとデカップリングになると想定されます。そのナイフをまったく適用しないと、それが真であることを実証する前に、クラスが互いの動作をすべて知っている必要があると想定することになります。
「切り離す」(または「疎結合」)は動詞なので、工夫が必要です。YAGNI は推定であり、それが正しくないことがわかったときに調整します。
私は(ほとんど)常に切り離します。私がこれをするたびに、私はそれが役に立つと思いました、そして(ほとんど)私がしなかったときはいつも後でそれをしなければなりませんでした。また、バグの数を減らす良い方法だと思いました。
デカップリングのためのデカップリングは悪い場合があります。ただし、テスト可能なコンポーネントを構築することは非常に重要です。
話の難しい部分は、いつ、どれだけのデカップリングが必要かを知ることです。
私は彼らがそうしないと言うでしょう。デカップリングとは、コード内の不要な依存関係を減らし、クリーンで明確に定義されたインターフェイスを介してアクセスを強化することです。「あなたはそれを必要としない」というのは、明白で現在のユースケースがないソリューションの過度の拡張性と過度に広いアーキテクチャに対して一般的にアドバイスする有用な原則です。
これらの実際的な結果は、アプリケーション全体に不注意に波及効果を引き起こすことなく、個々のコンポーネントのリファクタリングと保守がはるかに簡単であり、設計に不必要に複雑な側面がないシステムがあることです-それは必要なだけ単純です現在の要件を満たすため。
「単体テストが面倒」なら、必要だと思います。ほとんどの場合、デカップリングもほぼゼロのコストで実現できます。
さらに、新しいコードベースで作業するときの私の最大のバグベアの 1 つは、どこかにインターフェイスを導入したり、依存性注入を使用したりすることで多くの時間を節約できる場合に、ユニット テストを書き始める前にコードを切り離さなければならないことです。
ええと、YAGNIは人々が投げかける偽の単純なフレーズに過ぎません。ただし、デカップリングはかなりよく理解されている概念です。YAGNIは、ある種の超能力者であることを暗示しているようです。それは決まり文句によるプログラミングであり、決して良い考えではありません。正直なところ、YAGNIはおそらくデカップリングとはまったく関係がないという場合があります。結合は通常「より迅速」であり、「分離されたソリューションが必要かどうかは誰にもわかりません。とにかくXコンポーネントを変更することはありません!」
あなたのタグが言うように、それは非常に主観的です。あなたが「必要としない」ものを決定することは、あなた自身の工学的知恵に完全に依存しています。ある場合には結合が必要かもしれませんが、別の場合には必要ありません。誰に言うの?もちろん、あなた。
したがって、非常に主観的な決定の場合、規定するガイドラインはありません。
YAGNI 混乱 :) ... 実際、「高速化」するためにすべてのコードを混在させる必要はありません。
単体テストは、結合されたときの感覚に本当に役立ちます (単体テストと他の種類のテストが何であるかをよく理解している場合)。代わりに、「コンポーネントを分離できない」という考え方でそれを行うと、必要のないものを簡単に追加できます:)
YAGNI は、現在の実装が要求する実際の使用シナリオを超えて、ロジックをひねり、変更し始めるときに出てくると言えます。外部サイトへのリダイレクトを扱ういくつかの外部決済プロバイダーを使用するコードがあるとします。すべてをきれいに保つ設計をすることは問題ありませんが、サポートされるかどうかわからないプロバイダーについて考え始めるのは問題ないと思います。ワークフロー。