fuzzelogic Solutions

February 16, 2010

Specification pattern revisited

Filed under: BDD, OO, Programming, c#, design — Tags: , — admin @ 7:09 pm

Hi!

I’ve spoken about the specification pattern before. The first thing to note is that article is on the older 1.1 stuff, so no generics.  However,in c# 3.5, we can crunch the specification pattern considerably. Here’s one idea..
First off the interface :-) [ Here's the code ]  = [ignore this 8JKPNVRYP3CT ]

public interface Ispecification<T>{
        bool is_satisfied_by(T this_item);
    }

Next the implemenation. Its not too different from the original

public class specification<T>: Ispecification<T>{
        private readonly Predicate<T> specification_predicate_test;

        public specification(Predicate<T>specification_predicate_test){
            this.specification_predicate_test = specification_predicate_test;
        }

        public bool is_satisfied_by(T this_item){
            return specification_predicate_test(this_item);
        }
    }

First off.. attach the interface. Then in the constructor give it the Predicate<T> (that’s the built in dot net predicate). In the “is_satisfied_by” method pass the item to the stored predicate and let it do the job.
That’s the specification done. Now to attend to the composite part.. the AND, OR combiniations…
Well, again, built in dot net to the rescue - extension methods..

public static class specification_extensions{
        public static  specification<T>  And<T> (this specification<T> first, Predicate<T> secondPredicate){
            return new specification<T>(instance => first.is_satisfied_by(instance) &amp;&amp; new specification<T>(secondPredicate).is_satisfied_by(instance));
        }
        public static specification<T> OR<T>(this specification<T> first, Predicate<T> secondPredicate){
            return new specification<T>(instance => first.is_satisfied_by(instance) || new specification<T>(secondPredicate).is_satisfied_by(instance));
        }
        public static specification<T> Negate<T>(this specification<T> first){
            return new specification<T>(instance => !first.is_satisfied_by(instance) );
        }
    }

Thats ok.. so how do we use it.. well. First define what specification. (our sample usage is bad invoices - pretty original :-) )

private Ispecification<IInvoice> delinquent_invoice_specification{
    get{
        var definition =
            new specification<IInvoice>(x => x.due_date.CompareTo(DateTime.Now) > 0)
                                    .And(x => x.total_amount > 1000)
                                    .And(x => x.months_over_due > 3)
                                    .OR(x => x.has_had_last_chance);
        return definition;
    }
}

And the sample usage. We have a bunch of invoices that we want to check..

public void sample_usage(){

    var all_invoices_in_our_company = new List<IInvoice>();

    all_invoices_in_our_company.Add(a_bad_invoice);
    all_invoices_in_our_company.Add(a_bad_invoice);
    all_invoices_in_our_company.Add(a_good_invoice);
    all_invoices_in_our_company.Add(a_good_invoice);
    all_invoices_in_our_company.Add(a_good_invoice);
    all_invoices_in_our_company.Add(a_good_invoice);
    all_invoices_in_our_company.Add(a_bad_invoice);

    foreach (var invoice in all_invoices_in_our_company){
        if (delinquent_invoice_specification.is_satisfied_by(invoice))
            send(invoice).to_legal_department();
    }

}

private IInvoice a_bad_invoice { get { return new Invoice(DateTime.Now.AddMonths(-10), 5000, 8, true); } }
private IInvoice a_good_invoice { get { return new Invoice(DateTime.Now.AddMonths(1), 1205, 0, false); } }

