知識星球
菜菜哥，出大事啦
怎麼了，你和男票分手了？很正常，誰讓你男票是產經經理呢
不是啦，是我做的一個小遊戲，需求又變了，程式我快改不動了
說來讓我歡樂一下？
菜菜哥，咱兩還能不能好好相處了
玩笑 玩笑，show time
//玩家的基礎抽象類
abstract class Player
{
public string Name { get; set; }
//.
//.
//.
//玩家的攻擊
public abstract void Attack();
}
//真實玩家
class PersonPlayer : Player
{
public override void Attack()
{
//to do something
return;
}
}
class RobotPlayer : Player
{
public override void Attack()
{
//修改攻擊內容等 to do something
return;
}
}
//攻擊介面
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;
}
}
現在我們需要靜下心來思考一番了，為什麼我們使用了面向介面程式設計，遇到這次需求，程式還是需要修改很多東西呢？
說到這裡，我們可以更系統的給Attack行為定義成一類行為，而具體的行為實現可以描述為一簇演演算法。想想看，Attack行為其實不止作用於player的型別，改日產品經理新加一個XX物件也具有攻擊行為，理想的情況是我只需要讓這個xx物件有Attack行為即可，而不需要改動以前的任何程式碼。你現在是不是對這個行為的定義理解的更深刻一些。
另外一點，到目前為止YY妹子的程式碼中一直是以繼承的方式來實現行為，這會有什麼問題呢？假如要想在程式執行時動態修改player的Attack行為，會顯得力不從心了。
談到這裡又引入了其他一個設計理念：一般情況下，有一個可能比是一個更好。具體概念為：多用組合，少用繼承。繼承通常情況下適用於事物本身的一些特性，比如：玩家基類具有姓名這個屬性，繼承類完全可以繼承這個屬性，不會發生任何問題。而組合多用於行為的設計方面，因為這個行為型別，我可能會在多個事物中出現，用組合能實現更大的彈性設計
//攻擊行為介面
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;
}
}
