{"id":854,"date":"2009-08-24T11:43:58","date_gmt":"2009-08-24T09:43:58","guid":{"rendered":"http:\/\/www.navision-blog.de\/2009\/08\/24\/the-openclosed-principle-c-vs-f\/"},"modified":"2009-09-01T11:46:32","modified_gmt":"2009-09-01T09:46:32","slug":"the-openclosed-principle-c-vs-f","status":"publish","type":"post","link":"http:\/\/www.navision-blog.de\/blog\/2009\/08\/24\/the-openclosed-principle-c-vs-f\/","title":{"rendered":"SOLID Part I – The Open\/Closed-Principle – C# vs. F#"},"content":{"rendered":"

Friday I attended the .NET BootCamp \u201cNHibernate vs. Entity Framework\u201d<\/a> in Leipzig and as always it was a pleasure for me being there. Afterwards I had a nice talk with my friend Alexander Groß<\/a> about the Open\/Closed Principle<\/a>. I didn\u2019t really care about this principle before, but now I think it\u2019s really a nice idea:<\/p>\n

\n

\u201cIn object-oriented programming, the open\/closed principle<\/strong> states "software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification"; that is, such an entity can allow its behaviour to be modified without altering its source code.\u201d<\/p>\n

[Wikipedia<\/a>]<\/p>\n<\/blockquote>\n

If we follow this principle we get lot\u2019s of small and testable classes. I want to demonstrate this with a simple spam checker for mails.<\/p>\n

Let\u2019s say our mail class has only a sender, a recipient, a subject and the mail body:<\/p>\n

\n

public<\/span> class<\/span> EMail<\/span><\/p>\n

{<\/p>\n

    public<\/span> string<\/span> Sender { get<\/span>; set<\/span>; }<\/p>\n

    <\/span>public<\/span> string<\/span> Recipient { get<\/span>; set<\/span>; }<\/p>\n

    <\/span>public<\/span> string<\/span> Subject { get<\/span>; set<\/span>; }<\/p>\n

    <\/span>public<\/span> string<\/span> Body { get<\/span>; set<\/span>; }<\/p>\n

 <\/p>\n

\n

    <\/span>public<\/span> EMail(string<\/span> sender, string<\/span> recipient,<\/p>\n

        <\/span>string <\/span>subject, string<\/span> body)<\/p>\n

    <\/span>{<\/p>\n

    <\/span>    <\/span>Sender = sender;<\/p>\n

    <\/span>    <\/span>Recipient = recipient;<\/p>\n

    <\/span>    <\/span>Subject = subject;<\/p>\n

    <\/span>    <\/span>Body = body;<\/p>\n

    <\/span>}<\/p>\n

}<\/p>\n

 <\/p>\n

\n

public<\/span> enum<\/span> SpamResult<\/span><\/p>\n

{<\/p>\n

    <\/span>Spam,<\/p>\n

    <\/span>Ok,<\/p>\n

    <\/span>Unknown<\/p>\n

}<\/p>\n

\n<\/p><\/div>\n

Now we want to know if a mail is spam or not. Of course we need some rules and some kind of \u201crule checker\u201d to decide this. Here is a very na\u00efve implementation for this:<\/p>\n

\n

public<\/span> class<\/span> RuleChecker<\/span><\/p>\n

{<\/p>\n

    <\/span>public<\/span> SpamResult<\/span> CheckMail(EMail<\/span> mail)<\/p>\n

    <\/span>{<\/p>\n

        <\/span>var<\/span> result = TestRule1(mail);<\/p>\n

        <\/span>if<\/span>(result != SpamResult<\/span>.Unknown)<\/p>\n

            <\/span>return<\/span> result;<\/p>\n

 <\/p>\n

\n

        <\/span>result = TestRule2(mail);<\/p>\n

        <\/span>if<\/span> (result != SpamResult<\/span>.Unknown)<\/p>\n

        <\/span>return<\/span> result;<\/p>\n

 <\/p>\n

\n

        <\/span>\/\/ …<\/span><\/p>\n

\n

        <\/span>return<\/span> SpamResult<\/span>.Unknown;<\/p>\n

\n

    <\/span>}<\/p>\n

 <\/p>\n

\n

    <\/span>private<\/span> SpamResult<\/span> TestRule1(EMail<\/span> mail)<\/p>\n

    <\/span>{<\/p>\n

        <\/span>\/\/ I don\u2019t care about the concrete rules <\/span><\/p>\n

    <\/span>}<\/p>\n

 <\/p>\n

\n

    <\/span>private<\/span> SpamResult<\/span> TestRule2(EMail<\/span> mail)<\/p>\n

    <\/span>{<\/p>\n

        <\/span>\/\/ I don\u2019t care about the concrete rules<\/span><\/p>\n

    <\/span>}<\/p>\n

}<\/p>\n<\/p><\/div>\n

It is obvious that this implementation breaks the Open\/Closed Principle. Every time someone comes up with a new anti-spam rule or the rule priorities change I have to modify the code in CheckMail(). Another problem here is that I can\u2019t test CheckMail() isolated from the concrete rules.<\/p>\n

With the help of the Open\/Closed Principle our implementation could look like this:<\/p>\n

\n

<\/span><\/p>\n

public<\/span> interface<\/span> ISpamRule<\/span><\/p>\n

{<\/p>\n

    <\/span>SpamResult<\/span> CheckMail(EMail<\/span> mail);<\/p>\n

}<\/p>\n

 <\/p>\n

\n

public<\/span> class<\/span> RuleChecker<\/span><\/p>\n

{<\/p>\n

    <\/span>private<\/span> readonly<\/span> IEnumerable<\/span><ISpamRule<\/span>> _rules;<\/p>\n

 <\/p>\n

\n

    <\/span>public<\/span> RuleChecker(IEnumerable<\/span><ISpamRule<\/span>> rules)<\/p>\n

    <\/span>{<\/p>\n

    <\/span>    _rules = rules;<\/p>\n

    <\/span>}<\/p>\n

 <\/p>\n

\n

    <\/span>public<\/span> SpamResult<\/span> CheckMail(EMail<\/span> mail)<\/p>\n

    <\/span>{<\/p>\n

        <\/span>foreach<\/span> (var<\/span> rule in<\/span> _rules)<\/p>\n

    <\/span>    {<\/p>\n

            <\/span>var<\/span> result = rule.CheckMail(mail);<\/p>\n

            <\/span>if<\/span> (result != SpamResult<\/span>.Unknown)<\/p>\n

                <\/span>return<\/span> result;<\/p>\n

    <\/span>    }<\/p>\n

        <\/span>return<\/span> SpamResult<\/span>.Unknown;<\/p>\n

    <\/span>}<\/p>\n

}<\/p>\n<\/p><\/div>\n

Now you could easily write isolated UnitTests for RuleChecker.CheckMail() and for every new rule.<\/p>\n

You get the your concrete RuleChecker by calling the constructor with a list of rules:<\/p>\n

\n

class<\/span> MyFirstRule<\/span> : ISpamRule<\/span><\/p>\n

{<\/p>\n

    <\/span>public<\/span> SpamResult<\/span> CheckMail(EMail<\/span> mail)<\/p>\n

    <\/span>{<\/p>\n

        \/\/ I don’t care about this<\/span><\/p>\n

    <\/span>}<\/p>\n

}<\/p>\n

 <\/p>\n

\n

class<\/span> MySecondRule<\/span> : ISpamRule<\/span><\/p>\n

{<\/p>\n

    <\/span>public<\/span> SpamResult<\/span> CheckMail(EMail<\/span> mail)<\/p>\n

    <\/span>{<\/p>\n

        <\/span>\/\/ I don’t care about this<\/span><\/p>\n

    <\/span>}<\/p>\n

}<\/p>\n

\n

\/\/ …<\/span><\/p>\n

<\/span><\/p>\n<\/p><\/div>\n

\n

<\/span><\/p>\n

var<\/span> ruleChecker =<\/p>\n

    <\/span>new<\/span> RuleChecker<\/span>(<\/p>\n

        <\/span>new<\/span> List<\/span><ISpamRule<\/span>><\/p>\n

    <\/span>    {<\/p>\n

            <\/span>new<\/span> MyFirstRule<\/span>(),<\/p>\n

            new<\/span> MySecondRule<\/span>(),<\/p>\n

            \/\/ …<\/span><\/p>\n

        });<\/p>\n<\/p><\/div>\n

Alex please correct me if I\u2019m wrong, but I think this is what you had in mind Friday.<\/p>\n

As stated before, we end up writing lot\u2019s of very small classes – mostly with only one (public) method. I think this is some kind of functional approach, the only question is how we glue our code entities together. Let\u2019s look at the corresponding F# implementation:<\/p>\n

\n

type<\/span> EMail =<\/p>\n

  { Sender: string;<\/p>\n

    Recipient: string;<\/p>\n

    Subject: string;<\/p>\n

    Body: string}<\/p>\n

 <\/p>\n

\n

type<\/span> SpamResult =<\/p>\n

  | Spam<\/p>\n

  | OK<\/p>\n

  | Unknown<\/p>\n

 <\/p>\n

\n

let<\/span> checkMail rules (mail:EMail) =<\/p>\n

  let<\/span> rec<\/span> checkRule rules =<\/p>\n

    match<\/span> rules with<\/span><\/p>\n

    | rule::rest -><\/span><\/p>\n

      match<\/span> rule mail with<\/span><\/p>\n

      | Unknown -><\/span> checkRule rest<\/p>\n

      | _ as<\/span> other -><\/span> other<\/p>\n

    | [] \u2013><\/span> Unknown<\/p>\n

 <\/p>\n

\n

  checkRule rules<\/p>\n<\/p><\/div>\n

The signature of checkMail is (EMail -> SpamResult) list -> EMail \u2013> SpamResult<\/strong>, which means it takes a list of rules (as above the order is important) and a EMail and returns the SpamResult. In addition I exchanged the explicit foreach loop with a tail recursion to make it look more functional.<\/p>\n

If I want a concrete rule checker I could use partial application<\/a>:<\/p>\n

\n

let<\/span> myFirstRule mail =<\/p>\n

  \/\/ I don’t care about this<\/span><\/p>\n

<\/span><\/p>\n

\n

let<\/span> mySecondRule mail =<\/p>\n

  \/\/ I don’t care about this<\/span><\/p>\n

<\/span><\/p>\n

<\/span><\/p>\n

\/\/ val ruleChecker :  (EMail \u2013> SpamResult)<\/span><\/p>\n

let<\/span> ruleChecker =<\/p>\n

  checkMail<\/p>\n

    [ myFirstRule;<\/p>\n

      mySecondRule]<\/p>\n<\/p><\/div>\n

As you can see the F# implementation is nearly the same as the C# implementation, just without explicitly wrapping our public method in classes. If we would use Reflector we would see that the F# compiler is building the classes around our functions. One could say if we follow the Open\/Closed Principle we come to functional code or the other way around if we write functional code we automatically apply the Open\/Closed Principle. I think that\u2019s why I really didn\u2019t care about this before.<\/p>\n

Appendix<\/h5>\n

After thinking about this implementation and the extra type hint (see mail:EMail) I came up with a slightly more generic implementation:<\/p>\n

\n

<\/span><\/p>\n

type<\/span> SpamResult =<\/p>\n

  | Spam<\/p>\n

  | OK<\/p>\n

 <\/p>\n

\n

let<\/span> checkRules rules element =<\/p>\n

  let<\/span> rec<\/span> checkRule rules =<\/p>\n

    match<\/span> rules with<\/span><\/p>\n

    | rule::rest -><\/span><\/p>\n

      match<\/span> rule element with<\/span><\/p>\n

      | None -><\/span> checkRule rest<\/p>\n

      | _ as<\/span> other -><\/span> other<\/p>\n

    | [] \u2013><\/span> None<\/p>\n

 <\/p>\n

\n

  checkRule rules<\/p>\n<\/p><\/div>\n

Here I deleted the enum value for SpamResult.Unknown and used the standard None option. As a consequence the signature changed to:  val checkRules : (‘a -> ‘b option) list -> ‘a -> ‘b option. The function still takes a list of rules and a element and returns a option value. Now the checkRules function works with every kind of rule result and takes arbitrary elements.<\/p>\n","protected":false},"excerpt":{"rendered":"

Friday I attended the .NET BootCamp \u201cNHibernate vs. Entity Framework\u201d in Leipzig and as always it was a pleasure for me being there. Afterwards I had a nice talk with my friend Alexander Groß about the Open\/Closed Principle. I didn\u2019t really care about this principle before, but now I think it\u2019s really a nice idea: […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[12,23,448,6],"tags":[383,565,664,566,567],"_links":{"self":[{"href":"http:\/\/www.navision-blog.de\/blog\/wp-json\/wp\/v2\/posts\/854"}],"collection":[{"href":"http:\/\/www.navision-blog.de\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/www.navision-blog.de\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/www.navision-blog.de\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"http:\/\/www.navision-blog.de\/blog\/wp-json\/wp\/v2\/comments?post=854"}],"version-history":[{"count":6,"href":"http:\/\/www.navision-blog.de\/blog\/wp-json\/wp\/v2\/posts\/854\/revisions"}],"predecessor-version":[{"id":860,"href":"http:\/\/www.navision-blog.de\/blog\/wp-json\/wp\/v2\/posts\/854\/revisions\/860"}],"wp:attachment":[{"href":"http:\/\/www.navision-blog.de\/blog\/wp-json\/wp\/v2\/media?parent=854"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/www.navision-blog.de\/blog\/wp-json\/wp\/v2\/categories?post=854"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/www.navision-blog.de\/blog\/wp-json\/wp\/v2\/tags?post=854"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}