妹子开始埋怨起来

业务背景

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

第一次需要

产品经理:玩家有很多属性,例如:身高,性别 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;        }    }   

写在最初

接口是一种标准和束缚,更高层的形象更像是一类行为,面向接口编程只是代码层体现的一种格局体现而已,真正的面向接口设计更贴近面向行为编程

增加关注,查看更精美版本,播种更多精彩