Widgets Nick Hodges | A man's got to know his limitations

What I've been reading

By Nick at June 16, 2011 08:41
Filed Under: General, Personal

Flotsam and Jetsam #35

By Nick at June 10, 2011 07:02
Filed Under: Flotsam and Jetsam, Delphi

Flotsam and Jetsam #34

By Nick at June 09, 2011 00:53
Filed Under: Delphi, Flotsam and Jetsam

Getting Giddy with Dependency Injection and Delphi Spring #3 – Writing Testable Code

By Nick at June 05, 2011 13:05
Filed Under: Delphi, Software Development, Unit Testing

Okay, so in Part #2 we talked about the Law of Demeter, and how you should think about it and follow it as if it were the Word of God when building classes. 

One of the main reasons to follow the Law of Demeter is to write code and code modules that are loosely coupled.  Loosely coupled modules have minimal interactions with other modules and thus have minimal affect on those other modules.   Change something in a loosely coupled module and the chances of breaking something in another module are slim.  If you have a minimal connection to another module, then you can only cause minimal bugs in that module.

And “minimal bugs” is a phrase to warm the heart of us all, no? 

But the Law of Demeter even goes farther than that.  Using the LOD principles means that you can write “testable code”.

So I think we’d all agree that  the best way to avoid bugs in your application is to never check them in to your source control system in the first place. (And you are using a source control system, aren’t you?)  And the best way to do that is to write lots and lots of unit tests.  Unit tests are the first line of defense against bugs, as they can root out problems in your code as you write them.  They can discover trouble at the very lowest level before it becomes a system level problem.  Writing unit tests is the profound and solemn duty of every software developer.  If you do “true” test-driven development, you’ll write your test first so that the bugs never even show up at all as you write your code to make your tests pass. 

But when it comes to writing unit tests, a common refrain I hear is “I can’t test my code” or “My code is too complicated to test.”  And my response to that is this:

If your code can’t be easily unit tested, you’re doing it wrong.

In fact, this is kind of getting to be our mantra around here at Gateway Ticketing.

Now there are exceptions, of course, such as code for directly manipulating your GUI, etc. But if you are writing anything other than that -- i.e. the vast majority of the code you do write -- then you should be writing code that is testable.  But I’ll make the point again – if you can’t write unit tests for your code, then you need to change the way you are writing your code.   That is, you should be writing code that is “testable”.

Code that is “testable” has a number of familiar qualities.  The most noticeable of those is – surprise! – code that adheres to the Law of Demeter.  LOD code is easy to test because the classes you write stand alone and have limited dependencies.  Code with limited dependencies is easy to test.

A common refrain is this – “My code isn’t testable because it hooks up to too many other things like a database or a scanner or some other thing that can’t be attached to the test suite”.  And my answer to this is:  change your code to remove those dependencies and write mock objects for the instances that you can’t.

Code that is hard to test has dependencies.  Creating an instance of a given class can result in the creating of a host of other classes – even classes that you don’t know about or can’t foresee.  As noted above, heavily coupled code creates these dependencies. Consider the diagram below:


Here, you have a class that you want to test, but when you create it, it creates, in turn, three other classes that then  can create yet more classes, including dependencies on external devices and other systems.  Such classes are hard to test, because testing them brings in all those dependencies. 

What we need is a way to limit and even remove those dependencies in order to make a class easily testable.  And the way you do that is to find the “seam” in your class.  The seam is the point where the dependencies are “attached” to the class to be tested.  Once you find that “seam”, you can reduce and/or eliminate those dependencies.  In the diagram below, the Class Under Test is made more testable by creating classes that don’t create dependencies – a better designed class that itself uses the LOD, a “stub” class that does nothing (say, a logging class that actually doesn’t log anything) or a Mock class that merely pretends to be the external dependency without actually being the external dependency. 


Creating classes for which you can find this “seam” and substitute classes that don’t create the dependencies is key to creating a “testable” class.  Remember, it is hard to introduce bugs into systems that are made of up easy-to-test classes.  So, we should write easy to test classes, right?

The critical thing to remember here is that the class need not completely avoid the dependency – at some point your code is going to have to connect up and talk to that Oscillation Over-thruster – but rather your classes should be able to limit those dependencies as much as possible, and where they can’t, they should be easily able to “fake” having the dependency so the class can be tested without the real dependency.

