title: Design OOP question on Decorator and Strategy pattern C#
body: <p>Say for example you have a base abstract class</p>
  
  <pre><code>public abstract Foo
  {
    IFlyable _fly;
    ISwimmable _swim;
  
    void performSwim()
    {
      _swim.swim();
    }
  
   void performFly()
   {
     _fly.fly();
   }
  }
  </code></pre>
  
  <p>And have behaviors/algorithm that you will have in your system</p>
  
  <pre><code>interface IFlyable { void fly(); }
  interface ISwimmable { void swim(); }
  interface IVoteable { void vote(); }
  </code></pre>
  
  <p>etc etc</p>
  
  <p>Now you have multiple class that implement it, with concrete of IFlyable, ISwimmable etc</p>
  
  <pre><code>class Bar: Foo { _swim = new ConcerteSwim(); }
  class Baz: Foo { _fly = new ConcreteFly(); }
  </code></pre>
  
  <p>etc etc</p>
  
  <p>One is using the strategy pattern in the base class of Foo to swap in the behaviours.</p>
  
  <p>We could also use the decorator pattern to wrap it with certain behavior but since the decorator wraps it with base class, how do we actually allow the open close principle to work without touching the base class if we later on add more behaviors to objects. Since these behavior might have different signatures as we add more, rather than just for example like calling in decorator</p>
  
  <pre><code>void performSwim()
  {
       swimWithMoreSpeed() + foo.performSwim()
  }
  </code></pre>
  
  <p>I guess my question is if I add more behavior, how can I not modify the base class and still be able to say add IWeaponBehavior, ISomeBehaviour to a class.</p>
  
  <p>for example I want to have a class</p>
  
  <pre><code>public class XYF: Foo
  {
  
  }
  </code></pre>
  
  <p>But I want to give it some behavior of ISomeBehaviour, is there a way I could say wrap it with these kinds of behaviour, or more like here is an ConcreteFoo wrap it with these behaviours and now do stuff rather than implementing the interface on concrete xyz although that makes you implementing so many kinds of concretebehaviour class like swimbehaviour, nullbehaviour etc but there is no way out of it.</p>
  
  <p>Is there a way to do this in design patterns? It almost seems like a hybrid of patterns.</p>
  
  <p>I know it almost seems like if it walks like a duck and quacks like a duck but requires battery then you have something wrong with abstraction.</p>
  
  <p>Hope this make sense.</p>