.NetCore框架详解 -------一、 原因、解决方案和历史

• 原因、解决方案和历史

在程序的开发的实践中，许多具有不同功能和特性类的定义组合而成为了程序。为了增加程序的粘性，达到程序正常、顺利、流畅的执行，就必须需要这些类之间相互协作才能达到上述效果。类之间实现相互协作的常规和不需要任何思考的手段即是使用“new”关键字来对类进行实例化操作（“new”关键字实例化操作，不会因为出现了依赖注入等方式、手段，从而改变它的常规和通用性，只是在一定程度上减少了“new”关键字实例化类的频率），因此整个程序中以极高的频率存在着通过 “new”关键字实例化的各种各样的类对象。如果一个类的定义发生了改变，其它需要使用该类实例才能完成操作的类，会产生语法或逻辑错误，导致整个程序的崩溃。使用“new”关键字通过调用并执行类定义本身直接实例化类，是导致类之间因为相互协作的原因，从而产生相互锁死的关系，如果产生改变，则关系链断裂，整个程序的崩溃是关系链断裂的必然结果(整个事件的起始、发展、结束和后果专家给了一个词：耦合)。

怎样保证类之间的相互协作，减少之间的相互锁死，在三层架构盛行的年代大牛们给出了两个当时比较出名的两个解决方案“工厂模式”（另一个我记了有了解的在评论区通知我，实际上在当时我比较看好这个）。在以后的发展过程中两者由于思想不熟、执行效率等问题两个解决方案都没成为程序开发中的主流解决方案。“工厂模式”是通过接口和程序集（反射）两者相互结合从而达到类之间的相互协作，减少之间的相互锁死的目标，即实例化操作只需要调用相应接口的相应方法，至于怎样实现具体功能和特性定义在继承该接口的类中。即类之间的相互协作不再把关注点和目标放在类本身上，而是把关注点和目标放在相应接口中是否声明有相应方法，至于具体实现是定义在类A或类B甚至C或D中都没关系，即类之间的相互协作不依赖于其它的类而是依赖于相应的接口。有的开发者提出个一种极端的可能：类所依赖的接口发生改变，且这些改变恰好以被该类所使用，不是以会造成程序的崩溃吗？的确存在这种可能，但是最好的实践是根据需求在接口中声明一个新的方法，并重新定义一个继承该接口的一个新的类来实现该方法，而不是对原有类或类中的方法修修补补，就能有效的避免上述极端情况。

虽然“工厂模式”没有成为主流解决方案，但是要随着软硬件技术的发展，特别是硬件性能的提升和SUN对反射技术的改化良优化，类实例化效率的差距(相比于“new”关键字)由原来的10几倍缩小到现在的一倍以上，由于上述因素由于加上开发思想先进、各种条件相继成熟，所以从“工厂模式”升级而来的依赖（Dependency）、依赖倒置原则（DIP - Dependence Inversion Principle）、控制反转（IoC -Invertion of Control）、依赖注入（DI- Dependency Injection）、IoC容器等开发思想、原则、技术实现和手段经过不断的自我进化成为了当今程序开发的主流，如SUN的Spring.NET和微软的.NetCore等都通过自己的开发环境和框架实现了上述的开发思想、原则、技术实现和手段。所以只有知道了上述这些等开发思想、原则、技术实现和手段来自“工厂模式”，才能够理解这些东西不是从石头里蹦出来的，反射技术为什么在Spring.NET和.NetCore中会成为程序开发的常规思考方法、常用技术和手段，甚至这些开发环境和框架强制要求遵循，由这些技术和手段所提供的格式和规范才能开发出能够被正常执行的程序。许多开发者对于阅读大段的文字十分感，而阅读大段的代码则会比较有耐心，如果需要和有可能也会自己去亲自实践这些代码。因为这些文字是那么的像软件工程中的教条、对自己技术能的提升也不如代码那样简单而有效，但是相要把网络上碎片化的知识整合为一个来历明确、逻辑清晰、系统性知识，大段文字的写能有足够的时间对这些碎片化的知识时行梳理和思考，成为自己能够理解的知识体系。(如果想要加深对工厂模式的理解参见示例程序：21-04-03_FactoryPattern(001_在工厂模式下以通过接口结合列表、泛型和反射等方式实现指定类型的实例化操作_控制台) https://download.csdn.net/download/zhoujian_911/16621596)