And just how will that be done? You’ll have to tune in for the next episode!

Flotsam and Jetsam #33

By Nick at May 20, 2011 09:01
Filed Under: Flotsam and Jetsam

A Note on Delphi Open Source Licensing

By Nick at May 12, 2011 14:29
Filed Under: Delphi, Software Development, TechBiz

I love open source code.  I love the notion of sharing and working together for the betterment of a community. I love the free stuff that I can use because of the generosity of open source developers. 

Open source development often can be bogged down by licensing decisions.  I don’t know how many bits have been spilled arguing over the exact meaning the Lesser GNU Public License (LGPL), or whether the GNU Public License (GPL) is one step away from a socialist worker’s paradise or not, but surely it’s a lot of bits. 

Well, I’m going to spill a few more.

I totally get the GPL – I respect it, and I laud the folks that do work on GPL-based projects.  They are really giving away for free (as in speech) their work to others.  Linux exists because of the GPL. I get why the license exists. I understand the whole “Free Beer/Free Speech” thing.   Some amazing, awesome things exist because of the GPL.  It’s all good.


The GPL is completely incompatible with commercial software.  Totally, utterly, and completely incompatible.  If you use GPL source code in your commercial application, you are obligated to release your entire application as a GPL Open Source project.  Everything.  Obviously, if you sell your software, you very likely don’t want to do that.  (I recognize that there are folks that will, and more power to them…..).

Now, Delphi is a development tool used by a whole lot of businesses – businesses that are likely not to want to make their source code available under the GPL.  And so open source projects that are aimed at Delphi developers make a very limiting decision if they release their code under the GPL.  A Delphi library of code with the GPL attached to it will severely limit the number of Delphi  users that can or will use that library. 

Many of the popular open source libraries for Delphi use a much less restrictive license.  All the Turbopower code was released under the Mozilla Public License (MPL) which is much less restrictive, only requiring you to share any changes you make to the MPL project itself.  Others use the Apache License which is very permissive.  But some do use the GPL.

Now, I’m going to give some advice to those folks who publish Delphi source code under the GPL:  Issue it under an alternative license – one that businesses can handle.  I’d recommend MPL at the most strict end of the spectrum.  We are going to start using the Delphi Spring Framework, and that is licensed under the very friendly Apache license.  I’d love to use the Emballo framework as well – particularly for the Mock object classes, but it is licensed under the GPL, and so we really can’t touch it. A project like the Emballo project is also available for use under the LGPL and worth considering.

The GPL is great – it works well in the Linux world and where other open source development tools reign supreme.  But for more commercial-based eco-systems like Delphi, a business-friendly license is much more in order. 

Flotsam and Jetsam #32

By Nick at May 12, 2011 13:28
Filed Under: Flotsam and Jetsam, Software Development
  • “We put our faith in Apple and they screwed us”  Just another reason why Apple always seems to rub me the wrong way.  Don’t get me wrong -- I think Apple should be able to do what they want when it comes to this type of thing – but I don’t have to like it.
  • I confess to being guilty of this in my blog, but no more, I promise.
  • Have you had this problem? You are working on a website and local testing/debugging is a hassle because you have to move from page to page filling in valid information, and it takes huge amounts of time and you cringe when you have to do it?  Our team here at Gateway has started to use iMacro.  It’s a FireFox that lets you record events on a given website and run them with the click of a button.  This is saving our guys tons and tons of time.  Highly recommended.
  • And yet another way that you can support the fine work we do here at – you can join DropBox as my referral.  It’s completely free for the first 2GB. Yes, I am well aware that this appeal is utterly shameless.  In addition, I give the DropBox folks full marks for marketing – they basically have a zero-dollar advertising budget.

Getting Giddy with Dependency Injection and Delphi Spring #2 - The Law of Demeter

By Nick at May 11, 2011 09:07
Filed Under: Delphi, Software Development


Okay, I keep digging into the Delphi Spring Framework and I keep finding cool stuff you can do, so I can hardly wait to write all these articles.  Seriously, this is a mind-expanding experience.

