工厂模式很多参数需要提示

Question

I'm designing a small "Rule Engine" solution. Basic idea of module is that it checks whether received user interactions satisfy some rules and if yes then gives them bonus points. In short, there is a collection of List<IRule> interfaces, when user interacts with system, let's say buys stuff, I iterate to all IRule -s and check if bool Execute(ITransactionContext context) returns true. Here's IRule interface

public interface IRule
{
    bool Execute(IContext context);
}

And the problem is that concrete Rule : IRule classes differ from each other, have different parameters and meanings. Eg

• AmountRule has Min, Max properties
• DatePeriodRule has From and To parameters

• EqualsRule has CheckProperty and ExpectedValue parameters and so on... These are very basic and simple rules, there may be exist more complicated rule.

   public class AmountRule : IRule { private decimal _min; private decimal _max; public bool Execute(IContext context) { return context.Amount >= _min && context.Amount <= _max; } } public class DatePeriodRule : IRule { private DateTime _from; private DateTime _to; public bool Execute(IContext context) { return context.ProcessDate >= _from && context.ProcessDate <= _to; } } 

So creating rules is not an easy task and I decided to use the Factory Pattern (or any pattern related to it, don't mind if it's an Abstract Factory , Factory Method or Builder ) and have an interface IRuleFactory which is responsible for creating any kind of IRule implementation class.

public interface IRuleFactory
{
    IRule Create(RuleType type);
}

I face real problem here because of the parameter variety for concrete implementations of IRule . Eg If I want to create AmountRule then my RuleFactory needs MinAmount, MaxAmount params, If DatePeriodRule it needs From, To params and so on...

I'm looking for some good approaches to solve this problem. Is Factory just an extra headache here?

Answer 1

It's ok for your Factory to create specific types that implement an interface but have constructors with different parameters. That's exactly the type of abstraction it's meant for. So your Create method could look something like the following:

IRule Create(RuleType type){
    if(type == RuleType.ValidAmount){
        return new ValidAmountRule(10, 20);
    }
    else{
        return new OtherKindOfRule("some other param");
    }
}

Of course it's assumed here that your Factory knows what the parameters for the constructors should be. If this is only known by the client of the Create method, then I would say the indirection isn't necessary and the client should construct the rule itself. The RuleType parameter is a bit suspicious in that the caller obviously has to know something about the IRule it wants. If there is a one to one mapping between RuleType and a concrete type to be constructed then this is certainly needless complexity unless the caller just doesn't have the information it needs to construct the rule directly.

In general, the point of a rules engine is to reduce complexity by removing a bunch of complicated if/else statements and encapsulating rules so they can be managed in isolation and possibly configured outside a code deployment. Your concrete rules have to get the information they need to apply their logic from some combination of the constructor of the object and the caller of the object. What can't be known in the object constructor has to be passed to your Execute method. That means that the parameter in your IRule interface should be a high-level object that contains a lot of information that some of your rules may not even need.

Answer 2

I have actually implemented a RulesEngine called Ariadne so I speak from experience here. Your dilemma comes from the fact that you have varying operand types and they have to line up. After all, you can't ask

is 'foo' > 10

that expression is invalid because foo is a string and 10 is a number. Similarly, you can't ask if

Weight > 15lbs

Because computers don't know what 'Weight' is or what '15 lbs' is.

You have to manage this with a variety of patterns and well thought design.

The design architecture of Ariadne (and you are welcome to try to take some liberties) was this: You have

• Operations (Predicates, Equations, etc.)
• Operators ( plus, minus, divide, etc). (Ariadne, for simplicity sake does binary ops)
• OperandOwners (These are objects that extract a numeric value from 'Weight' so you can do things like 'Weight > 10'.
• All implementations of the above are entirely stateless. Gathering whatever information they needed from the call context.

Your first problem is to keep all the Operations, Operators and OperandOwners in the same KnowledgeBase -- This is crucial for running more than 1 in your app. The way I did this was with a AbstractFactory pattern .

In this example you can see:

KnowledgeBase kb = KnowledgeBase.getInstance();

Is how I control these 3 pieces. If you try to manage an operator/operand/operandowner they all go through this knowledgbase because you have to call it's functions

You also need to be able to funnel the creation of rules into your methods .

public Predicate getPredicate(OperandOwner lho, String op, OperandOwner rho) throws AriadneException {
    return operationFact.getPredicate(lho, op, rho);
}

This is a registration process that allows for the reuse of common objects through use of the Flyweight pattern and in addition, it is a Factory method for producing predicates.

All this is well and good, but really, you want to be able to combine rules arbitrarily. To do this you need to continue to combine them but expose them as a single rule. This many as one pattern is the composite pattern. Consider:

• is today tuesday ?
• is it raining ?
• is my weight > 10lbs

You have 3 separate predicates that can be combined. And in any combination of 'and' or 'or' you still have a predicate. You must be able to represent many combined predicates as one.

For an example of how this works look here

Bottom line: A robust implementation will be:

1. Memory efficient. Rules are bound to be endless
2. Stateless. Side-effects can bring the whole thing down
3. Open for extension (Ariadne allows/encourages you to roll your own operators/operand owners)
4. closed for modification
5. Next to impossible to get rule creation wrong.

To this end you have:

• Flyweight
• Composite
• Abstract Factory
• Factory Method

Good luck

Answer 3

I would apply prototype pattern to register rules. If all rules you anticipate to have are stateless you even can do without cloning.