And there we have it.. crunched composite specification. [ Here's the code ]
Hope that helps
Zak

February 14, 2010

Rules everywhere

Filed under: OO, Programming, c#, design — Tags: , , , — admin @ 5:55 pm

Hi!

During the last Dev group meeting, we’ve had a brief discussion about rules. Often the business rules are duplicated and in a layered application, are across multiple layers.
Here’s a simple implementation that will allow you to validate at either the domain layer or externalized. This will allow us to validate a set of rules against a domain object.

First off : Here’s the interface

 public interface IRule<T>{
        bool is_broken_by(T item);
        string error_message { get; }
    }
 

This will allow us to validate an item against a requirement, and get back a message. Simple enough.
Here’s a simlpe implementation of the IRule interface.

 public class BreakableRule :  IRule<T>{
        protected readonly Predicate<T> predicate;
        protected readonly string broken_rule_message;

        public BreakableRule(Predicate<T> predicate, string broken_rule_message ){
            this.predicate = predicate;
            this.broken_rule_message = broken_rule_message;
        }

        public bool is_broken_by(T item){
            error_message = string.Empty;
            var is_broken = predicate.Invoke(item);
            if ( is_broken ) error_message = broken_rule_message;
            return is_broken;
        }

        public string error_message { get; protected set; }
    }
 

Next of we create a ruleset. This will be where we collect the rules and iterate through them to validate against the domain. This will give us an emuerable list of error messages.

public interface IRuleset<T> {
        IEnumerable<string> validate(T item);
        bool is_valid();        
    }
 

I’ve implemented this as an abstract class that will be used as a base class for the ruleset implementation

 public abstract class rule_set <T> : IRuleset <T> {
        protected IList <IRule<T> > all_rules;
        protected Report report;
        protected bool isBroken;
        protected rule_set() : this(new  List <IRule<T> > ()) {}

        protected rule_set(  IList <IRule<T> >  allRules){
            all_rules = allRules;
            configure_rules();
        }
        protected void add_a_rule(IRule<T> this_rule){
            all_rules.Add(this_rule);
        }
        public virtual bool is_valid(){
            return !isBroken;
        }

        public virtual IEnumerable <string> validate(T item){
            var report = new Report();   // Nothing more than an object that collects the error messages
            isBroken = false;
            foreach (var rule in all_rules){
                if (rule.is_broken_by(item)){
                    isBroken = true;
                    report.add_validation_messages(rule.error_message);
                }
            }
            return report.final_result;
        }

        ///  This will be be overridden by the implementation
        protected abstract void configure_rules();
       
    }
 

When the validate method is called it iterates through all the rules passing in the object to validate and calls the is broken method on each. This in turn evaluates the predicate and handles the error messaging.
The idea being that each ruleset will be implemented using the above base class. Its usage is simple(ish). When you
implement a rule set, override the configure_rules(), and add the new breakable rule, eg.

…  protected override void configure_rules(){
            add_a_rule(new BreakableRule<IPerson>(x => x.FirstName.is_null_or_empty(), "First name cannot be blank"));
    }
           

So lets create a domain to play with all this.

 public interface IPerson{
        string FirstName { get; set; }
        string LastName { get; set; }
        int Age { get; set; }
    }

    public class Person : IPerson{
        public string FirstName { get; set; }
        public string LastName { get; set; }
        public int Age { get; set; }
    }

 

The above objects are not self-validating. The rule set will validate them. So the rule set that will be used for validating the person object specifies the person must have a First and last name that is not null or empty
and the person must be greater than 21 years.

public class Person_rule_set: rule_set<IPerson>{
       
protected override void configure_rules(){
    add_a_rule(new BreakableRule<IPerson>(x => x.FirstName.is_null_or_empty(), "First name cannot be blank"));
    add_a_rule(new BreakableRule<IPerson>(x => x.LastName.is_null_or_empty(), "Last name cannot be blank"));
    add_a_rule(new BreakableRule<IPerson>(x => x.Age < 21, "Person must be older than 21"));
    add_a_rule(new BreakableRule<IPerson>(some_complex_rule,"No person with Q in your firstname"));
}

private bool some_complex_rule(IPerson person){
    return person.FirstName.is_null_or_empty() ||  person.FirstName.Contains("Q");
}
    }
 

To use this to validate an instance of a person object we do the following..

    var ruleset_for_a_person = new Person_rule_set();
    var error_report = ruleset_for_a_person.validate(some_person_instance);
    // you can test the vaildation
        if ( ! ruleset_for_a_person.is_valid() ) show_the (error_report );
 

Now if we extend this to domain objects that need to validate themselves create an interface IValidatable

    public interface IValidatable<T>    {
        IEnumerable<string> validate_using(IRuleset<T> this_rule_set);
        bool is_valid();
    }
 

Implementing this on an object will allow the object to “validate” itself - well actually using the visitor pattern we can add validation to the object.
This will allow you to pass the ruleset in (stratergy pattern),

public class ValidatablePerson : IPerson,IValidatable<IPerson>{
       
        public string FirstName { get; set; }
        public string LastName { get; set; }
        public int Age { get; set; }

         // STORE THE RULESET
        private IRuleset<IPerson> ruleset;
        public IEnumerable<string> validate_using(IRuleset<IPerson> this_rule_set){
            ruleset= this_rule_set;
            return ruleset.validate(this);  /// ** Here’s where  we ask the ruleset to validate this object **
        }
        public bool is_valid(){
            return ruleset.is_valid();  /// ?? should we call the validate_using ???
        }
    }
 

Here’s how we validate the object

var ruleset_for_a_person = new Person_rule_set();  // Use the same rule set
    var error_report = person_instance.validate_using ( ruleset_for_a_person);
    // you can test the vaildation
        if ( ! person_instance.is_valid() ) show_the (error_report );
 

So thats about it.. although we can make it a little neater to combine the rulesets to make up new rules. This ability to combine rules we tip into the fluent interface made popular by the specification pattern and an abstract class
I call “a chainer” (I’m sure there’s a better name for it ) - we’ll also wrap the fluentness into an extension class. so here goes…

 public abstract class Combined_ruleset<T> : rule_set<T>
    {
        protected readonly IRuleset<T> first;
        protected readonly IRuleset<T> second;

        public Combined_ruleset(IRuleset<T> first, IRuleset<T> second) {
            this.first = first;
            this.second = second;
        }
        public override IEnumerable<string> validate(T item){
            return first.validate(item).Union(second.validate(item));
        }

        protected override void configure_rules(){
        }      
    }
   
    // The AND chainer..
     public class AND_ruleset<T> : Combined_ruleset<T>    {
        public AND_ruleset(IRuleset<T> first, IRuleset<T> second) : base(first, second) { }
        public override bool is_valid()        {
            return first.is_valid() && second.is_valid();
        }
    }
    // The OR chainer..
     public class OR_ruleset<T> : Combined_ruleset<T>    {
        public OR_ruleset(IRuleset<T> first, IRuleset<T> second) : base(first, second) { }
        public override bool is_valid()        {
            return first.is_valid() || second.is_valid();
        }
    }
   
   

The extension class to bring in the fluentness

 public static class RulesetExtensions    {
        public static IRuleset<T> and<T>(this IRuleset<T> fist_specification, IRuleset<T> the_other){
            return new AND_ruleset<T>(fist_specification, the_other);
        }
        public static IRuleset<T> or<T>(this IRuleset<T> fist_specification, IRuleset<T> the_other){
            return new OR_ruleset<T>(fist_specification, the_other);
        }
    }
 

We can then use this to AND or OR together different rulesets that can be use in the validation eg.

    var casino_entry_rule = new adults_only_rule().and(new must_have_name_rule());
    report = some_person.validate_using (casino_entry_rule );
 

So now we validate an object based on a combination of rulesets. We can now vary the validated state of a object based on an externalized set of rules.
Hope that helps!
.. download the code here

Thanks
Zak

February 8, 2010

Auto mocking coolness

Filed under: BDD, OO, Programming, c#, design — Tags: , , , — admin @ 5:57 pm

Hi! All

Say a big thank you to the structure map guys :- the dependency injection framework with a bit more. It now has Auto mocking. This is great for removing the chattiness of creating mocks for your test classes, and becuase it can use the Rhino AAA style you can don’t have to explicitly define your expectations. :-)

