the ‘bee log

Andres Taylor via Jeremy Miller:

Maybe it’s just me, but coming from Computer Science class I thought that OO was easy. I mean, how hard can it be to create classes that mimic the real world? It turns out that it’s pretty hard. Ten years later, I’m still learning how to model properly. I wish I spent more time reading up on OO and design patterns. Good modeling skills are worth a lot to every development team.

This is his top item in a great post, “Top ten things ten years of professional software development has taught me.”

OOP is hard. Hard as in difficult to do well. More appropriately, as Andres puts it, it’s “harder than you think”.

As a technique it’s deceptively easy to think you have it mastered. On the surface it makes a lot of sense. There’s an initial learning curve: what’s inheritance; what’s information hiding; what’s polymorphism? Once you’ve gotten these concepts it’s easy to be lulled into a false sense of accomplishment thinking you have mastered the technique: “I get OO!”

Did you really get it the first time you made that or a similar proclamation? I know I certainly didn’t. Rather it was a series of accelerating “Aha!” moments that continue to this day.

Question:

How many procedural programs are masquerading as object oriented ones? That is, how many developers think they’re writing OO apps but aren’t?

A) Lots of them
B) Loads of them (for the English)
C) All of the above

I’d wager C.

There is a lot of code in the wild which is simply “structured procedural.” That’s fine, but, I’m comfortable guessing based on past and anecdotal evidence, the author is usually under the impression that what they’re doing is true OO.

Why Bother?

I believe OOP is a superior way to structure your programs because it encourages direct mapping between your software and its problem domain. A good OO program is an executable model of what your domain, and, as Scott Bellware argues, superior to model-by-wire techniques favored by the old school, disconnected, ivory tower software architects.

Central to the point of DDD and the trend toward Domain Model is the question, why would you separate your model from it’s implementation? There simply is no need for the separation when you’re doing OO the right way; the model is the code is the model is the code…

Increasing Returns

Becoming proficient with OO is a big investment. It’s a change in mindset that comes with a learning curve, and flattening this curves takes plenty of time, effort, and practice. It’s a change in mindset that requires a constant commitment to learning.

As an investment, consider OO an annuity, and more of a permanent life insurance than a trust fund. That’s to say you’ve got to put work in to get benefit out. There’s a lot of reading you need to do and a lot of decisions and mistakes you’ll need to make before you develop a trusty toolbox of strategy and tactics. 

Infrastructure technologies come and go. Even large scale shifts in our tool approaches such as functional programming and external DSLs work perfectly well (or at all) when an OO lens is applied.

There is no other development paradigm (I’m aware of) has either the level of utility and nigh-universal applicability or the vast body of knowledge behind it: Agile Methods, Refactoring, TDD, DDD, Patterns, Pattern Languages - all “pluggable knowledge” into the OO mindset. OO techniques and practices form a fabric and amplify each other, they evolve.