My friend needs some help on an article

I would never do this, but a “friend” of mine has procrastinated entirely too long and let a deadline for an article sneak up on him.  Here’s a couple ideas that my friend has for his next article.  The article has to be on design fundamentals from a relatively ideology agnostic standpoint (not overtly pro-Agile or TDD in other words).  His first article in the series on the Open/Closed Principle will appear next month.  Please think about which topics would benefit your team members too, Mr. “I know the basics cold” Alpha Geek.

  • “Design Vectors” / “It’s the Little Things” / “A title that doesn’t stink” — Why do you care about Encapsulation, Coupling, and Cohesion.   Then follow up with some heuristics to push your design towards these qualities.  Tell, Don’t Ask, Law of Demeter, Don’t Repeat Yourself, and a bit on some Code Smells.  My friend wants to sneak in an example of using a lambda expression to remove duplication.  Yes, Mr. Alpha Geek, you’ve read the Pragmatic Programmer front ways, backwards, and sideways, but this is for a more general audience.
  • Creational Patterns — Builder, Factory, Abstract Factory.  Then talk about using an IoC tool as a generic way to implement these patterns.  The importance of separating functionality from the grunge work of assembling object graphs.  My friend isn’t that excited about this one.
  • Object Stereotypes — An introduction to the idea of object stereotypes from Responsibility Driven Design.  Apply these stereotypes to some bigger patterns like MVC/MVP.  It’s an under appreciated topic.
  • Inversion of Control as a Pattern — Forget the IoC/DI tooling.  Let’s talk about how, why, and when this pattern is useful.
  • Patterns for Persistence and Data Access — Lots of stuff from Fowler’s PEAA book.  Unit of Work, Database Mapper, Active Record, Row & Table Gateway.

Anything sound good to you?  My “friend” would appreciate some opinions here.

About Jeremy Miller

