歡迎光臨
每天分享高質量文章

程式員過關斬將–你的面向接口編程一定對嗎?

菜菜哥,出大事啦

怎麼了,你和男票分手了?很正常,誰讓你男票是產經經理呢

不是啦,是我做的一個小游戲,需求又變了,程式我快改不動了

說來讓我歡樂一下?

菜菜哥,咱兩還能不能好好相處了

玩笑 玩笑,show  time

妹子開始抱怨起來

01
業務背景
妹子的游戲是個對戰類的游戲,其中有一個玩家的概念,玩家可以攻擊,這個業務正是妹子開始撓頭的起點

02
第一次需求
 

YY妹子寫程式也是很利索,一天就把程式搞定了,而且還抽象出一個palyer的基類出來,堪稱高級程式員必備技能

//玩家的基礎抽象類
   abstract class Player
    {
        public string Name { getset; }
        //.
        //.
        //.

        //玩家的攻擊
       public abstract void Attack();
    }
    //真實玩家
    class PersonPlayer : Player
    {
        public override void Attack()
        {
            //to do something 
            return;
        }
    }

 

01
第二次需求
這個需求修改還是難不住YY妹子,沒過幾天代碼改好了,增加了一個機器人玩家的類,用到了OO的繼承。在這裡為玩家抽象類點贊

class RobotPlayer : Player
    {
        public override void Attack()
        {
            //修改攻擊內容等 to do something 
            return;
        }
    }

 

02
第三次需求
這個時候YY妹子終於意識到攻擊是一種行為了,需要抽象出接口來了。

//攻擊接口
    interface IAttack
    {
        void Attack();
    }
    //玩家的基礎抽象類
   abstract class Player
    {       
        //其他屬性代碼省略一萬字
    }
    //真實玩家
    class PersonPlayer :PlayerIAttack
    {
        public  void Attack()
        {
            //to do something 
            return;
        }
    }
    //機器人玩家
    class RobotPlayer :PlayerIAttack
    {
        public  void Attack()
        {
            // to do something 
            return;
        }
    }
    //怪物玩家
    class MonsterPlayer : IAttack
    {
        public  void Attack()
        {
            // to do something 
            return;
        }
    }

 

到了這裡,我們遇到了大家耳熟能詳的面向接口編程,沒錯,這個做法是對的。這也是設計的一大原則:程式依賴接口,不依賴具體實現。這裡要為YY繼續點贊。順便說一下,在多數情況下,很多同學就到此為止了

01
第四次需求
據說此刻YY妹子的心裡是一萬頭羊駝飄過的狀態。這次要怎麼設計呢?這也是菜菜要說的重點部分。

現在我們需要靜下心來思考一番了,為什麼我們使用了面向接口編程,遇到這次需求,程式還是需要修改很多東西呢?

 

設計原則:找出應用中將來可能變化的地方,把他們獨立出來,不需要和那些不變的代碼混在一起。

 

這樣的概念很簡單,確是每個設計樣式背後的靈魂所在。到目前為止,設計中不斷在變的是Attack這個接口,更準確的應該是Attack這個行為。面向接口這個概念沒有問題,是大多數人把語言層面和設計層面的接口含義沒搞明白,真正的面向接口編程更偏向於面向架構中行為的編程,另外一個角度也可以看做是利用OO的多型原則。

 

說到這裡,我們可以更系統的給Attack行為定義成一類行為,而具體的行為實現可以描述為一簇演算法。想想看,Attack行為其實不止作用於player的型別,改日產品經理新加一個XX物件也具有攻擊行為,理想的情況是我只需要讓這個xx物件有Attack行為即可,而不需要改動以前的任何代碼。你現在是不是對這個行為的定義理解的更深刻一些。

 

另外一點,到目前為止YY妹子的代碼中一直是以繼承的方式來實現行為,這會有什麼問題呢?假如要想在程式運行時動態修改player的Attack行為,會顯得力不從心了。

 

談到這裡又引入了其他一個設計理念:一般情況下,有一個可能比是一個更好。具體概念為:多用組合,少用繼承。繼承通常情況下適用於事物本身的一些特性,比如:玩家基類具有姓名這個屬性,繼承類完全可以繼承這個屬性,不會發生任何問題。而組合多用於行為的設計方面,因為這個行為型別,我可能會在多個事物中出現,用組合能實現更大的彈性設計

02
面向行為編程(千言萬語不如10行代碼)
封裝行為一簇

//攻擊行為接口
    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;
        }
    }   

 

寫在最後
接口是一種規範和約束,更高層的抽象更像是一類行為,面向接口編程只是代碼層體現的一種格式體現而已,真正的面向接口設計更貼近面向行為編程

    赞(0)

    分享創造快樂