继承结构的另类实现方式

不知从何时起，我不太轻易去设计抽象类了，一方面是因为我写的业务确实没有设计抽象类的需求，另一方面则基于以下三个考虑：

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一文中提到的方案将会使你的代码增色不少。你觉得该方案相比类继承的方案如何呢？