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.

Template Method is one of the design patterns I turn to a lot when building tiny, lightweight frameworks.

Sure it’s been around since dirt, but I count it as a first class citizen in the pantheon of useful patterns, living with its more hyped siblings: DI/IoC, MVC, MVP, etc. (Yes I know MVC is also old as dirt, Smalltalkers). Maybe it’s not as sexy or “cool” but it’s damn handy for building a consistent and testable codebase.

Let’s take a look:

public abstract class TaskBase
{

  public void Execute()
  {
    using (TransactionScope scope = new TransactionScope())
    {
       if (this.BeforeExecute != null) BeforeExecute();
       ExecuteTask();
       if (this.AfterExecute != null) AfterExecute();
       LogExecution(); 
       TransactionScope.Commit();
    }
  }

  public event EventHandler BeforeExecute;

  public event EventHandler AfterExecute;

  private void LogExecution()
  {
    // write event details to 
    // some durable resource
  }

  protected abstract void ExecuteTask();
}

Above I’ve declared an abstract base class (or Layer Supertype if you skew fancy). In this case “ExecuteTask” is our template method. Inheriting classes must implement this method. This is where the work of our “Task” implementation actually gets done.

What’s cool is that we’ve essentially created a one class framework here. With a simple base class we manage a transaction, log execution, and provide pre- and post-execution notification. The work surrounding the meat of our implementation is both separated and consistent and doesn’t encumber the testability of our specific task classes.

We could easily add behavior to this base class (asynchronous anyone?) and make it testable through the normal means of constructor or setter dependency injection (or manual stuffing in a mock) of the services it calls on.

Additionally you could mark your Template Method (ExecuteTask) public if you don’t mind it being exposed to the world trading for increased testing ease. This is a similar choice to the whole internal/public constructor debate regarding Entity classes and, unlike The N, I won’t “Go There”.

I am sure a lot of you are probably aware of Template Method, no matter, I want to give it the love it deserves. It’s a great technique for creating simple, lo-fi frameworks that standardize, de-duplicate and separate infrastructure from pure business logic.

-

Definition? Examples? What the hell am I talking about? Click here.

I had intended to write-up a review of my impressions of the recent MVP summit, but why not let Jeremy Miller do it for me? I think I shall. There were, to me, other interesting elements close to my heart, so hopefully I’ll be able to blog about soon as plans and products are revealed in the near-near future.

One additional comment I’ll have is on the p&p feedback session hosted by Tom Hollander and Don Smith. I realize that they’re more community facing than the average product team. Still I’m impressed by the level they’ve taken it to and I think they are probably discounting the value of the position they have in evangelizing Agile methods to the .NET community. 

I do hope they’ll consider revising and expanding upon the “Application Architecture” document and incorporate some ideas and guidance around TDD (designing for testability), DI, AOP… some of the things we see in the “patterns” side of the house with things like CAB and EntLib 3.

Meeting a good chunk of my OPML file in one fell swoop was awesome. Augmenting my OPML file was even awesomer. I liked almost everyone… even Scott Bellware (despite the fact that he p0wns a good chunk of me). 

I’ve been in the “Smart Client” realm lately but with web projects looming on our horizon I’ll take a serious look at the MonoRail framework. On multiple occasions various smart and reputable people enthusiastically recommended the MVC framework: web apps for the cool kids, rails for the typesafe.

The one thing that sucked was the NE “snowstorm”. Like Sam I got delayed until Sunday, ending up on the redeye into Philly then the train to NYC. I got home Monday at 10:30 in the morning.  

A THREE DAY DELAY?! Epic.

On the upside I had Drew Marsh as my travel buddy and couldn’t have asked for a better co-commiserator. Seriously easy going guy and we had the whole startup / Manhattan living thing to chat about. He also indulged my many questions regarding WPF which was kind of him.

At the MVP Summit I got a chance to participate in a great, vehement, passionate, and deep conversation about the forthcoming ADO.NET Entity Framework with the Microsoft team responsible and some of the main leaders of the Agile .NET community.

A recent post from Jeremy Miller:

I am putting a post together on what we saw from Linq to Entities this week, but let’s just say that I thought the only compelling technical advantage it had over NHibernate is Linq queries. One of the smart aleck comments somebody made was that Ayende would probably add a Linq front-end to NHibernate over a long weekend.

I can’t agree on his the only “compelling technical advantage” comment. Perhaps true from the standpoint of what ships with Orcas release of VS, but as a long term vision I think we need to seriously consider this as a positive step.

What’s coming is not an ORM, therefore there is no comparing the two.

In the traditional ORM (NHibernate) world you have two models: domain objects and database. The mapping is there to, well, map the two worlds: to bring them together. It’s there to solve the (generally overhyped) impendence mismatch.

That said, EDM (Entity Data Model) is a logical representation of a data model. The framework will permit various “services” to be attached to this model such as domain objects/models containing behavior (which is what we want to test and test-drive after all) replete with LINQ queries, reports, mock and test data generation, entity aggregation type service endpoints, etc.

With EDM and its associated platform, OR mapping is merely one facility (of many) possible. It’s a rather ambitious and appealing vision. You can read more about it here and here. 

Jeremy goes on to say that Ayende is working on a LINQ to NHibernate. I’m a big proponent of NHibernate and I will most likely stick with it until the LINQ to Entities framework fleshes out a bit (I don’t see myself as an early adopter on Entity Framework at this point).

It’ll be awesome to have a strongly typed Query Object, but I think I’ve mentioned this before. Not 100% sure if I’ll be ready to give up externally mapped queries, but we shall see after some play and consideration.

Chip Lemmon is getting his UX group off the ground on March 22nd. Get the details right here.

This is a great and topical idea with interesting new technologies like WPF and ASP.NET for AJAX out now and with the tools following soon (Blend looks like the hotness, download the CTP).

Slides (big), code (bigger), and links (negligible).

There’s a nice collection of great books that, once read, will help you realize the elegance and power of the Domain Model. You really can’t go wrong starting here. Take the next logical step. Don’t stop. Keep going. Almost there. Does it ever end?

You tell me!

If you do snag the code scope the “Readme.txt” for a quick note on DB setup. If you are having difficulties, shoot a message into one of the usual channels. If you flat out can’t follow it, no worries, explanation posts to come.

More to come.

Lots more.

You’ve heard it all over the joint: ReSharper’s the stuff. I could never go back to Plain Jane Studio. To squeeze maximum juice you’ll need to learn a bunch of keyboard macros. I found this swell cheat sheet tonight. Print it and fix it to the tackboard by your desk. Maybe you’re looking for a new tattoo? Broken apart a bit it’d make a fine and quite practical sleeve.

-

CodeCamp NYC was a blast. Met some interesting, smart new folks and got to hang out with the usual suspects which is always fun. 

My talk went well, great turnout, and I got lots of ideas for good “fine tunings” to make. If you were there, thanks for checking it out! The questions and comments were many and amazing and got me thinking of all sorts of new angles. 

I promise to post my slide deck, the code, and a resources page tomorrow. I’m taking some time to make the code tight, safe, and usable; I plan to write a series of “idiosyncratic” posts (e.g. how I like to do things) about the domain model contained therein.