Let’s go back to the basics of Cohesion and Coupling

Recently, I’ve seen a nice trend out on the blogosphere on going back and revisiting the basics of programming like this post from Scott Hanselman and this podcast from the Herding Code gang.  My contribution to this trend just went out in the October issue of MSDN Magazine.  For the latest issue of the Patterns in Practice column I decided to focus on the very basics of software design:  Cohesion and Coupling. I made an effort to explain the two concepts of coupling in terms of the first causes of desiging code that is readable, simpler to change, and easier to write.  Assuming that I made my case on why cohesion and coupling qualities are important to your daily coding effort, I moved onto some design concepts that can help point the way toward better coupling and cohesion qualities in your code:

  • The Tell, Don’t Ask Principal from the Pragmatic Programmers
  • The Law of Demeter.  I can’t say that I coordinated with him, but fellow Austinite Jimmy Bogard conveniently wrote the perfect companion piece for this section entitled:  Entities and the Law of Demeter
  • Once and Only Once” from Extreme Programming.  One of the best things you can do to improve your design is to simply recognize and remove duplication whereever it pops up.
  • Information Expert from Craig Larman’s GRASP patterns. The GRASP patterns are a great read for OO newbies.

And just for fun, I talked about some “Code Smells” that can help us spot potential coupling and cohesion problems that have crept into our code:

  • Inappropriate Intimacy



Coming up next

Roy Osherove made a good post yesterday called Goodbye
mocks, Farewell stubs
about why so many teams and developers struggle with
adopting TDD and their inability to grasp the “Testability message.”  He’s largely talking about the learning curve hurdles with some of our existing testing tools, but I still
think the bigger obstacle to TDD adoption (assuming that people are open minded
and willing to begin with) is a general lack of skill with designing Object Oriented systems.  TDD adoption
punishes coders that don’t understand the basics of coupling, cohesion, and separation of
concerns.  Coincidentally, I’m busy writing my next article for Patterns in Practices on “Testability and Design” to explore the design considerations and patterns for the efficient usage of automated testing (I was going to steer way clear of interaction testing and all the TypeMock/DI/Mock v. Stub. v. Let’s just hopelessly muddle the situation by calling lots of very different things a ‘Fake’ controversies, but decided that it just couldn’t be complete without some mention of substituting fake implementations for infrastructure concerns).


The Hereafter…

I’ve been renewed to continue the Patterns in Practice column throughout next year, so I need to generate some more article ideas.  Anything below sound good to you?  Got any requests?

  • Essence, Ceremony, Conventions, and Opinionated Software — I want to explore ways to increase the Essence v. Ceremony quality of our code with better API’s, some FP-like coding, and the way that we’re starting to exploit convention over configuration techniques in our designs.  I also want to talk about the impact of programming language advances on our designs
  • I’d love to do an article on messaging patterns and Distributed Domain Driven Design ala Greg Young, but this is mostly for my own learning benefit
  • Designing better API’s.  I want to use my experiences with StructureMap to talk about how to create more predictable and usable API’s.  This has been on my mind quite a bit lately because of some flat out mistakes I made on the previous version of StructureMap that I’m trying to correct
  • I’ve also proposed Persistence/Infrastructure Ignorance as a possible topic to MSDN.  Obviously, I have to be very careful with this one, but I think it would be valuable to explain the issues and the patterns used to accomplish Infrastructure Ignorance.  I think I would work in the Hexagonal Architecture 
  • The Top N (where N == however long the article needs to be) things that makes a codebase hard to work with.  That’s not exactly a design-specific article, but I’ve had the outline for it for 18 mos
  • Moving beyond the Layering Metaphor for Software Design — I don’t think about my architecture in layers anymore, do you?
  • Data Access patterns.  Repository, Database Mapper, Active Record, etc.  I’m not enthusiastic about this, but sooner or later I’ll do it

I’ve thought about an article on Inversion of Control as a pattern, but I’m working it into my current article.  I’ll also take requests and suggestions.

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 http://codebetter.com/jeremymiller.
This entry was posted in Uncategorized. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • http://blog.jonasbandi.net Jonas Bandi

    The link (http://msdn.microsoft.com/en-us/magazine/cc947917.aspx) to your article seems not to work any more :-(
    I have glanced the article before and would like to read it now :-(

  • mickd

    would definitely like something on getting away from layering. i’m working on a large dot.com at the moment and it kills me the amount of unnesscessary layering we have to deal with jus to keep archtectural “best practices happy”.. i’m trying to get across the ddd message, but all i see is dto’s and layers everywhere… :-(

  • http://blog.phatboyg.com/ Chris Patterson


    Let’s talk about messaging patterns (and maybe walk through masstransit) at KaizenConf, eh?

  • http://www.thefreakparade.com Nathan

    They all sound great. DDDD would be my top pick though. Then probably Essence, Ceremony… followed by Data Access Patterns.

  • Paul

    Essence, Ceremony, Conventions, and Opinionated Software

  • http://coderblues.com Coder Blues

    My vote would be for the top N.

  • Ike Casteleyn

    The last 3 get my vote (top N, layering, data access)

  • http://www.chrisholmesonline.com Chris Holmes

    You may not be enthusiastic about it Jeremy, but I know for myself, I’m enthusiastic to hear about your take on Data Access Patterns. I just feel like it’s an area that doesn’t get enough real coverage.

    I’d also like to vote for the second item: messaging patterns. I’d particularly like to read something (related) about message buses, etc. (NServiceBus type things). I think there’s a whole lot in that area that we developers could learn a lot more about.

  • http://codebetter.com/blogs/jeremy.miller Jeremy D. Miller


    I’ll keep that in mind. I don’t know if it’s all new patterns so much as some of the old GoF patterns go away as unnecessary.

    We had the conversation at work today about why IoC tools are generally considered unnecessary in Ruby.

  • http://elegantcode.com David Starr

    How about introducing a few patterns that may be useful in a dynamic language world? Perhaps implemented in IronRuby?

  • Don

    Just wanted to say that it’s VERY refreshing to see some OOP foundation and best practices stuff in MSDN. Keep up the good work!

  • o.s.

    “The Top N things that make a codebase hard to work with” gets my vote as well. I don’t think enough devs really have a clue in this area and it shows in the codebases I’ve come across.

  • Gabriel Schenker

    a little bit more DDDD (Greg Young’s articles are a great start) would be appreciated 😉

  • http://bahadorn.blogspot.com Bahador

    If I was to choose from the proposed articles you mentioned above, to read now, I would probably choose this one:
    “The Top N things that makes a codebase hard to work with.”

    Thanks for your great articles!