jeudi 12 juillet 2018

Which is the Design Pattern of Fallback services in an array

Let's suppose I've seen a FallbackCompositeService that is used by a client object to obtain a result with a fallback mechanism. It implements a FallbackServiceInterface with a method doSomething().

We have a DI container providing the service, which is instantiated with a series of concrete fallback strategies (pseudo-PHP example here):

new FallbackCompositeService([
  new Rule1FallbackService(),
  new Rule2FallbackService(),
   ... 
])

Every fallback service implements FallbackServiceInterface too, so they also doSomething().

When we call $result = $fallbackCompositeService->doSomething(), the service cycles through its child services calling the same method, the first non-null Rule response "wins" and is returned.

The question is:

  • is this implementation a "degenerate" version of the Composite pattern (hence the name)?
  • or is it a "degenerate" version of Chain of Responsibility (where the nextHandler() pointer is simplified to an iteration through an array)?
  • or something else/undefined/both/whatever...? And its potential drawbacks?

Aucun commentaire:

Enregistrer un commentaire