关于装饰器和策略模式 C# 的 OOP 设计问题

Question

举例来说，你有一个基础抽象类

public abstract Foo
{
  IFlyable _fly;
  ISwimmable _swim;

  void performSwim()
  {
    _swim.swim();
  }

 void performFly()
 {
   _fly.fly();
 }
}

，并且有你的系统中将有的行为/算法

interface IFlyable { void fly(); }
interface ISwimmable { void swim(); }
interface IVoteable { void vote(); }

等等

现在你有多个类来实现它，具体为 IFlyable、ISwimmable 等等

class Bar: Foo { _swim = new ConcerteSwim(); }
class Baz: Foo { _fly = new ConcreteFly(); }

等，

其中之一是在基础中使用策略模式Foo 类来交换行为。

我们还可以使用装饰器模式来用某些行为来包装它，但是由于装饰器用基类来包装它，如果我们稍后向对象添加更多行为，我们如何真正允许开闭原则在不触及基类的情况下工作。 由于当我们添加更多行为时，这些行为可能会有不同的签名，而不仅仅是像调用装饰器那样，

void performSwim()
{
     swimWithMoreSpeed() + foo.performSwim()
}

我想我的问题是，如果我添加更多行为，我如何才能在不修改基类的情况下仍然能够说添加 IWeaponBehavior、ISomeBehaviour到一个班级。

例如我想要一个类

public class XYF: Foo
{

}

，但我想给它一些 ISomeBehaviour 的行为，有没有一种方法可以用这些行为来包装它，或者更像是一个 ConcreteFoo 用这些行为来包装它，现在做一些事情而不是在具体的 xyz 上实现接口，尽管这会让您实现多种具体行为类，例如 SwimBehaviour、NullBehaviour 等，但没有办法摆脱它。

有没有办法在设计模式中做到这一点？ 它几乎看起来像是模式的混合体。

我知道，如果它像鸭子一样行走，像鸭子一样嘎嘎叫，但需要电池，那么你的抽象就有问题了。

希望这是有道理的。

Answer 1

尝试装饰器模式。 要支持新行为，您只需实现一个继承自 Foo 的新类，实现 IWeaponBehavior 并装饰另一个 Foo 对象。 然后，您现在可以将 WeaponDecorator 用作 Foo 或 IWeaponBehavior，并且仍然可以访问它的基本 Foo装饰。

基类：

public abstract Foo { void Jump(); }

具有基本行为的具体子类：

public Bar : Foo { void Jump() { /* jump! */ } }
public Baz : Foo { }

行为接口：

interface IFlyable { void Fly(); }
interface ISwimmable { void Swim(); }

具有行为的装饰器子类：

public FlyableFoo : Foo, IFlyable
{
    public Foo Base { get; set; }
    public FlyableFoo(Foo base) { Base = base; }
    void Fly() { Base.Jump(); /* fly! */ }
}

现在我们可以使用其特定的 Jump() 实现来使任何 Foo 飞行：

Baz baz = new Baz();
FlyableFoo flybaz = new FlyableFoo(baz);
flybaz.Fly();

Answer 2

访客模式怎么样？ 它允许基类的实现者改变行为，而无需强制基类针对每个新实现进行更改：

public interface IFlyable { void fly(); }
public interface ISwimmable { void swim(); }
public interface IVoteable { void vote(); }

public abstract class Animal
{
    public abstract void Accept(AnimalVisiter Visitor);
    //some common behaviour is here
    public bool LegsKicking { get; set; }
    public bool ArmsFlapping { get; set; }
}

//This class now absorbs new responisbilities, so base class doesn't have to
public class AnimalVisiter
{
    public void Visit(ISwimmable Subject)
    {
        Subject.swim();
    }

    public void Visit(IVoteable Subject)
    {
        Subject.vote();
    }

    public void Visit(IFlyable Subject)
    {
        Subject.fly();
    }
}

public class SwimmingHuman : Animal, ISwimmable
{
    public void swim()
    {
        LegsKicking = true;
    }

    public override void Accept(AnimalVisiter Visitor)
    {
        Visitor.Visit(this);
    }
}

public class VotingHuman : Animal, IVoteable
{

    public override void Accept(AnimalVisiter Visitor)
    {
        Visitor.Visit(this);
    }

    public void vote()
    {
        VoteCast = true;
    }
    //some specific behaviour goes here
    public bool VoteCast { get; set; }
}

public class SwimmingTiger : Animal, ISwimmable
{

    public void swim()
    {
        LegsKicking = true;
        //also wag tail, flap ears
    }

    public override void Accept(AnimalVisiter Visitor)
    {
        Visitor.Visit(this);
    }
}

Answer 3

所以这是我对此的看法：

public enum ActionType
{
   Swim, Vote, Fly
};

public interface IBehavior
{
   public boolean ActionReady;
   public ActionType _type;

   public void performMyAction();
}

public abstract Foo
{
  IBevahior[] behaviors;

  // if you want to keep track of behavior states as on or off
  void perform()
  {
    for(int i = 0; i< behaviors.length; i++)
    {
       if(behaviors[i].ActionReady)
       {
          behaviors[i].performMyAction();
       }
    }
  }

  // if you want to call behaviors individually
  void performType(ActionType type)  // however you want to make the distinction
  {
     for(int i = 0; i < behaviors.length; i++)
     {
        if(behaviors[i].type = type)
        {
            behaviors[i].performMyAction();
        }
     }
  }
}

然后让 ISwimmable 等接口继承自 IBehavior。