用于分析实例组合的设计模式？

Question

I'm looking for a recommendation on a design pattern which could be used to interpret an array of different Object instances. Ideally, these pattern definitions would be statically defined.

So, as an example, I'm looking for something along the lines of this:

Ingredient [] lIngredients = new Ingredient []{ new Lime (), new Soda (), new Sugar (), new Mint (), new Rum () };

Patterns.WHITE_RUSSIAN.isRecipe(lIngredients);//returns false Patterns.MOJITO.isRecipe(lIngredients);//returns true

I managed to develop a working solution using Object class references, however it's clear that later on in my development some of my patterns will rely upon instance data members, whilst others will not. I'd like the patterns to be flexible, so they may not have to depend on a specific ordering in the array, or ignore superfluous elements, or detect duplicates.

Are there any widely-used approaches that suit these requirements?

Answer 1

Probably, you can do it using one of those two

interface Ingredient {
  boolean belongsTo(Cocktail cocktail)
}

interface Cocktail {
  boolean hasIngredient(Ingredient ingredient)
}

A Cocktail itself can be an array or other aggregation of Ingredients

Answer 2

The preferred design pattern for when you have a hierarchy of classes to be processed is the Visitor pattern .

public class Lime {
    public void accept(IngredientVisitor visitor) {
        visitor.visit(this);
    }
}
public class Soda {
    public void accept(IngredientVisitor visitor) {
        visitor.visit(this);
    }
}

public class MojitoVisitor extends IngredientVisitor {
    public void visit(Lime lime) {      
        System.out.println("Visiting lime");
    }

    public void visit(Soda soda) {
        System.out.println("Visiting soda");
    }
}

EDIT: I agree solution above creates too much overhead. I'd then go with a Matcher like Hamcrest where you can do something like:

private Matcher mojitoMatcher = arrayContainingInAnyOrder(
        instanceOf(Rum.class),
        instanceOf(Mint.class),
        instanceOf(SodaWater.class),
        instanceOf(Lime.class),
        instanceOf(Sugar.class)
);
public boolean isMojito(Ingredient[] ingredients) {
    return mojitoMatcher.matches(ingredients);
}

Answer 3

After a little contemplation and encouragement from the wonderful answers offered by other StackOverflow users, I think I've stumbled upon a reasonable solution.

Scenario We'd like to take an array of Ingredient s and systematically interpret the range of delicious cocktail recipes that can be reproduced from them. The relationships must be flexible and capable of accessing data members from our generic array specifications.

Technical In this application, we'll be processing a collection of instances. In this regard we'd like to develop pattern-matching code that acts as a function of aggregate set of data members, rather than have the data members themselves define the logic of a recipe. The reason for this is two-fold; firstly, an Ingredient is not just only ever used in just a Cocktail (which will pertube the more party-prone amongst you) ; it could be in a Cake , a Salad or even an Colonoscopy ; therefore we're obliged to abstract the analysis logic from the base class specifications to improve separation of responsibilities. This approach inspires us to develop a set of generic tools that are applicable for a whole range of different applications, not just my imaginary bar. Secondly, it enables us to process autoboxed Java Primitives or Java Beans without having to construct any interfaces. Another happy biproduct of this approach is that it enables much clearer visualization of the Cocktails pattern as a whole; there's no 'hidden' interactions between class calls.

So, rather than handling the relationships between different Ingredient s, I decided to formalise the entire approach as finite interactions between two generic entities; Alice and Bob . I've decided to refer to these interactions as a Liason , not only because I'm just sad, but also lonely.

Design First, I've constructed an Interface called ILiason . I use an interface because this enables existing classes in a design to integrate with the pattern matching architecture without causing multiple-inheritance conflicts.

/* Defines the basis of a ILiason. */ public interface ILiason<A, B> { /* Defines whether a ILiason exists between Alice and Bob. */ public abstract boolean isLiason(final A pAlice); /* Returns the source of comparison. */ public abstract B getBob(); }

In ILiason , we define two simple methods that are dependent on two generic types, A ( Alice ) and B ( Bob ). A will be the runtime collection or Object we wish to compare against, and B will be the source of Comparison returned by getBob() . In the method isLiason(final A pAlice) , we will define the specific logic in how to properly compare Alice and Bob .

In the Cocktails application, I've decided to represent each specific Ingredient as an implementor of the IIngredient interface. You'll see below that we define things like Rum , Vodka and eugh... Gin . I've also defined an additional extension to IIngredient , ISpoonfuls ; this enumerates the number of spoonfuls of a certain ingredient the caller has selected. A concrete implementation of ISpoonfuls is defined within the IIngredient.Sugar class specification.