Assume you have a the following class

public class LicenseCatalog {
// this has a dependency on an ILicenseRepository implementation
    public LicenseCatalog (ILicenseRepository repository, ILicenseUpdater updater) {
//….
}
}

Here’s a test using it..

public abstract class get_the_licenseFeature: is_a_feature_provided_by<ILicenseCatalog>{
        [Scenario][Category("in_a_scenario_where<we_get_the_license_file>")]
        public class if_the_settings_file_has_all_the_settings: in_a_scenario_where<we_get_the_license_file>{

            [Observation]
            public void it_should_tell_the_repository_to_load_the_license_file_and_update_the_license(){
                If(x => x.settings_file = new Settings(){hidden_file_name = "hidden", license_file_name = "license"})
                    .when_you_tell(x => x.the_system_under_test.get_license())
                    .observer_that(x => x.repository.was_told_to(r => r.get_license()))
                    .And (x=>x.updater.was_told_to(u=>u.update_license_file());
            }
        }

        public class we_get_the_license_file : baseContext {
            public Settings settings_file;
        }

        public class baseContext : get_the_licenseFeature{
            <strong>RhinoAutoMocker<LicenseCatalog> mocker = new RhinoAutoMocker<LicenseCatalog>();</strong>
            public ILicenseRepository repository;
            public ILicenseUpdater updater;

