不知从何时起，我不太轻易去设计抽象类了，一方面是因为我写的业务确实没有设计抽象类的需求，另一方面则基于以下三个考虑：
1、面向对象编程中建议多使用“组合”而不是使用“抽象”，原因在于“组合”更加灵活。
2、因为要公用一个“方法”，就迫不及待的设计出抽象关系，很容易造成抽象类不够SRP，久而久之抽象类成了大杂烩，不忍直视。
3、抽象设计要符合LSP（里氏替换原则），LSP是指：子类型必须能够替换掉它们的基本类型。
我们经常说继承关系就是IS-A关系，也就是说，如果一个新类型的对象被认为和一个已有类的对象之间满足IS-A关系，那么这个新类型就可以从已知类派生。
在《敏捷软件开发 原则、模式与实践》一书中，Robert C.Martin提到了一个关于正方形和矩形的例子让我记忆犹新：
从一般意义上讲，一个正方形就是一个矩形。因此，把Square视为从Rectangle类派生似乎是符合逻辑的。但是这一设计却会带来微妙的问题：
public class Rectangle
{
protected double Width;
protected double Height;
public void SetWidth(double width)
{
Width = width;
}
public void SetHeight(double height)
{
Height = height;
}
public double Area
{
get { return Height*Width; }
}
}
如果我们从Rectangle类派生一个Square类会怎样呢？
首先Square并不需要Width和Height两个成员，更加严重的问题是SetWidth和SetHeight这两个方法对Square类而言是不合适的，因为正方形的长度和宽度是相等的，不过我们可以复写这两个方法：
public class Square : Rectangle
{
public new void SetWidth(double width)
{
Width = Height = width;
}
public new void SetHeight(double height)
{
Width = Height = height;
}
}
这样似乎没问题了，但是考虑下面的测试：
public void TestArea(Rectangle rectangle)
{
rectangle.SetHeight(10);
rectangle.SetWidth(2);
var area = rectangle.Area;
Debug.Assert(area == 20,"area should be 20");
}
根据LSP原则，所有基类都可以用子类代替，这意味着我们在这个函数中可以传入一个Square实例，这将导致测试不通过，也就意味着该设计不符合LSP。
由此可见，一个良好的继承设计并不是将基类标记为abstract这么简单。
我在再谈扩展方法，从String.IsNullOrEmpty一文中提到过一种继承的替换方案，可以将公共方法扩展在接口上，本文我将再介绍一种带有函数式味道的方案。
举个栗子:
1、传统的继承方案
这是一个使用继承关系的设计方案，基类WebCrawlerProvider提供了三个虚方法，子类可以选择复写，比如写一个专门抓图片的ImageCrawlerProvider子类和一个专门抓取视频的VedioCrawlerProvider子类：
public class WebCrawlerProvider
{
public virtual bool CheckContent(RequestContext context)
{
return true;
}
public virtual Crawler GetCrawler(RequestContext content)
{
return new Crawler();
}
public virtual void SaveContent()
{
//save it
}
}
public class ImageCrawlerProvider:WebCrawlerProvider
{
public override bool CheckContent(RequestContext context)
{
//if it is image
return true;
}
public override void SaveContent()
{
//save to D:image
}
}
public class VedioCrawlerProvider : WebCrawlerProvider
{
public override bool CheckContent(RequestContext context)
{
//if it is vedio
return true;
}
public override Crawler GetCrawler(RequestContext content)
{
return new VedioCrawler();
}
public override void SaveContent()
{
//save to d:vedio
}
}
2、带有函数式味道的方案
相比于使用类继承，接口继承更加稳定和灵活，一般而言使用接口继承基本不会违反“面向对象”的各种原则，所以我们先定义一个接口：
public interface IWebCrawlerProvider
{
Func<RequestContext, bool> CheckContent { get; set; }
Func<RequestContext, Crawler> GetCrawler { get; set; }
Action SaveContent { get; set; }
}
该接口的实现只需要一个通用实现即可：
public class WebCrawlerProvider : IWebCrawlerProvider
{
public Func<RequestContext, bool> CheckContent { get; set; }
public Func<RequestContext, Crawler> GetCrawler { get; set; }
public Action SaveContent { get; set; }
public WebCrawlerProvider()
{
CheckContent = context => true;
GetCrawler=context=>new Crawler();
SaveContent=()=>{/*save to c:default*/};
}
}
该实现将之前的方法设计为公共属性，这意味着我们可以直接对该属性赋值，此时如果实现一个ImageCrawlerProvider和VedioCrawlerProvider该当如何？
//use default WebCrawlerProvider
var crawlerProvider=new WebCrawlerProvider();
//use image CrawlerProvider
var imageCrawlerProvider=new WebCrawlerProvider()
{
CheckContent = context =>/*if it is image*/ true,
GetCrawler = context=>new Crawler(),
SaveContent = () => { /*save it to d:image*/}
};
//use vedio CrawlerProvider
var vedioCrawlerProvider = new WebCrawlerProvider()
{
CheckContent = context => /*if it is vedio*/ true,
GetCrawler = context => new Crawler(),
SaveContent = () =>{/*save it to d:vedio*/}
};
直观感受，后面的方案比继承方案更加简洁，代码量更少，熟练使用该方案和再谈扩展方法，从String.IsNullOrEmpty一文中提到的方案将会使你的代码增色不少。你觉得该方案相比类继承的方案如何呢？