What design pattern is right for this situation?

I am learning design patterns and I am confused because I don’t know which pattern is best for this situation:

I have a String and this string can be different. It can be "123abc", "abc123", "abcdfe" or "123456" and only like those strings.

public void doSomething(String variousString) {
    StringType type = checkType(variousString);
    if(type==StringType.Mixed) doMixedAction();
    if(type==StringType.OnlyLetters) doOnlyLetterAction();
    if(type==StringType.OnlyDigits) doOnlyDigitsAction();
}

      

First, I thought about the Strategy pattern , but I think it doesn't fit here. Now I think that the responsibility chain fits here very well.

What is the best pattern for removing if statements in this situation? What are your opinions?

+3


source to share


2 answers


Not a classic design pattern, but a simple card can also be used



public class Main {
    private final Map<StringType, Runnable> bindings = new HashMap<>();

    public Main() {
        bindings.put(StringType.Mixed, () -> doMixedAction());
        bindings.put(StringType.OnlyLetters, () -> doOnlyLetterAction());
        bindings.put(StringType.OnlyDigits, () -> doOnlyDigitsAction());
    }

    public void doSomething(String variousString) {
        bindings.getOrDefault(checkType(variousString), () -> {}).run();
    }
}

      

+1


source


What you display with can StringType

most likely be considered a type system. As such, the relevant templates here are likely to be a simple "switcher", strategy template or visitor.

Which patterns / implementation should be chosen depends heavily on the scope and variability of the actions and types.

Some questions to consider:

  • - Is the number of actions small and is reused as infrastructure throughout the application, or will the application create many arbitrary actions?
  • Are types set?
  • it would be helpful if the Action implementations could delegate to each other, eg. to create complex behaviors from simpler ones?

Now to the templates.

In business logic with a simple switch

  • implement MyProcess.doAction()

    with a radio button to select the implementation appropriately.
  • suitable when the actions are many or unknown to the Type System, but the types are pretty well corrected.

In a type system with a simple switch



  • implement StringType.doAction()

    with a radio button to select the implementation appropriately.
  • suitable when the number of "types" is modest and is known in advance by the type system.

Strategy pattern in type system

  • or parameterize instances StringType

    to implement a method doAction()

    .
  • suitable when the number of "actions" required is modest and is known in advance by the type system.
  • The strategy can also enable a "chain of responsibility"; this occurs when delegating Strategies.

Visitor template sent from type system

  • define StringVisitor (oh my, meaningful name will make this much easier).
  • which implements the visitMixed (), visitOnlyLetters (), visitOnlyDigits () methods.
  • The StringValue or some helper can then be dispatched as type to an arbitrary visitor.

To be honest, this question and example is poor and doesn't make sense for meaningful design answers to be given - but the following should give you some food for thought.

I would definitely suggest that you try to make a meaningful domain model out of these things (IBAN Codes, if that's what they are). You will need to consider what your specific types and actions are, as well as their relative dynamism / fixity, to get a proper design.

+1


source







All Articles