プログラマーはクリアします--あなたのインタフェース向けのプログラミングはきっと正しいですか?

妹が文句を言い始めた

ビジネスの背景

妹のゲームは対戦系のゲームで、その中の1つのプレイヤーの概念があって、プレイヤーは攻撃することができて、この業務はまさに妹が頭をかく起点です

第一次需要

プロダクトマネージャ:プレイヤーには多くの属性があります.例えば、身長、性別blalala、プレイヤーは他のプレイヤーを攻撃することができます.
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;
        }
    }

第2次需要

プロダクトマネージャ:ゲームではロボットプレイヤーを増やしてオンラインの人数を増やす必要があります.ロボットの属性は実際のプレイヤーと同じですが、攻撃は違います.
この需要を修正するのはやはり难しくてYY妹、数日もしないうちにコードを変更して、ロボットプレイヤーのクラスを追加して、OOの継承を使いました.ここではプレイヤー抽象クラスにいいねをします

class RobotPlayer : Player
    {
        public override void Attack()
        {
            //        to do something 
            return;
        }
    }

第3次需要

プロダクトマネージャ:プレイヤーのようなモンスターを作成します.実際のプレイヤーの属性はありませんが、実際のプレイヤーと同じように攻撃行為があります.
この時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のためにいいねを続けます.ちなみに、多くの場合、多くの学生はここまでです.

第4次需要

製品マネージャー:私は今プレイヤーの攻撃方式を設計します.現在、遠隔攻撃、近距離攻撃、身近な攻撃の3種類があります.その他の需要はblalalalalaです.
今はYYちゃんの心の中には1万頭のアルパカが漂っている状態だそうです.今回はどのようにデザインしますか?これも料理のポイントです.今、私たちは心を静めて考えなければなりません.なぜ私たちはインタフェース向けのプログラミングを使っていますか.今回のニーズに直面して、プログラムはやはり多くのものを修正する必要がありますか.
設計原則:応用の中で将来変化する可能性のある場所を見つけて、彼らを独立させて、それらの不変のコードと混同する必要はありません.
このような概念は簡単で、確かに各設計モードの背後にある魂がある.これまで、デザインはAttackというインタフェースに変わりつつあり、より正確にはAttackという行為であるべきである.インタフェース向けという概念は問題なく、多くの人が言語面と設計面のインタフェースの意味を理解していないため、本当のインタフェース向けプログラミングはアーキテクチャ中の行為向けプログラミングに偏っており、もう一つの角度ではOOを利用する多態原則と見なすことができる.
ここでは,Attack挙動をより系統的に一種類の挙動として定義することができ,具体的な挙動実装はクラスタアルゴリズムとして記述できる.考えてみれば、Attackの行為は実際にプレイヤーのタイプに作用するだけでなく、製品マネージャーが新たにXXオブジェクトを追加しても攻撃行為を持っています.理想的には、私はこのxxオブジェクトにAttack行為を持たせるだけで、以前のコードを変更する必要はありません.あなたは今、この行為の定義をもっと深く理解しているのではないでしょうか.
どちらかというと、これまでYY妹のコードの中でずっと継承的に行動を実現してきたのですが、これは何か問題がありますか?プログラム実行時にプレイヤーの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;
        }
    }   

最後に書く

インタフェースは1種の規範と制約で、もっと高いレベルの抽象は更に1類の行為のようで、インタフェース向けのプログラミングはただコード層の体現の1種のフォーマットの体現だけで、本当のインタフェース向けの設計は更に行為向けのプログラミングに近いです
注目を追加し、より美しいバージョンを表示し、より素晴らしいものを得る