写给自己看的小设计4 - 对象设计通用原则之扩展原则

　　除了前面学习的那些核心原则，还有一些衍生的原则，掌握它们，你将更好的面向对象。不妨称它们为"扩展原则"吧。

迪米特法则：尽量不与无关的类发生关系。

　　迪米特法则全称Law of Demeter，简称LoD，也称为最少知识原则(Least Knowledge Principle，LKP)。这个原则没什么固定的定义，大体上有这么几种说法：

1. 只与你的朋友说话
2. 不和陌生人说话
3. 对象应该只与必须交互的对象通信

　　通俗地讲，一个类应该对自己需要调用的类知道得最少，你调用的类的内部是如何实现的，都和我没关系，那是你的事情，我就知道你提供的接口方法，我就调用这么多，其他的一概不关心。

　　也可以说，不要让类也染上人们之间的那种神秘的暧昧关系。对象之间联系越是简单，则越是容易管理。

　　具体的从技术上来说，就是要求对象只与下列必须交互的各类对象通信：

(1) 当前对象本身(this)；
(2) 以参数形式传入到当前对象方法中的对象；
(3) 当前对象的成员对象；
(4) 如果当前对象的成员对象是一个集合，那么集合中的元素也都是可以交互的；
(5) 当前对象所创建的对象。

　　此外，还需要适当设置对象的访问权限。

　　正面教材太多了，就看一些反面教材吧：

// 方法链式调用，此种方式在Web页面开发中倒是常用，但是静态语言中似乎不推荐
public void Do()
{
  m_accessor.GetUser().Rename();
}
// 无谓的公开方法
class UI
{
 public void Do()
 {
  WorkHelper();
 }
 
 public void WorkHelper() { }
}

 

好莱坞法则：不要调用我，让我调用你。

　　在前面我们分析对象之间交互的时候，直接调用指的就是直接调用对象的方法，间接调用中很重要的一种就是回调，特别是在异步编程中，好莱坞法则从某种程度上来说，就是等同于在合适的时候，多使用回调函数。

　　下面是C#版本的事件实现：

public class Program
{
 static void Main(string[] args)
 {
  User user = new User();
  View ui = new View(user);
  user.Name = "Hello";
 }
}
 
delegate void OnNameChange(string name);
class View
{
 public View(User user)
 {
  user.onNameChanged += user_onNameChanged;
 }
 
 void user_onNameChanged(string name)
 {
  Console.WriteLine(name);
 }
}
 
class User
{
 private string m_name;
 public string Name
 {
  get { return m_name; }
  set
  {
   m_name = value;
   onNameChanged(m_name);
  }
 }
 public event OnNameChange onNameChanged;
}

　　这也是简单的MVC模式中的MV之间的交互方式，View作为事件的接收者，只需要提供好回调函数，当Model部分发生变化时，View自动接收到变化去更新UI(此处只是打印了出来)。

　　如果这里不使用事件(观察者模式)来实现，那么Model必然要保存View的引用(实际上内部当然还是保存了相关引用的，但是观察者合理采用各种抽象手段安排好了引用管理，比如这个例子中delegate的使用，作为C#中相当弱的耦合关系，它远比直接使用继承，实现接口的耦合性要弱的多)，当Model的数据发生变化时，直接调用View的相关方法去更新UI，这种强烈的互相依赖关系对程序来说并不是什么好的做法。而且一旦多个未确定的类似于View的角色对Model的改变感兴趣的时候，直接应用常常难于处理。

　　电影中常说，单线联系最安全，如此是也。

 

优先使用组合原则：多使用组合，少使用继承

　　复用的手段除了继承这种强约束手段，组合这种弱耦合的关系更加灵活。

　　看一个小例子：

class User
{
 public virtual void PrintType() { }
}
class Admin : User
{
 public override void PrintType() { Console.WriteLine("Employer"); }
}
class Programmer : User
{
 public override void PrintType() { Console.WriteLine("Employer"); }
}
class Manager : User
{
 public override void PrintType() { Console.WriteLine("Employer"); }
}
class Contractor : User
{
 public override void PrintType() { Console.WriteLine("Temp"); }
}

　　公司的系统中除了Contractor外几乎全是正式员工，打印类型的时候只需要打印Employer即可，而只有Contractor需要打印Temp。

　　针对这个功能，如果我们设计一个类层次像上面这样，工作是完全正常的。而且当有新的正式员工类型的话，也只需要复制一遍Admin的PrintType方法即可，这里没有违背任何的我们前面介绍的基本或者核心原则。但是我们还是发现了不爽的地方，那就是打印正式员工的代码复制的到处都是，咋办？还是 老套路，抽象加封装，再传进来。

public class Program
{
 static void Main(string[] args)
 {
  User admin = new Admin(new EmployerPrintor());
  admin.PrintType();
  User contractor = new Contractor(new TempPrintor());
  contractor.PrintType();
 }
}
 
class User
{
 Printor m_printor;
 public User(Printor printor)
 {
  m_printor = printor;
 }
 
 public virtual void PrintType() { m_printor.PrintType(); }
}
class Admin : User
{
 public Admin(Printor printor)
  :base(printor)
 {
 
 }
}
class Contractor : User
{
 public Contractor(Printor printor)
  : base(printor)
 {
 
 }
}
 
class Printor
{
 public virtual void PrintType() { }
}
class EmployerPrintor : Printor
{
 public override void PrintType() { Console.WriteLine("Employer"); }
}
class TempPrintor : Printor
{
 public override void PrintType() { Console.WriteLine("Temp"); }
}

　　对于这个原则，其实我自己宁愿描述为：合理使用继承与组合。作为复用和描述对象关系的两种最基本的手段，我想说的是适合继承的使用场景时候还是得用继承，适合使用组合的时候就使用组合。

　　个人认为：

　　继承的使用场景：满足严格的IS-A关系，也就是说当基类是真正的作为子类的强约束存在时，也即子类完全复用基类的所有信息的时候，继承是必须的。

　　注意这句话中的"严格"和"强约束"，继承作为一种最为沉重的复用关系，使用继承时要多加考虑，因为现代语言大多数都是单继承(只能继承一个类)、多实现(可以实现多个接口)的使用方式，一旦从类的继承关系被使用了以后，扩展性其实是被限制在了基类的范围内了。但是一旦确定需要它，就放下顾虑，直接使用。其实在前面的所有例子中，我们几乎每个例子中都离不开继承。

　　组合的使用场景：满足宽松的HAS-A关系，也就是说如果某个类只是作为另一个类的从属关系存在的时候，就可以使用组合了。

　　注意这句话中的"宽松"，组合使用起来就是可以这么"任性"。

　　对于很多的功能，其实纯用继承也是可以实现的，但是总是不完美，要么有冗余成员，要么复用程度不够，这个时候基本就说明单纯的继承是不够的，可以尝试使用"组合+继承"的方式。

 

　　好了，大原则中能上台面的也就是这么多了。