The ALT.NET Criterion

Recently I was on a mail thread where the following question was raised. "What are the kinds of things that concern folks from the ALT.NET community?"

Over the past year I've been pretty involved with ALT.NET and have been part of countless conversations, blogs and email threads on this topic. One of the main takeaways from those experiences is that many of the problems in developing software arise from a lack of application of the following set of principles.

  1. Separation of Concerns
  2. Single Responsibility Principle
  3. Law of Demeter (LOD)
  4. DRY
  5. Not doing BDUF
  6. Liskov
  7. Favoring Composition over Inheritance

These principles are orthogonal to language, technology and platform. Applying each of these principles leads to software that is easier to test, easier to maintain, and easier to extend.

So the real question is not about ALT.NET, it's "How do we build better software?"

Comments (11)

  1. damonwildercarr says:

    I am sure you know this but for any reader not immediately getting this, the list has nothing to do with .NET. It’s Object Oriented DEsign and non of it is new.

    I’ve always hated the fact that all that effort over the last fifteen years in trying to master the craft of all things OO/Patterns/etc. (I even hate listing THAT as it has a buzzwordy handwavy kind of slant to many which is just so wrong).

    I am curious about your listing order. Any meaning behind it? I tend to order these as such when trying to move teams to the drinking well:

      1.  Single Responsibility Principle

    Often easiest to see as a horrible ‘smell’ once they get it. Also a massive pain point to change. Often I walk in and am proudly presented a ‘domain model’. What it is unfortunately is overloaded everything, nasty specialization, and an utter lack of the slightest awareness of your post.

      2. Separation of Concerns

    A natural occurrence if you achieve (1) no? Is there a subset of SRP classes that could violate seperation of concern?

    One variant here for potential mischef is the placement of your SRP classes into assemblies and their dependencies between eachother moves you into the more concrete architectural perhaps.

      3. Law of Demeter (LOD)

    This is the ‘in the small’ principle I tend to fractal everywhere. From component dependency cycles to intra-namespace circular dependencies. This also tends to happen once SRP and one not really explicit here ‘design by contract’ are present.

    I am sort of dismayed now when I see extension methods being written on classes the developer owns. I mean varying your interface (even if it’s static) based on namespace references for YOUR STUFF seems utterly wrong. I love extensions for stuff you cannot change, but is there a good reason ever on stuff you own?

      4. DRY

    I disagree. Copy and Paste is amazingly productive (grin)… Again, if you truly have SRP then you cannot accept other classes with the SAME RESPONSIBILITY. Although just knowing that exists is often the problem.

      6. Liskov

    Let q(x) be a property provable about objects x of type T. Then q(y) should be true for objects y of type S where S is a subtype of T.

       * Preconditions cannot be strengthened in a subclass.

       * Postconditions cannot be weakened in a subclass.

    In other words, don’t do what they told you in college. And… get ready for it… favor what over what? Ah that is coming..

      Not doing BDUF

    The fact we must still speak to this is so broken. It’s often baked into the core of a culture so each situation has to be addressed differently I find, and Agile DOES NOT mean this is fixed. I often get ‘we are Agile but no iterative dev’ or ‘no C.I. server for us, as we hand-off to QA every quarter’ or ‘what’s a mock’?!

    Favoring Composition over Inheritance

    Most just have no idea what this means until you;ve drilled the strategy pattern into their heads and the change in thinking about instances as ‘services’, service consumers, contract defined candidates for being swapped out, etc.

    There are so many reasons but it often is about enabling change post release 1 (where few are measured!). So as this is one heard by many and not understood I also get negative reactions to the comment.

    What are your experiences here? I wish I was surrounded in my professional life as a consultant in NY with clients who had mastery of this but they are stuggling still with Generics for the most part…

    Anway, I love your summation. Your moving us forward via articulating the higher level patterns and indeed I 100% agree (if you read my Amazon book review on Bob Martin’s Agile C# book for example, we face a crisis in a design mandate). And not for those who get it who do not need guidance or encouragement but the average .NET dude who even came out of VB. Once THEY start caring and they understand it is EXPECTED of them, this might holistically get fixed.

    Thanks for the short but powerful post.


  2. Great comment Damon. You just threw a way your own blog post 🙂

  3. Damon

    In terms of Composition vs Inheritance, the biggest recent experience I had is when we were designing Prism in patterns & practices.

    Prior to Prism there was CAB. CAB imposed a pretty strict inheritance model. That meant there was a checklist of things that if not in place, it just wouldn’t work for example root workitem, workspaces, etc, etc. Because of this it was very difficult to light up existing apps with CAB without significant rework. It also took very strong opinions on how you needed to structure your app.

    We head a ton of feedback on this. When we started out with Prism, one of our core values was favoring composition over inheritance. The result was that Prism was much more malleable. None of its core constructs depend directly on one another. All of those constructs can also be swapped in terms of implementation. The heart of it all was an IoC container, that we also didn’t take a hard dependency on.

    The real benefit showed through when we took an existing app (FamilyShow) and were able to light it up with parts of Prism without redesigning it. That was proof for me.

  4. Mike Brown says:

    Hey Glenn,

    I posted my thoughts on my blog…started to reply here, got past the two paragraph mark and switched over to my own post.

  5. Alan Stevens says:

    Glen, I’m not clear on why these are Alt.Net criterion. They appear to me to be OOP development criterion. I heartily agree that the conversation in our community would be improved if we move away from specific tools and new shiny technologies (including MEF, sorry) and focused more on exploring the meaning of these core principles.

    Once these principles are absorbed and assimilated, then we can make the right decisions around using tools and technologies within our given business context.

    Because I feel this conversation is universal, I don’t fly the flag. We all need to be part of this conversation.



  6. @Alan

    The reason for the post was based on a conversation I had internally where the question came up. I agree that these are not things that the ALT.NET community, owns, innovated, etc. However they are a set of principles that people in the community strongly believe in and are pushing for a revival of.

  7. BillKrat says:

    "How do we build better software?"

    Enjoyed the reading, thanks Glenn.  There is soooo much stuff to sift through so it’s nice to get bite-size chunks on a silver platter.

    I haven’t moved on to Agile studies yet, at least not until I take the 70-300 exam (hopefully next month).  I’ve been focused on the Microsoft Solutions Framework (MSF) for the past couple of years and apply the principals whenever practical.  

    What little I did read about Agile had me raising an eyebrow; what I read suggested that you start a project without any form of commitment to scope; that the client is expected to just pay and developers code as they go, changing requirements in the direction the wind is blowing.  I don’t see how this is practical, nor have I ever had a client that would not expect a bid with milestones and a timeline.  Note: I chuckled when I read the "no more than a 40 hour week" notion.

    As a contractor for large corporations perhaps we’re afforded this luxury (but we owe our clients better than this).  When I was a mom’n pop developer if I was asked for a bid on a project there was going to be a commitment to BDUF or I was’nt going to do it; been there, done that and in the end I ended up paying without it (I was held to my bid and scope creeped in all directions).

    I once helped a friend (contractor) put kitchen cabinets in a relatives house – he saved the appliances for last and when he was done their dishwasher wouldn’t fit – they had to go out and buy a thinner one.

    With BDUF – we would have known the dishwasher wasn’t going to fit 😉

    As for 1, 2, 3 and 4? From my personal experience it requires a strong lead/team that does code reviews (reduces the changes of re-inventing the wheel; keeps everyone educated and in sync). I’ve been on very large teams, large teams and smaller teams.  Never been on a project that has failed – most times success was in spite of the design / plans 😉

    As for 6. :O ? Tis been a long coding week(end) think I’ll save that for another day 🙂

    7. After working with the CompositeWPF (aka Prism) and Unity – I’m sold on Composition over inheritance.

    Thanks again Glen – enjoyed the reading!

  8. miguel says:

    The newest user group in Sydney will have it's first meeting on September 30 at the Thoughtworks

  9. Glenn Block mentioned recently the list of very basic rules of "Right Software Design". These

  10. Sure Bill, glad you found it useful. As to 1,2,3 and 4. Code reviews is one way, but that’s more an enforcement technique. Being proactive ahead of time, through educating on the principles, and through pairing makes a big difference.

Skip to main content