Jeremy is the Chief Software Architect at Dovetail Software, the coolest ISV in Austin. Jeremy began his IT career writing "Shadow IT" applications to automate his engineering documentation, then wandered into software development because it looked like more fun. Jeremy is the author of the open source StructureMap tool for Dependency Injection with .Net, StoryTeller for supercharged acceptance testing in .Net, and one of the principal developers behind FubuMVC. Jeremy's thoughts on all things software can be found at The Shade Tree Developer at
This entry was posted in Uncategorized. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • Kalpesh

    I know your friend now ๐Ÿ˜‰
    It goes into recursion, if the author of the article is your friend.

  • Jeremy D. Miller


    I’m with you on this one. I don’t *ever* want to see another article that goes “point XYZ at the Northwind database and let ‘er fly!”

  • Kalpesh

    All topics are interesting.

    However, any topic with “what is it?”, “how it works?”, why should you care? and where it can be applied with real life example (other than northwind) would help.

    Thanks to you & friend.

  • Derick Bailey

    There’s a lot of suggested topics about underlying principles, and “high” level patterns. I’d like to see an article that ties things together – a look at why patterns exist, in the context of the principles.

    for example, MVP/MVC are great patterns – but if you truely understand DI, LSP, SoC, Orthogonality, etc. etc., then MVP/MVC are some of the possible natural outcome of the code you will want to write for a UI.

  • Kiris

    +1 to object stereo types. While the other stuff is interesting, I think this one is under served in terms of coverage.

  • J.P. Hamilton

    Object Stereotypes or Creational Patterns

  • Chad Myers

    @Bil That’s the first stage in bending the mind around IoC and away from ‘traditional’ creation patterns. I started out using ObjectFactory.Get() all over the place, but what I found was that it was essentially just a replacement for the ‘new’ operator and I still had many of the same problems. Sure, I have a lot more flexibility, but it’s still not true INVERSION of control, it’s more DELEGATION of control.

    The next phase (that I went through at least) was to get to the point where no object is creating another object (well, at least the objects I control, new StringBuilder() is OK, for example).

    The only place I want to see ObjectFactory.Get() anywhere is when the app is initializing or in some central place that kicks off a cascading dependency resolution fiasco that results in all my objects being ready to go when they’re needed.

  • Bil Simser

    Heh. What’s funny is *everyone* uses “IoC” describing inversion of control (and hey, why not, it’s shorter to type). I bet *everyone* has an IoC static class with a couple of methods like Resolve and Resolve in them and an initialize method that takes in IWindsorContainer.

    The debate now is should “IoC” be “Locator” since that’s what it’s doing which introduces more DDD like terms to replace the technobabble.

  • andrew finkenstadt

    1+ control of inversion

  • isaiah

    design vectors and object sterotypes please

  • Andy Stopford

    >> I think what I’m going to do first is the Object Stereotypes, but probably use some IoC scenarios as illustrative examples

    when you say ‘I’ you mean your friend, right? ๐Ÿ˜‰

  • Robz

    +1 IoC

  • Jeremy D. Miller


    “”The importance of separating functionality from the grunge work of assembling object graphs”. In OO code, you can’t separate functionality from assemblage of objects.”

    Yes you can, and many times you should. Object graphs do real work in and by themselves. Assembling those object graphs from storage, the database, Xml config, or whatnot is often a separate responsibility from the business logic performed by those object graphs. Sorry, but I think the IoC article has some value based on your comment.

  • Nat

    I vote for the design vectors. It sounds like your friend has a lot of personal experience and wisdom to put across.

    From your short abstracts, I think your friend needs to work more on the IoC/DI/object-construction topics. For example…

    “The importance of separating functionality from the grunge work of assembling object graphs”. In OO code, you can’t separate functionality from assemblage of objects. The functionality IS the assemblage of objects. If you can separate functionality from composition, it means your classes are too large. If you try to separate functionality from composition, you end up with code only expresses how the system works, instead of what it does and why.

    The others sound like your friend is repeating what he has read elsewhere. I’d much rather read his thoughts about software than his rewording of someone elses.

  • Seth Petry-Johnson

    +1 IoC, +1 Persistence and Data Access.

  • Jeremy D. Miller


    This is a bimonthly series of articles for MSDN. The very first one coming up in the June issue addresses OCP and SRP.


    Thanks for all the comments here. I think what I’m going to do first is the Object Stereotypes, but probably use some IoC scenarios as illustrative examples. I’ve got more prepared for that. I might get the “why IoC” thing out on the blog.

    I’ll definitely do #1 at some point. Maybe I’ll do the creational patterns next since so many people asked for it.

    Thanks everybody!

  • Kasi Prasad

    I’d like to see the really basic stuff like SRP and OCP (hopefully with thorough coverage of Strategy) covered. As an MCT (Microsoft Certified Trainer) I am suprised by the number of developers I encounter who have never heard of these terms nor how they are implemented. I think these simple concepts go along way toward teaching the “Why” behind many of the other topics you mention (specifically IoC, Coupling and Cohesion).

    Oh and btw, Excellent Work on that MSDN article regarding ALT.NET. Glad to see MS supporting ALT.NET in a publication that really reaches the masses.


  • Tom Opgenorth

    #1 by far. You need those principles as a foundation.

  • Sergio Pereira

    It’s no secret that I have a thing for incorporating lambdas in your design ( ) but I’d also see a lot of value in an article about favoring composition over inheritance.

  • Joe

    Creational patterns, real world usage.

  • Colin Jack

    I’d like to see Object Stereotypes, seems like the most interesting of the lot.

  • Lucas

    Without a doubt the first one.

  • JohnOpincar

    I vote for IoC and creational patterns.

  • jdn

    IoC, and why it is used/useful for anything but helping testability (sorry Chad :P)

  • Bil Simser

    The IoC one is nice and could make for a good article. My second runner up would be the creational patterns as they can tie into the IoC one, but maybe that should be your “friends” next article.

  • James Lorenzen

    +1 IoC

  • Chris Chew

    I’d love to see an article from your friend on Object Stereotypes!

  • Jeremy D. Miller


    I can’t do that this time. I’ll link to it though.

  • Chris Bilson

    +1 for Object Stereotypes. Will you blog proto-articles?

  • Jeremy D. Miller


    It’s for MSDN Magazine, so you’ll be able to read it one way or another

  • TedE

    I’d like to see Object Stereotypes, since I’m not very familiar with that topic.

  • ScottC

    Where might these articles appear?

  • David Tchepak

    +1 to Chad’s comment on IoC. Be great to have an article on IoC itself, rather than simply of a way of replacing dependencies at test-time.

  • Chad Myers

    My vote is for #4 – the IoC pattern. I’m tired of hearing people say that we do these things just to make testability easier.

  • Bart

    I vote for the first one.

  • Jarod

    my friend told me to tell your friend that he, speaking on behalf of his team, wants to read all of the topics… so just pick one!

    But I say 2, 1, 3, 5, 4