`/* The base ingredient interface. */ public interface IIngredient {

/* Amount Interface. */
public static interface ISpoonfuls extends IIngredient {
    /* Returns the Number of Teaspoons required for the concrete Ingredient. */
    public abstract int getNumberOfTeaSpoons();
}

/* Define some example implementations. */
public static final class Rum      implements IIngredient { }; 
public static final class Liquor   implements IIngredient { }; 
public static final class Vodka    implements IIngredient { }; 
public static final class Cream    implements IIngredient { }; 
public static final class Gin      implements IIngredient { }; 
public static final class Vermouth implements IIngredient { }; 
public static final class Orange   implements IIngredient { }; 
public static final class Lime     implements IIngredient { }; 
public static final class Soda     implements IIngredient { }; 
public static final class Mint     implements IIngredient { }; 

public static final class Sugar  implements ISpoonfuls  { 
    /* Member Variables. */
    private final int mNumberOfTeaspoons;
    /* Constructor. */
    public Sugar(final int pNumberOfTeaspoons) {
        /* Initialize Member Variables. */
        this.mNumberOfTeaspoons = pNumberOfTeaspoons;
    }
    /* Getters. */
    @Override public int getNumberOfTeaSpoons() { return this.mNumberOfTeaspoons; } 
}; 

}`

It's clear from this design that in order to check for the presence of a certain IIngredient in a collection, we'll wish to test for it's Class. So, we'll define our first ILiason type, the Assignable :

/* A ILiason used to determine whether a given instance is assignable from a given class. */ public static abstract class Assignable<A> implements ILiason<A, Class<?>> { /* Default Implementation Stub. */ public static final class Impl<A> extends Assignable<A> { private final Class<?> mBob; public Impl(final Class<?> pBob) { this.mBob = pBob; } @Override public final Class<?> getBob() { return this.mBob; } }; /* Determines whether Alice is an assignable form of Bob. */ @Override public final boolean isLiason(final A pAlice) { /* Checks whether the source class of Alice is compatible with the concretely-defined Bob. */ return (this.getBob().isAssignableFrom(pAlice.getClass())); } };

In the abstract (incomplete) Assignable class, we'll see that we define a generic specification of the Alice type, however we assert that Bob must be a Class<?> reference. In our concrete definition of isLiason(final A pAlice) , we use the Class<?> reference returned by getBob() in conjunction with the method isAssignableFrom(Class<?> c) to investigate if Java can detect an existing hierarchy between Alice and Bob . We use this metric as the result for whether there's an existing liason between Alice and Bob . In Cocktails , we're able to use this basic form of ILiason to detect specific Class types.

As a basic implementation, below I demonstrate how to detect if a certain instance is a specific type of IIngredient : (new ILiason.Assignable<IIngredient>() { @Override public Class<?> getBob() { return Lime.class; } }).isLiason(Lime.class); // Returns true! (new ILiason.Assignable<IIngredient>() { @Override public Class<?> getBob() { return Lime.class; } }).isLiason(Lime.class); // Returns true! (new ILiason.Assignable<IIngredient>() { @Override public Class<?> getBob() { return Lime.class; } }).isLiason(Mint.class); // Returns false!

What we've achieved so far seems like a lot of overhead for what we could have achieved using instanceof , and it is; but the benefit will soon be apparent when we move onto more complex relationships, which fundamentally rely upon the same architecture.

Another requirement of our design is that for given instances, we'd like to query their instance members to determine the validity of an ILiason . To achieve this, we define a second implementor of ILiason , the Intuition .

What we've achieved so far seems like a lot of overhead for what we could have achieved using instanceof , and it is; but the benefit will soon be apparent when we move onto more complex relationships, which fundamentally rely upon the same architecture.

Another requirement of our design is that for given instances, we'd like to query their instance members to determine the validity of an ILiason . To achieve this, we define a second implementor of ILiason , the Intuition .