First, though, I need to talk about some general topics.  There are a few things that need to be accepted and understood before Dependency Injection can really sink in.  (And again, I want to point  out that I’m deeply indebted to Misko Hevery of Google for a lot of this material.)

The Law of Demeter (LoD)

First topic -- the Law of Demeter.   What exactly is the Law of Demeter?  The strict definition goes like this:

Law Of Demeter

A method of an object may only call methods of:

  1. The object itself.
  2. An argument of the method.
  3. Any object created within the method.
  4. Any direct properties/fields of the object.

That’s a bit formal, so here’s a “real world” example:

Let’s say you go into a store.  You buy a bunch of stuff, and the total is $25.  When you go to pay, what do you do?  If you are believer in the Law of Demeter, then you pull out your wallet and give the $25 to the clerk – just the money, nothing more.

But no, you are a scofflaw and fear not the deep coupling of your wallet to other people and thus you think the Law of Demeter is for weaker men, so you pull out your wallet and hand the whole thing over to the clerk and let her decide what to do for the payment. 

Lady at Cash Register

Sure, you intended to pay with cash, but instead the clerk takes your wallet, uses a credit card to pay for the stuff, drops your library card on the floor, runs your BuyMore loyalty card through a degaussing machine, and draws a moustache on the picture of your wife.  You paid for the stuff, but wow, what a mess!

That’s why you should follow the Law of Demeter in a nutshell.  It’s basic premise is that you should only hand over (and on the other side, only ask for) exactly what you need to hand over (or ask for).  Things should be linked together with as thin a string as possible.  The Venn diagram illustrating the connections between classes should have as small an overlap as can be managed.  In this example, you might not even want the clerk to know you have a wallet, right?

Or in another example, you wouldn’t give the paperboy your wallet or let him search around your house for spare change.

A Coding Example

So for instance, in code, you may have a Transaction class that needs a form of payment to be completed.  And hey, look! The Customer class has different Forms of Payment, so you pass a Customer to the Transaction.  Sure, at first all is well, because you are very careful and all you do is grab the Form of Payment from the customer and use it.  What could possibly go wrong?


But a few months pass, and that (cough, cough) “less experienced” developer comes along and says “Hey look! Here’s a Customer object!  I think I’ll change his address here instead of over there!” and all heck breaks loose.   Pretty soon, you are fixing a bug in the Transaction class and Customer data changes.  You fix a Customer bug and access violations start flying when you try to commit transactions to the database.  The next thing you know, changing a Customer address is sending major cash bonuses to your office cleaning service, and before you know it, there is no end to the havoc reeked by that little Customer object innocently sitting in the Transaction class.

The right thing to do, of course, is to simply pass the Form of Payment itself, or better yet, forget the Form of Payment and pass in just the money itself in some form.  The idea is that your classes should ask for a little as possible, and refuse to accept more than they need.    If you have code like this --


-- that is, code that seems to drill down deep into a class hierarchy -- then you probably deserve a ticket from the cops for breaking the Law of Demeter.  You’ve gone searching down a rabbit hole for something that you should have just asked for to start with.

The classic quote is “Only talk to your friends, and never talk to strangers”. “Mind your own business” comes to mind as well. 

Or let’s put it in even starker terms:  Pretend that every class you write is a pristine clean room with no germs, dirt, or any other yucky stuff in it – and that you plan on keeping it that way.  Are you going to let some delivery guy who just tramped through a horse barn while sneezing because of the ebola virus just walk  into your room and hand you a package? Heck no!  You are going to make him shower, scrub, de-sanitize, purify, and otherwise delouse himself before entering.  Heck, you should probably make this guy put on some sort of bio-hazard suit on before you let him in.  Or even better still, don’t let him in at all, and only let him pass in whatever he’s trying to give you via some secure slot in the door. 

That’s how you should be treating any outsider class that want’s to sneak in to the current class.

Law of Demeter in Delphi

