ES2015(es6)
js文档Node.jsVue.jsReactjQueryES2015(es6)angularjscss3动画vbs最新电影flutter微信小程序C教程java教程C++教程C#教程php教程sql教程mysql教程android教程ios教程python教程正则表达式

Design Pattern: Not Just Mixin Pattern

发布时间：2019-08-14 发布网站：脚本宝典
脚本宝典收集整理的这篇文章主要介绍了Design Pattern: Not Just Mixin Pattern，脚本宝典觉得挺不错的，现在分享给大家，也给大家做个参考。

brief　　　　　　　　　　　　　　　　　　　　　　　　　　　　

从Mix-in模式到Mixin模式，中文常用翻译为“混入/织入模式”。单纯从名字上看不到多少端倪，而通过采用Mixin模式的jQuery.extend我们是否可以认为Mixin模式就是深拷贝的代名词呢？
本文试图从继承机制入手对Mixin模式进行剖析，若有纰漏请大家指正，谢谢。

The Fact of InherITance 　　　　　　　　　　　　　　　　　　

首先让我们一起探讨一下继承机制吧。作为OOP的三个重要特性（Inheritance,Polymorphism,and Encapsulation）之一，继承应该是和Encapsulation关系最紧密。
试想一下，现在我们得到需求分析后要对问题做概念模型设计，过程大概就是从具象化->抽象化->再具象化，而在抽象化时自然而然需要提取具象的共同点得到简单直接的识别模型（如：广东人啥都吃，外国教育就是好），而再具象化时则需要构建更为明确的含义更丰富的认知模型（广东人有的吃猫肉，有的不吃），但它始终是识别模型的具象，也就始终依赖识别模型。
认知模型 多对多 识别模型，如 广东人有的会做生意，有的喜欢打工(广东人有的吃猫肉，有的不吃) 对 广东人会做生意(广东人啥都吃)
PS：认知模型、识别模型均为本人老作出来，识别模型就如文章title，略看后大概知道文章方向；认知模型如文章的content，细看才了解文章的含义。

The Diamond PRoblem From Multiple Inheritance　　　　　　

从上文了解到认知模型可对应多个识别模型，那么自然而然就需要多继承了，而C++和Python均支持这一语言特性。
示例：

Design Pattern: Not Just Mixin Pattern


D类为B、C的派生类，A类有方法M，若C重写方法M，若现在通过D类的实例调用方法M，那么到底是调用A类中的方法实现，还是C类中的方法实现呢？这个就是著名的Diamond Problem。
本质上是，对象在同一时间拥有多条继承链，并且相同的成员签名出现在>1条继承链上，在无优先级或其他约束条件的情况下自然是找不到北的哦。
Cons：1. 随着项目规模发展，类间继承关系愈发复杂，继承链增多，容易发生Diamond Problem。

Single Inheritance Plus Multiple Interfaces　　　　　　　　

鉴于多继承引起的问题，Java和C#、Ruby、Scala等后来者均 采用单继承+多接口 的继承机制。
单继承，导致对象无法在同一时间拥有多条继承链，从而防止Diamond Problem的发生。
多接口，定义行为契约和状态（严格的接口仅含行为契约），不含具体的行为实现，表达like-a语义。
但问题又随之产生，在撸ASP.NET MVC时项目组一般都会在concreteController和Controller间加>=1层的BaseController，然后各种LOGger、Authentication、Authorization和Utils均塞到BaseController里面，然后美其名为基(鸡)类(肋)。这时你会发现BaseController中的成员（方法、字段）是无机集合，要靠#region...#endregion来划分功能区间，然后随着项目规模的扩大，各种狗死垃圾都往BaseController猛塞。那为什么不用Interface来做真抽象呢？那是因为Interface只能包含方法定义，具体实现则由派生类提供。BaseController的作用却是让派生类共享有血有肉的行为能力，难道还有每个ConcreteController去实现代码完全一样的Logger吗？
Cons：1. 在需要行为能力组合的情况下显得乏力。

由于上述问题，所以我们在开发时建议 组合优于继承，但如果组合是在BaseController上实现，那跟采用#region...#endregion划分代码片段是无异的。我们希望的是在ConcreteController直接组合Logger、Authentication等横切面功能。为什么呢？因为不是所有横切面功能都被ConcreteController所需要的，加入在BaseController中则增加冗余甚至留下隐患。

Make Mixin Pattern Clear　　　　　　　　　　　　　　　　　　

由于Multiple Inheritance容易诱发Diamond Problem，而Single Inheritance Plus Multiple Interfaces则表达乏力，那么可以引入其他方式完善上述问题呢？Mixin Pattern则是其中一种。
首先找个实现了Mixin Pattern的而我们又熟悉的实例，以便好好分析学习。很自然地我把目光投到了jQuery.extend函数，$.extend(target/*, ...args*/)会将args的成员(方法+字段)都拷贝到target中，然后target就拥有args的特性，后续处理过程中外界就可以将target当做args中的某个对象来用了。（Duck TyPE）
好了现在我们可以提取一下Mixin Pattern的特点：
1. Roles：Mixin原料（args）、Mixin对象（target）；
2. 将Mixin原料的成员（方法+字段）复制到Mixin对象中，然后Mixin对象就拥有Mixin原料的特性。
是不是这样就将Mixin Pattern描述完整了呢？当然不是啦，上面两条仅能作为初识时的印象而已。
Mixin Pattern的真实面目应该是这样的：
1. Roles：Mixin Source & Mixin Target；
2. Mixin Source将织入自身的所有成员（方法和字段）到Mixin Target；
3. Mixin Source织入的方法必须具备实现，而不仅仅是签名而已；
4. Mixin Source 和 Mixin Target相互独立。就是Mixin Target与Mixin Source互不依赖，Target即使移除Source的成员依然有效，而Source也不针对Target来设计和编码；
5. 若存在签名相同的成员，后来者覆盖前者还是保留，还是以其他规则处理都是正常的；（对象的继承链依然只有一条，因此若存在签名相同的成员，其实还是好办的^_^）
另外Mixin Pattern还细分为 对类进行Mixin（Mixin Classes） 和 对对象进行Mixin（Mixin Objects） 两种实现形式

Mixin Class

// 引入defc.js库
/* 定义mixin source */
VAR mixins1 = {
  name: 'fsjohnhuang',
  getName: function(){return this.name}
}
var mixins2 = {
  author: 'Branden eich', 
  getAuthor: function(){return this.author}
}

/*** 类定义时织入 ***/
var JS = defc('JS', [mixins1], {
  ctor: function(){},
  version: 1,
  getVersion: function(){return this.version}
})
// 实例化
var js = new JS()
js.getName() // 返回 fsjohnhuang
js.getVersion() // 返回1

/*** 类定义后织入 ***/
JS._mixin(mixins2 )
js.getAuthor() // 返回Branden Eich

Mixin Class对类织入字段和方法，因此会影响到所有类实例 和 继承链上的后续节点（既是其派生类）。

Mixin Object

// 引入defc.js库
/* 定义mixin source */
var mixins1 = {
  name: 'fsjohnhuang',
  getName: function(){return this.name}
}
var JS = defc('JS')
/*** 对Object进行Mixin ***/
var js = new JS()
defc.mixin(js, mixins1)
js.getName() //返回fsjohnhunag

Mixin Object对实例本身织入字段和方法，因此仅仅影响实例本身而已。
注意：Mixin Source实质为字段和方法的集合，而类、对象或模块等均仅仅是集合的形式而已。
上述代码片段使用的类继承实现库defc.js源码(处于实验阶段)如下：