Sponsored By Aspose - File Format APIs for .NET

Aspose are the market leader of .NET APIs for file business formats – natively work with DOCX, XLSX, PPT, PDF, MSG, MPP, images formats and many more!

Can’t say that I have this problem

Jeff Atwood has a pretty good rant and comment trail up on OOP for OOP's sake.  I can't say that I have the same problems that he's describing.  Heck, I think I'd like to run into people that obsess over OOP.

Other than bumping into a handful of nasty runaway inheritance trees (got one that runs 12 deep at my client), I haven't seen that much OO abuse.  What I mostly see in the legacy code I get to take over is almost purely procedural code that's just screaming for some OO structuring and better separation of concerns.  My experience is that many developers stop learning about programming as soon as they master if/then and looping constructs.

Some of the complaints Jeff Atwood and the commenters repeat may just be shining some light on the downsides of our mainstream static typed OO languages.  Pulling out an interface for only one implementation isn't necessarily done for extensibility, it's probably for testability.  That problem goes away with "Duck Typing."  Design Pattern abuse was inevitably brought up.  Almost as inevitably, someone else brought up the point that many design patterns are just repeated workarounds in our programming languages (C#/Java) that aren't necessary in other languages.  There might be some truth to that one.

The handful of times that I have seen terrible Object Oriented designs,
they were caused by adopting a complicated scheme
for extensibility or premature generalization way too early in the development cycle instead of
growing a design in response to continuous learning.

My little drams of advice for this morning?

  • Favor composition over inheritance.  There are a lot of little reasons, but I'd put forward understandability as the primary reason.  Testability and extensibility also come to mind.
  • Do learn about Design Patterns, but that also means learning why and why not to use each design pattern, not just the usage mechanics.  For that reason, the best patterns book I would recommend is Refactoring to Patterns. 
  • Avoid speculative abstraction.  Every OO abstraction has to earn its right to exist by providing value.  Your OO models will generally be better if you keep things simple upfront and only add more abstraction defensively.  Complicated upfront designs almost never turn out to be worthwhile.  The combination of automated refactoring tools and code written with TDD can push down the mechanical costs of evolutionary design.  Might as well take advantage of that.
  • Throw away bad abstractions and OO models.  Sometimes the very best thing you can do on a project is delete code.  All, and I do mean all, of the worst designs took a bad design idea and kept right on going.  All it would have taken was for one or two people to sit up straight and loudly say "this just can't be right."

For the record, in English at least, "POO" is just "Plain Old Object" to denote a business object that isn't encumbered by special infrastructure requirements (think EJB's).  "PONO" or "POCO" just doesn't have the same ring to it as "POJO" does in the Java world.  Although I'll admit that I do like a couple of Poco songs, but that's nothing to be proud of.

 

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://sticklebackplastic.com Matt Ellis

    “What I mostly see in the legacy code I get to take over is almost purely procedural code that’s just screaming for some OO structuring and better separation of concerns.”

    This is something that continually bothers me about OO. I find that unless you’re writing a framework, you very rarely find yourself writing code that lends itself well to the traditional OO mainstays – polymorphism and inheritance. Encapsulation is almost always needed, but you can argue that most business problems don’t require the other two.

    I’d love to hear how you refactor procedural code into OO code. Or, put another way, how would you model in objects a process that took data in, transformed it several times, then processed various bits of it.

    An example – a mortgage calculator. Takes in a bunch of parameters, does a load of calculations based on them all and spits out a monthly payment. Feels like not much room for objects.

    I don’t know if this is just the world I live in – a lot of stateless process flows – or if I’m missing something. I’d be very interested to hear what you think…

    Cheers
    Matt

  • Dan

    I would highly recommend getting both the Head First Design Patterns book and Refactoring to Patterns and reference one another as you read through them. I find that comparing both methods give me a better grasp on the subject. The core principles of each book are pretty much the same but each has different way to deliever the message.

    And before anyone even thinks of making accusations… No, I’m not just recommending the Head First book because of the girl on the cover

  • http://dotnet.kapenilattex.com Jon Limjap

    Oops… i meant “ingrokgestion”.

  • http://dotnet.kapenilattex.com Jon Limjap

    Maybe “POCO” and “PONO” just doesn’t ring a bell because .NET and the CLR is not “old” enough — certainly not as old as Java, to describe as “old.”

    I too have the original GoF book, and it causes a lot of ingorkgestion.

  • http://codebetter.com/blogs/jeremy.miller jmiller

    I said Refactoring to Patterns in specific because it concentrates more on when and why to utilize patterns. It’s effectively about using patterns defensively.

    I’ve never read the Head First book, so I can’t speak to it, and the original GoF book isn’t the most approachable book in the world.

  • http://www.itgroundhog.com aaron

    Asking in ignorance here (I haven’t read “Refactoring to Patterns”), why not “Head First Design Patterns”? Curious as to differences…

    (http://www.amazon.com/Head-First-Design-Patterns/dp/0596007124/ref=pd_bbs_sr_1/103-8150329-4667841?ie=UTF8&s=books&qid=1173114428&sr=8-1)

    As an introductory text to design patterns (with a helping of “when not to use ’em) I can attest to it’s (HFDP) effectiveness in my own education. (This was after purchasing the original GOF tombe and experiencing brain-lock upon trying to parse it out and apply it…possibly due to my own inexperience…)

  • http://codebetter.com/blogs/jeremy.miller jmiller

    I’d recommend either;) Sorry for being too lazy to post links.

  • Dave

    Doh.

    One is a hardback of the other, with a completely different cover.

    Forgive me being an ijut.

  • Dave