What pattern should be used, strategy?

Question

I do have a service which needs to handle two types of meal.

@Service
class MealService {

   private final List<MealStrategy> strategies;

   MealService(…) {
       this.strategies = strategies;
   }

   void handle() {
       var foo = …;
       var bar = …;
       strategies.forEach(s -> s.remove(foo, bar));
   }
}

There are two strategies, 'BurgerStrategy' and 'PastaStrategy'. Both implements Strategy interface with one method called remove which takes two parameters.

BurgerStrategy class retrieves meals of enum type burger from the database and iterate over them and perform some operations. Similar stuff does the PastaStrategy.

The question is, does it make sense to call it Strategy and implement it this way or not?

Also, how to handle duplications of the code in those two services, let's say both share the same private methods. Does it make sense to create a Helper class or something?

Answer 1

does it make sense to call it Strategy and implement it this way or not

I think these classes 'BurgerStrategy' and 'PastaStrategy' have common behaviour. Strategy pattern is used when you want to inject one strategy and use it. However, you are iterating through all behaviors. You did not set behaviour by getting one strategy and stick with it. So, in my honour opinion, I think it is better to avoid Strategy word here.

So strategy pattern would look like this. I am sorry, I am not Java guy. Let me show via C#. But I've provided comments of how code could look in Java. This is our abstraction of strategy:

public interface ISoundBehaviour
{
    void Make();
}

and its concrete implementation:

public class DogSound : ISoundBehaviour // implements in Java
{
    public void Make()
    {
        Console.WriteLine("Woof");
    }
}


public class CatSound : ISoundBehaviour
{
    public void Make()
    {
        Console.WriteLine("Meow");
    }
}

And then we stick with one behaviour that can also be replaced:

public class Dog
{
    ISoundBehaviour _soundBehaviour;

    public Dog(ISoundBehaviour soundBehaviour)
    {
        _soundBehaviour = soundBehaviour;
    }

    public void Bark()
    { 
        _soundBehaviour.Make();
    }

    public void SetAnotherSound(ISoundBehaviour anotherSoundBehaviour) 
    {
        _soundBehaviour = anotherSoundBehaviour;
    }
}   

how to handle duplications of the code in those two services, let's say both share the same private methods.

You can create one base, abstract class. So basic idea is to put common logic into some base common class. Then we should create abstract method in abstract class. Why? By doing this, subclasses will have particular logic for concrete case. Let me show an example.

An abstract class which has common behaviour:

public abstract class BaseMeal
{
    // I am not Java guy, but if I am not mistaken, in Java,
    // if you do not want method to be overriden, you shoud use `final` keyword
    public void CommonBehaviourHere()
    { 
        // put here code that can be shared among subclasses to avoid code duplication
    }

    public abstract void  UnCommonBehaviourShouldBeImplementedBySubclass();
}

And its concrete implementations:

public class BurgerSubclass : BaseMeal // extends in Java
{
    public override void UnCommonBehaviourShouldBeImplementedBySubclass()
    {
        throw new NotImplementedException();
    }
}

public class PastaSubclass : BaseMeal // extends in Java
{
    public override void UnCommonBehaviourShouldBeImplementedBySubclass()
    {
        throw new NotImplementedException();
    }
}