Delphi and the Law of Demeter can be good friends.  Here are some pointers to help out in your Delphi code:

  • Limit the number of units in your uses clauses.  If you have a long list of items in your uses clause, it is a strong indication that things are tightly linked together.
  • Limit the scope of your uses clauses.  If you can put an item in the uses clause of the implementation, do so. 
  • Use strict private and strict protected.  This will limit you from the temptation to make classes “friends” of each other in the same unit.
  • As noted above, anytime you have a chain of “dotted” properties in a single line, you should examine this for violations of LoD.
  • Anytime you are creating a lot of temporary object, this might indicate un-necessary dependencies.
  • Check your constructors – if they are creating a lot of things or taking a lot of other classes as parameters, then the same thing applies:  the possibility of too much coupling.

Note that these aren’t iron-clad rules, but rather suggestions of examination and consideration. It need not become “a Dot Counting Exercise.”  The idea is to reduce coupling and thus limit the damage any one modification can have on the system as a whole.


Following the Law of Demeter is a key to creating clean, easier to maintain code.  Once you get that down, you’ll also find that you are writing code that is easy to test.  Next time, we’ll take a look at why it’s important to write testable code. 

Flotsam and Jetsam #31

By Nick at May 10, 2011 08:30
Filed Under: Flotsam and Jetsam, Delphi
  • Interesting News Item of the Week:  Microsoft is buying Skype.  I’m a huge fan of Skype.  I like it best as an IM client, and as a teleconferencing system as well.  The creepy feeling you get when someone is on Skype in a conference room using a nice set of speakers takes some getting used to.  It’s a bout 342 times better than a POTS conferencing system.  Anyhoo – I’ll be curious to see if MS rewrites the currently-written-in-Delphi Windows clients and continues to support non-Windows clients as well. 
  • New Delphi Blog of the Week: Delphi Sorcery  and I’ll give him Cool Delphi Code of the Week as well. 
  • As you may have noticed, I’ve added one of those little tool bars to my posts that let’s you Like/Add/Tweet/whatever my postings.  I do this in a self-glorifying attempt to get you to broadcast my stuff more.  It was amazingly easy to do with AddThis.  I trust you all will take the hint. 
  • I thought this was pretty impressive.  How long can it be before everything is just a Javascript application running in a browser?  I’ve been saying for years that Javascript is to the browser what assembler is to the CPU.

I Have a New IDE Color Scheme……

By Nick at May 10, 2011 08:08
Filed Under: Delphi

I used a theme from the many found in the Delphi Theme Editor as a starting point, did a few tweaks, and ended up with my my new coloring scheme that I’ve called “ChocoCaramel”  What do you think?


What do you think?  Here’s the XML file from the Delphi Theme Editor if you want it.

ChocoCaramel.theme.xml (103.56 kb)

Getting Giddy with Dependency Injection and Delphi Spring #1

By Nick at May 09, 2011 14:13
Filed Under: Delphi, Software Development

I remember way back in the 90’s when I finally had “the light bulb” go on about object oriented programming.  You know “the light-bulb” I’m talking about  -- that moment when suddenly you get it and it all becomes clear and it all makes sense and you have this thrilling sense of understanding and one-ness with your code and the new concept.  It’s really fun.

For me and OOP it came in the middle of reading what is still my all-time favorite Pascal book, Borland PASCAL 7 Insider by Paul Cilwa.  I can still remember where I was sitting when suddenly it all came together in my brain.  It was very exciting.

And I was feeling that way again this week when I started doing Dependency Injection with the Delphi Spring Framework.  It really came to a head when I realized that I can create useful and powerful units that have no code in their interface sections. 

That’s right:  no code in the interface section. No uses clause, no code, no nothing.  Seriously – a unit that looks like this:

unit DoWhatever;


  // a whole bunch of cool code here and nowhere else


Yeah, you heard me – nothing.  And yeah, the cool code mentioned above works and is totally accessible.  That fact alone should give you pause – and give a clue into the power and coolness of what I’m talking about.  And yes, I’m still giddy about all this.

So, how does this happen you ask?  Well, it’s going to take a little while to explain – maybe even a few blog posts – so if you want to see this cool thing that’s got me all goose-pimply, you’ll have some to do some reading.

At the start, I want to say that I’m well aware that Java guys in particular have been doing this kind of thing for while, and that .net guys have been  as well.  That’s great. I know Delphi is a bit late to the party here, and I am too, but that doesn’t make it any less cool and it doesn’t make me any less giddy.  Winking smile

