c# - SOLIDの原則とコンパイル？

Question

たとえば、Single Responsibility原則に関して：

Radioクラスについて話しましょう：

Radioクラスには、ボリュームとステーションの管理という2つの責任があると主張する人もいるかもしれません。これらの操作は、それを使用するクライアントの完全に異なる領域から呼び出されます。

したがって、これがあります：

大丈夫だ。

しかし、私はいつもこのような文章を見ます：

したがって、変更が必要になったときに、壊れたコンポーネントに依存するすべてのコードを再コンパイルする必要さえありません。

ちょっと待って ！

クラスを変更する必要がある場合-再コンパイルする必要はありVolumeManager ません。 ただし、アプリケーションが新しいDLLを使用するには、iisを（Webで）停止する必要があります。これにより、アプリケーションがダウンします。RadioStationManager

また、ではconsole、プロセスによってロックされているため、dllを変更するためにプログラム全体を終了する必要があります（アプリの実行中にdllを変更することはできません-ファイルはロックされています）

GACを使用する場合でも、dllを変更するには、プログラムを停止する必要があります。

それで、それは私を何を救うのですか？コンパイルはただ-右クリックしてビルドします。それで全部です

「壊れたクラスだけをコンパイルする必要があります。 」と言及することの利点はわかりません。

私は何が欠けていますか？

http://www.gontu.org/solid-single-responsibility-principle/build 「 」という単語を探します

http://epic.tesio.it/doc/manual/solid_principles.htmlrecompiled 「 」という単語を探します

http://www.dananhudson.com/?tag=solidrecompile単語「 」を探す

Answer 1

コンパイル時間を忘れて、アプリケーションの再起動を忘れてください。

SOLIDは、クリーンなコードと保守性に関するものです。それは実行時のことではなく、コードが時間の経過とともにより複雑になり、保守が困難になることであり、それが実際のコストです。

Answer 2

変更の範囲が制限されていることを示すことができる場合、たとえば1つのDLLのみを更新する必要がある場合など、既存のアプリケーションに更新を展開する方が「政治的に」簡単な場合があります。（これは、すべてのクラスが独自のDLLに含まれている必要があるという意味ではないことに注意してください。ただし、ほとんどの場合、すべてのクラスが同じDLLに含まれているわけではありません）

ただし、他の利点はより概念的なものです。DLLを再コンパイルする必要がない場合は、DLLに何も壊れていないことが確実にわかります。触れる必要のあるコードが少なければ少ないほど、バグを導入する可能性は低くなります。

Answer 3

コンパイル時間は、C ++と比較してC＃では問題になりません。大規模なC++プロジェクトは、コンパイルに時間がかかる場合があります。ある領域で変更を加えようとすると、無関係なコンポーネントが再コンパイルされるため、非常にイライラします。単一責任は、コンパイルの問題を改善する方法で、よりコンパクトな依存関係に向けてガイドします。

Answer 4

SOLIDの原則に関するボブおじさんのクリーンなコーダービデオを強くお勧めします。

独立した展開可能性の背後にある主な考え方は、独立して展開できるモジュールも独立して開発できるということです。通常、モジュールを独立して展開することはありませんが、モジュールを独立して開発できることでメリットが得られます。

コンパイルプロセスへの影響に関連して、これはおそらくC ++に関連しており、コードが変更に依存するときに各コンパイルユニット（cppファイル）を再コンパイルする必要があり、慎重に作成された依存関係グラフでは、変更が1つのコンパイルユニットにのみ影響します、コンパイル時間に深刻な影響を与える可能性があります。とにかく、古いハードウェアで作業しているのでない限り、コンパイル時間を優先するべきではありません。

独立したモジュールが変更およびデプロイされたときにアプリ（Webまたはコンソール）を停止する必要があることについて-これは、プラグインフレームワークを使用することで回避できます。プラグインフレームワークは、新しい/変更されたアセンブリをアプリに動的にロードできます-SOLIDの原則をプラグインとそのインターフェースを構築する方法。これにより複雑さが増す可能性があることに注意してください。これを回避し、デプロイ時にアプリを再起動することをお勧めします。

Answer 5

保存されたコンパイルが重要だとは思いません。むしろ、それなしで逃げることができる理由です。

アプリの限られた領域に特定の変更が含まれているためです。これはそれ自体が良いことです。適切に設計されたシステムでは、動作を変更するためにアプリケーション全体を理解する必要はありません。それが重要だと思います。

dllがロックされているか、IISが影響を受けるApp-Poolを再起動するという事実（これは私が言うかもしれませんが）は、将来のシステムで軽減される可能性のある技術です。

実際、シャドウコピーとApp-Domain hokey-pokeyを使用すると、dllを交換するときに再起動する必要のないプログラムを作成できます。

Answer 6

デザインパターンで心に留めておくべき重要なことは柔軟性だと思います。さまざまなタイプのStationManagerとVolumeManagerを実装することにした場合は、Radioクラスのコードを変更する必要はありません。唯一の変更は、クラスRadioのインスタンス化によって課されます。このためには、アプリケーションを再起動する必要がありますが、複数のif-elseステートメントを含むスパゲッティコードはクラスにありません。コードは変更されません。新しいクラスに新しいコードを追加するだけです。これは、別の重要な設計原則にも準拠しています。オープン/クローズの原則（SOLIDのO）：コードは拡張のために開かれている必要がありますが、変更のために開かれている必要はありません。すべての優れた設計慣行に従っている場合でも、変更が行われるようにアプリを再起動する必要があります

Answer 7

実際、コンパイルとビルドプロセスに関連する議論は、.NETプラットフォームにとってそれほど重要ではありません。ただし、他のプラットフォームや言語にとっては非常に重要な場合があります。

たとえば、C ++の世界では、この利点により、コンパイル時の時間を節約できるため、開発チームによる生産性の劇的な向上につながる可能性があります。C ++の世界では、ブリッジパターンまたはPimplイディオムを使用すると、ヘッダーファイルを変更するたびに（プライベート部分でも）すべての依存関係（直接または間接）の再コンパイルが行われるため、時間を大幅に節約できます。この場合、SOLID原則のビルドまたはコンパイルの側面は非常に有益です。

簡単に言うと、SOLIDの原則は、ビルドプロセスや再コンパイルではなく、依存関係がすべてです。ただし、依存関係を適切に管理すると、これらの領域でも確実に利益を得ることができます（ビルドおよびコンパイルプロセスを含みますが、制限されます）。