В шаблоне стратегии, как лучше всего справиться с общим поведением?

Я реализовал шаблон стратегии. Есть ли разумный способ справиться с дублированием нижеприведенных функций function2() и function1()?
В интерфейсе IBehaviour есть другие члены, которые не имеют общих функций.

class Behaviour1: IBehaviour
{
    public void DoSomething()
    {
        Function1();
    }
    //other functions of IBehaviour
}

class Behaviour2 : IBehaviour
{

   public void DoSomething()
   { 
       Function2();
       Function1();
   }
   //other functions of IBehaviour
}

class Behaviour3 : IBehaviour
{
    public void DoSomething()
    {
        Function2();
    }
    //other functions of IBehaviour
}

У меня уже есть один класс для борьбы с таким поведением. Затем я понял, что разные ситуации требуют разного поведения, поэтому в этом основном классе я создаю объект Behavior во время выполнения. Я не хочу создавать еще один класс для Function1 и Function2, поэтому мне было интересно, есть ли что-то, чего мне не хватает.


person user1725145    schedule 22.02.2014    source источник
comment
Кажется, вы все правильно инкапсулировали. Я не уверен, что понял вашу проблему   -  person Luis Filipe    schedule 22.02.2014


Ответы (2)


На ум приходит один из двух простых вариантов:

  1. Сделать Behavior3 наследником Behavior2. Я бы рекомендовал этот подход только в том случае, если вы можете установить четкие отношения «IS A», иначе этот подход к проектированию может действительно создать вам проблемы позже, если что-то изменится в том, как Behavior2 работает по отношению к Behavior3.

  2. Переместите Function2() во вспомогательный класс, который Behavior2 и Behavior3 могут использовать независимо друг от друга.

person Matthew Cox    schedule 22.02.2014

Если лучше повторно использовать в качестве компенсации за немного большую сложность, которую вы хотите, разделение IBehavior на IBehavior1 и IBehavior2 может быть целесообразным. Затем Behavior1 будет реализовывать IBehavior1, а Behavior3 будет реализовывать оба, и т. д. Этот подход будет идти по той же линии с принципами единой ответственности и (возможно) разделения интерфейсов.

person henginy    schedule 22.02.2014