/* A ILiason which uses informed knowledge of a type to determine the state of a ILiason. */ public static abstract class Intuition<A, B> implements ILiason<A, Class<?>> { /*** TODO: to B **/ /* First, we determine if Alice is an instance of Bob. */ /** TODO: We suppress the unchecked type cast, however Assignable guarantees us the check. **/ @Override @SuppressWarnings("unchecked") public final boolean isLiason(final A pAlice) { /* Determine if we can use intuitive processing via an Assignable. If we can't, return the default result. */ return (new ILiason.Assignable.Impl<A>(this.getBob()).isLiason(pAlice) ? this.onSupplyIntuition((B)pAlice) : false); } /* Defines concrete methodology towards handling alice in a class-specific manner. */ public abstract boolean onSupplyIntuition(final B pA); }; `

In Intuition , we see that to compute the status of the Liason we first test for assignability using an ILiason.Assignable ; if this is achieved, we're able to safelty type cast Alice to the assignable type and allow concrete implementors to define a more intimate analysis of the instance via onSupplyIntuition . Below, we use this to examine the NumberOfTeaspoons of IIngredient.Sugar :

new ILiason.Intuition<IIngredient, Sugar>() { /* Define the Number of Teaspoons of Sugar expected for a Mojito. (I made this up, it's probably a lot more.) */ @Override public final boolean onSupplyIntuition(final Sugar pSugar) { return (pSugar.getNumberOfTeaSpoons() == 2); } /* Define the Searchable class reference. */ @Override public final Class<Sugar> getBob() { return Sugar.class; } }; } }

With these definitions, we're able to define both generic and informed analysis of Collections, and use their results to infer specific combinations of classes. For example, the presence of a given ILiason within an individual array index may be found using the ILiason.Element :

/* Determines whether a particular Liason is present within a specified Array, Alice. */ public static abstract class Element<A, B> implements ILiason<A[], ILiason<A, B>> { /* Here we iterate through the entire specification of Alice in search of a matching Liason. */ @Override public final boolean isLiason(final A[] pAlice) { /* Define the Search Metric. */ boolean lIsSupported = false; /* Iterate Alice. */ for(int i = 0; i < pAlice.length && !lIsSupported; i++) { /* Fetch Alice at this index. */ final A lAlice = pAlice[i]; /* Update the Search metric using Alice's Liason with Bob. */ lIsSupported |= this.getBob().isLiason(lAlice); } /* Return the Search Metric. */ return lIsSupported; } };

Using a similar approach, the applicability of an array of ILiason s to a given Alice may be processed using a ILiason.Cohort . The order in which ILiasons are defined in the call to getBob() also defines priority:

/* Compares an array of Alice against an array of Liasons. Determines whether all Liasons are fully met. */ public static abstract class Cohort<A, B> implements ILiason<A[], ILiason<A[], B>[]> { /* Iterates the array of Alice and returns true if all Liasons within the cohort are supported. */ @Override public final boolean isLiason(final A[] pAlice) { /* Define the Search Metric. */ boolean lIsValid = true; /* Fetch the associated Liasons. */ final ILiason<A[], B>[] lLiasons = this.getBob(); /* Iterate the Liasons whilst the delegation is Valid. */ for(int i = 0; i < lLiasons.length && lIsValid; i++) { /* Fetch the Liason. */ final ILiason<A[], B> lLiason = lLiasons[i]; /* Update the search metric. */ lIsValid &= lLiason.isLiason(pAlice); } /* Return the search metric. */ return lIsValid; } };

Using these tools, we're able to define different Cocktail s as follows: :

/* Define the Martini Specification. */ private static final ILiason.Cohort<IIngredient, Class<?>> LIASON_COHORT_COCKTAIL_MARTINI = new ILiason.Cohort<IIngredient, Class<?>>() { @SuppressWarnings("unchecked") @Override public final ILiason<IIngredient[], Class<?>>[] getBob() { return ((ILiason<IIngredient[], Class<?>>[]) new ILiason<?, ?>[] { /* Define the Dry-Gin. */ new ILiason.Element<IIngredient, Class<?>>() { @Override public final ILiason<IIngredient, Class<?>> getBob() { return new ILiason.Assignable<IIngredient>() { @Override public Class<?> getBob() { return Gin.class; } }; } }, new ILiason.Element<IIngredient, Class<?>>() { @Override public final ILiason<IIngredient, Class<?>> getBob() { return new ILiason.Assignable<IIngredient>() { @Override public Class<?> getBob() { return Vermouth.class; } }; } }, new ILiason.Element<IIngredient, Class<?>>() { @Override public final ILiason<IIngredient, Class<?>> getBob() { return new ILiason.Assignable<IIngredient>() { @Override public Class<?> getBob() { return Orange.class; } }; } }, }); } }; private static final ILiason.Cohort<IIngredient, Class<?>> LIASON_COHORT_COCKTAIL_MARTINI = new ILiason.Cohort<IIngredient, Class<?>>() { @SuppressWarnings("unchecked") @Override public final ILiason<IIngredient[], Class<?>>[] getBob() { return ((ILiason<IIngredient[], Class<?>>[]) new ILiason<?, ?>[] { /* Define the Dry-Gin. */ new ILiason.Element<IIngredient, Class<?>>() { @Override public final ILiason<IIngredient, Class<?>> getBob() { return new ILiason.Assignable<IIngredient>() { @Override public Class<?> getBob() { return Gin.class; } }; } }, new ILiason.Element<IIngredient, Class<?>>() { @Override public final ILiason<IIngredient, Class<?>> getBob() { return new ILiason.Assignable<IIngredient>() { @Override public Class<?> getBob() { return Vermouth.class; } }; } }, new ILiason.Element<IIngredient, Class<?>>() { @Override public final ILiason<IIngredient, Class<?>> getBob() { return new ILiason.Assignable<IIngredient>() { @Override public Class<?> getBob() { return Orange.class; } }; } }, }); } };

Then, with a simple call to an LIASON_COHORT_COCKTAIL_MARTINI 's isLiason(final IIngredient[] pAlice) method, we're able to test for the existence of appropriate data members in our array of IIngredient s.

And there you have it! Statically defined pattern definitions which may implement arbitrary comparison functionality.

Drawbacks -- There's a pretty large coding overhead in creating new ILiason definitions. With all of the flexibility the pattern buys us, it doesn't quite measure up in simplicity. -- It's quite likely slow. Most of the comparisons implemented here are 2D array searches for every single ILiason type. instanceof might be the more preferable choice in simple cases. -- It's possible that there's an overlapping of responsibilities in ILiason definitions. Luckily, the core ILiason types are ILiason s themselves, and can often be nested in an effort improve code cohesion.