Okay, first, I’ll give you a few things to do.  To get the basic idea of where we’re going with all this,  I recommend that you read the seminal article by the inestimable Martin Fowler about Dependency Injection.  Understanding what Dependency Injection is  is key to all this cool stuff.  I’ll try to explain what Dependency Injection is in the first post, and then move on to the code itself.

Second, you’ll need at least Delphi 2010 and preferrably Delphi XE to do all this.  This stuff requires Parameterized Types (Generics) and you can only get that language feature from Delphi 2010 and above.

Third, you should go and download the Delphi Spring Framework from Google Code.   I recommend that you pull it using Subversion instead of grabbing the zip files as then you’ll be able to keep up more easily on this always improving project.  Get the code and start poking around, particularly in the Spring.DI.* units and the tests that go with it.  The TContainer class is really the heart of things, and so give that a close look.

And if you want some cool videos to watch that talk about a number general principles of how you can use dependency injection to make your code better, I’d recommend these three by Misko Hevery of Google:

And that ought to get you started thinking about some of the things you should be thinking about when doing Dependency Injection.

Next time I’ll give some samples of code and why this is all important.  And yes, I’ll likely be using a lot of the same material that Misko did.  Smile

My Old Blog is Back!

By Nick at May 04, 2011 00:39
Filed Under: Delphi, General

Hey, I’m delighted to note that my old Embarcadero blog is back online.  Thanks and kudos to David I who noticed that it was amiss and resurrected it.  He noted in a comment that the “archive” flag apparently didn’t mean what he thought it meant.  In any event, I’m very happy to have it back online.  Thanks, David I!

Flotsam and Jetsam #30

By Nick at May 03, 2011 05:00
Filed Under: Delphi, Flotsam and Jetsam

Flotsam and Jetsam #29

By Nick at April 25, 2011 23:43
Filed Under: Delphi, Flotsam and Jetsam
  • The folks at DevJet are at it again,  producing a cool little free enhancement to the Delphi IDE the makes your Help Insight window look cooler.  Help Insight is rendered according to an XSL file, and if you change that, you can make your Help Insight look as you please.  They also make it so that you can embed images in your /// comments that then appear  in the hint. 
  • Stay buggy, my friends
  • Cool Delphi Code of the Week: The Emballo Project. This is a nice dependency injection library that also has a really cool Mock object library as part of it.  I’ve actually updated the Mock objects to take Variants, and I’ll try to see about rolling that back into the repository.  The project hasn’t been updated since October 2010, but it is work a look and there is a lot to learn there.
  • In a previous Flotsam and Jetsam entry, I mentioned an interesting thread that was still alive after a long while that provides are reference to Delphi code that allows the integration of Crystal Reports.  Well, the author of the code must have seen my posting, because he sent me a message with a link to the file itself, offering it up for anyone who wants it.  Nice. He mentioned that it even works with Delphi XE.
  • Does anyone know anything about the Common Service Locator interface?  Is this a widely accepted way of providing service interfaces?  Has this been implemented in Delphi?

A Big Thank You

By Nick at April 15, 2011 04:59
Filed Under: Delphi, Software Development, Tech Stuff

I’d like to pass on a big thank you to Marco Cantu, Cary Jensen, and Cary’s lovely wife Loy Anderson for their wonderful hospitality while I was at Delphi Developer Days in Baltimore earlier this week.  It was an honor to be asked to be a guest speaker at the event, and I hope that my talk on unit testing with Delphi was worthy of the conference.  Cary also graciously gave me a signed copy of his excellent new book, Delphi in Depth: ClientDataSets

I should add that the conference was very valuable.  Cary and Marco do a great job and there were a lot of good examples and code, as well as a very nice manual with tons of great articles in it.  I heartily recommend attending next year if you are so inclined.

My Book

A Pithy Quote for You

"It is difficult to get a man to understand something, when his salary depends upon his not understanding it."    –  Upton Sinclair

Amazon Gift Cards

General Disclaimer

The views I express here are entirely my own and not necessarily those of any other rational person or organization.  However, I strongly recommend that you agree with pretty much everything I say because, well, I'm right.  Most of the time. Except when I'm not, in which case, you shouldn't agree with me.