程序员过关斩将--你的面向接口编程必定对吗？

妹子开始抱怨起来

业务背景

妹子的游戏是个对战类的游戏，其中有一个玩家的概念，玩家能够攻击，这个业务正是妹子开始挠头的起点

第一次需求

产品经理：玩家有不少属性，例如：身高，性别 blalalala ,玩家能够攻击其余玩家。

YY妹子写程序也是很利索，一天就把程序搞定了，并且还抽象出一个palyer的基类出来，堪称高级程序员必备技能。

//玩家的基础抽象类
   abstract class Player
    {
        public string Name { get; set; }
        //.
        //.
        //.

        //玩家的攻击
       public abstract void Attack();
    }
    //真实玩家
    class PersonPlayer : Player
    {
        public override void Attack()
        {
            //to do something 
            return;
        }
    }
复制代码

第二次需求

产品经理：游戏里我须要增长机器人玩家来增长游戏在线的人数，机器人属性和真实玩家同样，可是攻击不太同样

这个需求修改仍是难不住YY妹子，没过几天代码改好了，增长了一个机器人玩家的类，用到了OO的继承。在这里为玩家抽象类点赞

class RobotPlayer : Player
    {
        public override void Attack()
        {
            //修改攻击内容等 to do something 
            return;
        }
    }
复制代码

第三次需求

产品经理：我要建立一批相似玩家的怪物，没有真实玩家的那些属性，可是和真实玩家同样有攻击行为

这个时候YY妹子终于意识到攻击是一种行为了，须要抽象出接口来了。

//攻击接口
    interface IAttack
    {
        void Attack();
    }
    //玩家的基础抽象类
   abstract class Player
    {       
        //其余属性代码省略一万字
    }
    //真实玩家
    class PersonPlayer :Player, IAttack
    {
        public  void Attack()
        {
            //to do something 
            return;
        }
    }
    //机器人玩家
    class RobotPlayer :Player, IAttack
    {
        public  void Attack()
        {
            // to do something 
            return;
        }
    }
    //怪物玩家
    class MonsterPlayer : IAttack
    {
        public  void Attack()
        {
            // to do something 
            return;
        }
    }
复制代码

到了这里，咱们遇到了你们耳熟能详的面向接口编程，没错，这个作法是对的。这也是设计的一大原则：程序依赖接口，不依赖具体实现。这里要为YY继续点赞。顺便说一下，在多数状况下，不少同窗就到此为止了

第四次需求

产品经理：我如今要设计玩家的攻击方式了，目前有远程攻击，近程攻击，贴身攻击这三类，其余需求 blalalalala。

听说此刻YY妹子的内心是一万头羊驼飘过的状态。此次要怎么设计呢？这也是菜菜要说的重点部分。 如今咱们须要静下心来思考一番了，为何咱们使用了面向接口编程，遇到此次需求，程序仍是须要修改不少东西呢？

设计原则：找出应用中未来可能变化的地方，把他们独立出来，不须要和那些不变的代码混在一块儿。

这样的概念很简单，确是每一个设计模式背后的灵魂所在。到目前为止，设计中不断在变的是Attack这个接口，更准确的应该是Attack这个行为。面向接口这个概念没有问题，是大多数人把语言层面和设计层面的接口含义没搞明白，真正的面向接口编程更偏向于面向架构中行为的编程，另一个角度也能够看作是利用OO的多态原则。

说到这里，咱们能够更系统的给Attack行为定义成一类行为，而具体的行为实现能够描述为一簇算法。想一想看，Attack行为其实不止做用于player的类型，改日产品经理新加一个XX对象也具备攻击行为，理想的状况是我只须要让这个xx对象有Attack行为便可，而不须要改动之前的任何代码。你如今是否是对这个行为的定义理解的更深入一些。

两外一点，到目前为止YY妹子的代码中一直是以继承的方式来实现行为，这会有什么问题呢？假如要想在程序运行时动态修改player的Attack行为，会显得力不从心了。

谈到这里又引入了其余一个设计理念：通常状况下，**有一个可能比是一个更好。**具体概念为：多用组合，少用继承。继承一般状况下适用于事物自己的一些特性，好比：玩家基类具备姓名这个属性，继承类彻底能够继承这个属性，不会发生任何问题。而组合多用于行为的设计方面，由于这个行为类型，我可能会在多个事物中出现，用组合能实现更大的弹性设计。

面向行为编程（千言万语不如10行.Net Core代码）

封装行为一簇

//攻击行为接口
    interface IAttack
    {
        void Attack();
    }
    
    class RemoteAttack : IAttack
    {
        public void Attack()
        {
            //远程攻击
        }
    }
    class ShortAttack : IAttack
    {
        public void Attack()
        {
            //近程攻击
        }
    }
复制代码

事物包含行为组合

//玩家的基础抽象类
    abstract class Player
    {       
        //其余属性代码省略一万字
    }
    //真实玩家
    class PersonPlayer : Player
    {
        //玩家能够有攻击的行为
        IAttack attack;
        public PersonPlayer(IAttack _attack)
        {
            attack = _attack;
        }
       
        public  void Attack()
        {
            //调用行为一簇算法的实现
            attack.Attack();
            return;
        }
        //玩家能够运行时修改攻击行为
        public void ChangeAttack(IAttack _attack)
        {
            attack = _attack;
        }
    }   
复制代码

写在最后

接口是一种规范和约束，更高层的抽象更像是一类行为，面向接口编程只是代码层体现的一种格式体现而已，真正的面向接口设计更贴近面向行为编程

---

添加关注，查看更精美版本，收获更多精彩