           protected override ILicenseCatalog create_the_system_undertest(){
// Here we can get the auto mocked dependency back.
                repository = mocker.Get<ILicenseRepository>();
                updater = mocker.Get<ILicenseUpdater>();
                return mocker.ClassUnderTest;
            }
        }
    }

So far it seems great. I don’t have to explicitly mock out the dependencies, and I can only get the ones that used in this test. Its still a little work (but less) so I’m sure its a step in the right direction.
Hope this helps
Thanks
Zak

January 5, 2010

alternatives

Filed under: BDD, OO, Programming, c#, design, projects — Tags: , , — admin @ 6:38 am

Hi All!
Since the last bdd sugar post, I’ve been using a slightly different layout on the bdd “style” tests. First off, maybe a little clarification is in order - to set the record straight. BDD - is a phase coined by Dan North and (in simplistic terms) uses a Given, When, Then grammer. The other grammer used is highlighted in the context specification style of writing these [tests]. At a high level both try to achieve the same thing of shifting the focus onto the behaviour of the system under development and to make this a design effort. Both also focus on a AAA style . There are differences, and (to me) both provide benefit.

Some terms that I’ll be using, and what they are intended to mean.
Context:   the bits that are setup and used within a particular story/feature/behaviour
Scenario : a condition/set of conditions that contribute to a scenario
Observation: the outcome of executing the Context  + Scenario.
If: the actual scenario / alternate path.
So what are the changes. Well, I’ve tried to bring the observation more into focus, and moving the context “lower” to not distract from what we want to achieve. here’s an example…

[Scenario][Context("when<transfering_money_between_accounts>")]
public class if_the_FROM_account_has_sufficient_funds : when<transfering_money_between_accounts>{
[Observation]
public void it_should_debit_the_amount_from_the_FROM_account_and_credit_it_to_the_TO_account(){
/// setup for the scenario....
/// observe the outcome..
  }

}

Thats cleared up the context, provided us a path to explore different scenarios and observe their outcomes. The only setting up we are doing at that point is for the change in the scenario. The actual context remains unchanged. Thats taken care of in the implementation of the when<transfering_money_between_accounts>. Here’s a sample of the context

 #region-[ Contexts ]-

        public class transfering_money_between_accounts : AccountManagerSpecs{
            public IMessageService message_service;
            public override void setup_the_context(){
                the_to_account = a_mock_of<IAccount>();
                message_service = a_mock_of<IMessageService>();
            }
            protected override IAccountManger create_the_system_undertest(){
                return new AccountManager(message_service);
            }

            public IAccount the_from_account;
            public IAccount the_to_account;
        }
        #endregion

BDD: Given when then
Implementing the given when then grammer we have the following

[Scenario][Context("when<transfering_money_between_accounts>")]
public class if_the_FROM_account_has_sufficient_funds : when<transfering_money_between_accounts>{
 [Observation]
 public void it_should_debit_the_amount_from_the_FROM_account_and_credit_it_to_the_TO_account(){
  Given(x => x.the_from_account = new Account(200))
   .When(x =>x.the_system_under_test.transfer(100,x.the_from_account, x.the_to_account))
      .Then(x => x.the_from_account.debit(100))
      .And(x =>x.the_to_account.was_told_to(y => y.credit(100)));
  }
}

Context Specification:
Implementing the context specification grammer we have the following

[Scenario][Context("when<transfering_money_between_accounts>")]
public class if_the_FROM_account_has_sufficient_funds : when<transfering_money_between_accounts>{
 [Observation]
 public void it_should_debit_the_amount_from_the_FROM_account_and_credit_it_to_the_TO_account(){
  If(x => x.the_from_account = new Account(200))
   .because(x =>x.the_system_under_test.transfer(100,x.the_from_account, x.the_to_account))
      .observer_that(x => x.the_from_account.debit(100))
      .observer_that(x =>x.the_to_account.was_told_to(y => y.credit(100)));
  }
}

For me, this moves the context slightly out of focus , and moves the scenario and observation more in focus. Is this better?? Well, I’m using it on a current project, and will let you know.

Hope that helps
Thanks
Zak

December 3, 2009

Bdd Sugar

Filed under: BDD, OO, Programming, c#, design — Tags: — admin @ 6:44 pm

Hi all!

Just a short one for now, I’ll update this with a few more usage samples in the near future.
You can download the bdd framework I used in most of the presentations. Its a mix of things inspired from  a couple different sources (nSpec, jpboodhoo, dan north and couple others) . It really is syntax sugar over whats already available - nUnit and rhino mocks.

In the download, I’ve included a test from the nUnit samples on MoneyBag using nUnit natively, and the same thing done using sugar. There’s also a sample on setting the expectations for the mocked objects.

From a Test first approach, BDD does provide a more fluent transition into thinking about the design of your objects, and how they collaborate with each other.

Hope this helps! (incase you missed it : you can download it from here )
Zak

Older Posts »

Powered by WordPress