記事のディレクトリ
インターフェースは何ですか？
インターフェースの性質：追従し、発信者とプロバイダ機能共通の機能との間の契約（契約）
なぜインターフェースを使うのか？
場所を交換することができる場合、コードでは、インターフェースが存在しなければなりません。インタフェースは、疎結合ために生まれていますプロバイダ疎結合最大の利点は、機能が代替になることを許可することですが
実施例1：整数の集合を加算、平均化操作
（このグループはまた、ArrayListの中に配置され、整数配列の整数であってもよい）
インタフェースを使用せずに（1）：別々整数の書き込み群の二つのタイプを加算する必要性、静的メソッドの平均は、全書き込みを求めます4方法
インタフェースを用いて（2）：intとして[]、ArrayListには、[本] IEnumerableインターフェイスを達成している限り、発信者の関数として、反復機能しなければならないかもしれない-合計、平均化法をパラメータの型のIEnumerableをタイプは、機能的アプローチの重複を書き込む必要はありません
例2：車のエンジンのニーズを開始します
換言すれば、自動車のエンジンに依存して、それらの間の密結合関係を形成し
ても、その後、密結合関係を形成するために、自動車、エンジン、しかし_rpmフィールドエンジンクラス場合に誤って0として書き込む：（1）インタフェースを使用しませんスピードプロパティカーインスタンスが0である、または状態を出力します「CARが実行されている...」
（2）の疎結合を目的としたインターフェースを使用して（それが良いとは思えない書かれました）
例3：携帯電話はどのように行う壊れています
寄与者の特徴：携帯電話のさまざまな;呼び出し元の機能：携帯電話ユーザー
（1）インタフェースを使用していない、携帯電話ユーザーが一つだけの電話を使用することができます
（2）インタフェースを使用して：古いものと新しいものではないが来ていない - 全体の最新の主を、神はなります！
再び：インタフェースが緩く生まれ結合することで、それは密結合、ハイリスクに起因するかけがえのない機能の提供、高コストを解決します
依存関係逆転の原則
High level modules should not depend upon low level modules,Both should depend upon abstractions.Abstractions should not depend upon details.Details should depend upon abstracts.
高层模块不应该依赖低层模块，两者都应该依赖抽象；抽象不应该依赖细节，细节应该依赖抽象
依赖反转原则——面向接口编程，解耦在代码中的表现，其实就是依赖反转
例4：全能的司机
（1）司机依赖于车：每个司机只能开一种车
（2）开始大乱斗：多个功能的提供者与多个功能的调用者都遵循同一个接口
（3）再加一个无人驾驶系统还不是小菜一碟？
- 依赖反转原则，其实就是给我们提供了一种新的思维方式，用来【平衡】【自顶向下，逐步求精】这种单一的思维方式
- 自顶向下，逐步求精：将大问题分解为小问题，小问题逐一解决后 ，大问题也就迎刃而解了；那么，解决问题的编程实体，就是函数，从而各个函数之间形成了【依赖关系】
- 有了面向对象之后，函数都是封装在类和对象中的，所以依赖关系存在于类与类，对象与对象之间
- 适当地引用接口，运用【依赖反转原则】，可以有效地减少耦合度，使代码更"清爽"，更好维护
单元测试
单元测试其实就是依赖反转在开发当中的直接应用和直接受益者
什么是单元测试？
单元测试是用来对一个模块、一个函数或者一个类来进行正确性检验的测试工作。
比如对函数abs()，我们可以编写出以下几个测试用例：
- 输入正数，比如1、1.2、0.99，期待返回值与输入相同；
- 输入负数，比如-1、-1.2、-0.99，期待返回值与输入相反；
- 输入0，期待返回0；
- 输入非数值类型，比如None、[]、{}，期待抛出TypeError。
把上面的测试用例放到一个测试模块里，就是一个完整的单元测试。
如果单元测试通过，说明我们测试的这个函数能够正常工作。如果单元测试不通过，要么函数有bug，要么测试条件输入不正确，总之，需要修复使单元测试能够通过。
-
单元测试通过后有什么意义呢？如果我们对abs()函数代码做了修改，只需要再跑一遍单元测试，如果通过，说明我们的修改不会对abs()函数原有的行为造成影响，如果测试不通过，说明我们的修改与原有行为不一致，要么修改代码，要么修改测试。
-
这种以测试为驱动的开发模式最大的好处就是确保一个程序模块的行为符合我们设计的测试用例。在将来修改的时候，可以极大程度地保证该模块行为仍然是正确的。
例5：不准乱碰电源
（1）风扇的运转是依赖于电源的
（2）引入进口，进行解耦
接口的产生：自底向上（重构），自顶向下（设计）
自顶向下的情况一般是非常了解业务逻辑，一上来就知道该怎样设计代码，设计接口；但更多的情况是不断地重构代码，发现需要解耦，才返回来声明一个接口，如此下去
（3）进行标准的单元测试
<1>打开 Test Explorer ，测试case和结果都会显示在其中
（Test ——Window）
<2>选择测试框架并命名
（右键 Solution ——Add ——new project ——Test），一般测试项目的命名都是被测试项目后加 “.Tests”
- 每一个类就是一组 Test case 【TestClass】
- 每一个 Test case 就是一个方法 【TestMethod】
<3>在【InterfaceExample.cs】中引用被测试项目
<4>書き込みテストケース
<5>と、他のテストは、現在の状況を書き込み
電圧が200V、ではないと警告が、直接爆発超えたとき、電動ファンの製造における問題を想定
テスト：
<6>スタートデバッグ
集合問題のテストケースでは、ブレークポイント、右失敗したテストは、デバッグを開始し、あなたが任意の場所で問題を見つけるだろう。「！爆発する」に変更し、テストすることにより「警告！」
注：テストコードも仕事で非常に重要であり、テストコードを無視しないでください
サプリメント
実施例5では、最初の時間は、私はそのような問題があったことを、コードを書いた
ので：C＃の初期化変数の優先順位のコンストラクタ
コンパイラは、初期化の変数Iを保証することはできませんので、期待値を得ることができます
