C# 子类实例化基类 基类使用不了子类的方法_老话题：6个方法，检验你有没有正确使用设计模式...

方法一：设计模式是为了消除继承

大部分设计模式，是让你在在面向对象的基础上尽量消除继承的手段。所以，如果你用了一些设计模式，减少了继承，那你八成用对了。如果你用了一大堆设计模式，然而继承却越来越频繁，那你100%用错了。

之所以说大部分，是因为个别设计模式（比如享元模式）是为了解决特殊场景特殊问题而生的。

方法二：良好的设计应该利于测试

一个设计合理的系统，因为解耦充分，各个模块独立性强，所以单元测试应该是比较容易写的。如果你用了一大堆设计模式，却发现给你写的类编写单元测试用例非常困难，那你一定是用错了。

方法三：多态是更好的if

多态的本质是运行期动态决定程序的分支走向，也就是“更好的if”，而设计模式，至少是《设计模式》那本书中提到的那些模式，基本上是基于多态的。所以如果你合理的利用设计模式，你设计出的代码应该有较少的if，如果你的代码越使用设计模式if越多，或者更直观地说，缩进越多，你一定犯了错误。

方法四：看不懂的模式先不要用

有些模式是很容易用错的，比如visitor模式，其实是为了解决java不支持double dispatch而存在的，然而其逻辑很晦涩。所以当你还在怀疑自己是否用对了设计模式的时候，你不应该使用这样的模式。

方法五：大部分类继承都是错误

类继承总的来说只有1.5种正确的打开方式：

• 第一种叫做模板方法（template method），是设计模式之一。这种模式说的是基类在一个抽象的层面实现了公有方法a，a依赖私有方法b，而b的实现是子类的工作。这种模式下，子类实现的虚方法b是不应该被外界调用的。当然有一种极端情况，b即使a本身（比如react中的render），此时模板方法蜕化为普通的多态。

• 第二种叫做mixin，类a通过继承一个基类b，获得某种相对独立的能力。然而这其实是一种不太好的设计，尤其是在需要mixin多种能力的时候，更合理的方式其实是在a内部创建b的实例。只是在比较简单的场景中，我们可以用继承糊弄一下，所以只能算0.5种。

除此之外，使用类继承基本上可以认为是错误的设计。

由此我们可以推论，在es6流行导致运行时mixin写法在前端不流行之后，前端代码中出现了一些新的设计错误。

方法六：不要模仿java的写法

设计模式是一回事，设计模式的实现是另一回事，这一点很重要。比如著名的观察者模式（observer），在java中有大量应用。然而我们常见的观察者模式样板代码之所以长那个样，是因为java中缺乏事件订阅系统。在c++/c#以及js中实现观察者模式，就没必要那样写。因为c++有std:function，c#有委托，而js函数干脆就是对象。