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

Flotsam and Jetsam #64

By Nick at September 06, 2012 04:00
Filed Under: Flotsam and Jetsam, Tech Stuff, Delphi
  • Jim McKeeth was kind enough to interview me for the The Podcast at   It was fun to do. 
  • In a previous Flotsam and Jetsam, I mentioned that I had received as gift an ASUS RT-N16 and loaded it with the TomatoUSB firmware.  So far, it’s been working great – I really like it.  The reason I did it was to be able to have better control over the Quality of Service so that I could install an Ooma Telo  Well I have done so, and am quite pleased. 
    • I paid the $40 to have my number changed over.  It took about ten days, and now I am running the Ooma as my house phone. 
    • I got the Ooma Telo from Amazon for $150 (a special price, apparently, as the price appears to have gone up), and paid $40 for the number transfer.  I have cancelled my phone service from Comcast, saving about $50 a month.  That means that the Ooma Telo will pay for itself in four months, and save me a pretty good chunk of change going forward.  
    • And here’s a fun thing about the Ooma – I can take my home phone with me.  If I say, take a trip to my folks house, I can bring the Ooma, plug it in, plug in a phone, and I have my “house”  phone there wherever I am.  I don’t know why I find that amusing. 
    • One concern I had was the fact that if the power goes out,  my phone goes out.  But that’s true for my Comcast phone as well, though it would take a while for the battery to wear out.  In addition, we live in a development with lots of neighbors, and we have cell phones.  And lots of people are starting to get rid of their house phones all together, so that turns out to be a minor concern for me anyway.
  • Alas – Barry Kelly has moved on from Embarcadero. His contributions to Delphi are many and lasting.  I don’t know if I’ve ever met a smarter person, frankly. He’s also just a very interesting guy generally.  Good luck to you, Barry.
  • I won’t be the first Delphi book on LeanPub.  Currently available is Parallel Programming with OmniThreadLibrary by Primož Gabrijelčič.  (You did catch that I am writing a book, right?)
  • There are some pretty cool goodies that you can get if you buy RAD Studio XE3 right now, including a FireMonkey grid from the excellent folks at TMS Software.  It’s called the RAD XE3 Bonus pack. 

I’m Writing a Book

By Nick at September 03, 2012 17:09
Filed Under: Delphi, General, Software Development, Unit Testing

I’ve decided that my first official act as an Embarcadero MVP will be to write a book.

Here’s some details:

  • You can see the outline and a brief discussion here.
  • I’m writing it on LeanPub.  LeanPub is very cool.  They make it very easy for a guy like me to write a book – that is, a guy who doesn’t really know anything about the process of actually producing a book, as opposed to the content in the book.
    • LeanPub outputs to PDF, MOBI, and ePub formats. 
    • Eventually I’ll probably put the book on Lulu or some other on-demand publisher to allow folks to get physical copies if that is what they prefer.
    • You can view the outline on the LeanPub page
    • The book will contain a lot of content from my blog, but of course I’ll enhance and improve that material.  And there will, of course, be a lot of new material.
    • Many of the topics will include the Delphi Spring Framework, DUnit, ,and other cool new frameworks. 
  • I’ve actually been working on the book for a while, but once I saw LeanPub, I knew that I had to make the move official.
  • You can sign up to find out when the book gets published.  You can also tell me how much you are willing to pay for the book. 
  • LeanPub lets you very easily update and enhance the content.  So I’ll probably publish well before I’m done and then update as I go along.
    • This will allow early buyers (who will likely pay a lower price) to provide feedback.  Sort of like a “beta test” program.
    • It will also let me correct mistakes
    • And of course all purchasers will always have access to the latest and greatest version.
  • I’ll naturally incorporate feedback as much as I can.  Your help will make the book better for everyone.
  • I don’t know yet what I’ll charge and when.  That’s another cool feature of LeanPub – I can experiment with the pricing.  A lot of books on LeanPub have a variable, choose-your-own price models.

So I’m pretty excited.  LeanPub really was the catalyst to finally move ahead and make my idea public. 

So give the book a look, sign up to receive updates, and please feel free to provide feedback – I’m interested in what the community has to say.  As long as you are polite and professional, of course.  Winking smile

On the EULA and the Delphi Community

By Nick at September 02, 2012 22:24
Filed Under: Delphi, Leadership, Personal

I won’t rehash the details of the recent “EULA Incident”.  You can read about it for yourselves in the newsgroups or on various blogs and comments.

I want to talk, instead, about the reaction, response, and behavior of some of the community to the event.

First, I’m well aware that because on the internet no one knows you are a dog, people feel free to behave in ways they never would in person.  I have been as guilty as anyone of this over the years, though I daresay that I like to think that I’ve become self-aware about the issue and been a much  better online citizen over the past few years.  However, being on the internet isn’t an excuse to be rude, offensive, and, well, a jerk.

And frankly, the response to the EULA issue by the Delphi community was shameful.  Seriously.  It wasn’t a rational discussion, it was a witch hunt.  I’ll not weigh in on the issue at all other than to say that I was glad to see Embarcadero respond to the uproar by deciding not to make the change.  And when I expressed that sentiment, I was pretty aggressively attacked for apparently not participating in what I called the “public flogging”.  And then I was aggressively attacked for calling it a public flogging.

And it was a public flogging.  It couldn’t even remotely be described as a professional discussion.  I understand that the proposed but never adopted change would have had a rather profound effect on many people.  But even so, that is simply not an excuse for meanness and vitriol.

Why am I writing this? Well, because I consider David Intersimone one of the finest men I’ve ever known and a good friend.  He is kind, gentle, smart beyond reason, and very, very dedicated to the Delphi community.  And for the Delphi community – whom he has served so well for many, many years – to treat him so badly was, well, very, very painful for me to see.  DavidI didn’t even remotely deserve the treatment he got, and those of you who were so unpleasant to him should be ashamed of yourselves. 

They say “All’s well that ends well”.  The Delphi XE3 EULA controversy apparently is ending well. 

But the Delphi community’s treatment of its longest and dearest friend did not end well at all.

Honored to be an Embarcadero MVP

By Nick at August 26, 2012 14:35
Filed Under: Delphi, General, Personal

I am honored to be included amongst a rather large list of impressive developers as an Embarcadero MVP for Delphi.  The program is still young, and so I’m not entirely sure what it means to be part of it, but whatever it is, I’m honored and pleased to be included, and I’ll do my best to be worthy of that honor. 

There is already a nice perk to the position – the team at DevJet – about whom I can’t say enough nice things  – have given us free versions of all their products forever. That’s a long time!  This is very cool, as I am a big fan of Document Insight, including the new Enterprise version.

I’m looking forward to seeing where this all goes.  So my thanks to all of you and to Embarcadero.

Flotsam and Jetsam #63

By Nick at August 24, 2012 05:38
Filed Under: Delphi, Flotsam and Jetsam

Flotsam and Jetsam #62

By Nick at August 22, 2012 17:36
Filed Under: Flotsam and Jetsam, Software Development, Delphi
  • Okay, so it looks like the release of Delphi XE3 is imminent.  My friend Tim Del Chiaro (the Delphi Insider) has announce the World Tour for the release.  The official page is here.  Tim also mentions something about a new product “HTML5 Builder”.  That sounds interesting.
  • JT, the Product Manager for RAD Studio, has a blog post with more info. I’ve not dabbled much in mobile development yet, so the most interesting part was “by adding memory management features such as automatic reference counting” – that’s very intriguing.  This could add a whole new dimension to the great FreeAndNil debateWinking smile
  • I’m always looking to sell stuff on ebay – so when I put in my new ASUS RT-N16 router, I thought I’d sell the old one.  Apparently, I’m not the only one doing that, as the router that Comcast gave me is worth only about 15 dollars, if that.  They are $40 at Amazon. Oh well.  Winking smile  I was hoping it was worth a bit more.  But hey, $15 is a lot of money, right?
  • I think I’ve said at least 453 times how much I love FinalBuilder.  So I’m always happy to pass along good news about what the folks at VSoft are up to.  Their latest is a very intriguing product called Continua CI, recently released in beta.  It’s a follow on to their FinalBuilder Server product.  I say “follow on” and not “upgrade” because it looks to be something quite a bit different and improved. Robert Love has a good write-up on it as well.    We here at Gateway Ticketing currently use Jenkins in concert with FinalBuilder, but if the licensing for Continua is favorable, it might be something for us to consider.  In any event, I always recommend looking at anything at all from the fine folks at vSoft Technologies.

Cool New Tool: Delphi Code Coverage

By Nick at August 18, 2012 19:27
Filed Under: Delphi, Software Development, Unit Testing

Code Coverage is an interesting topic – Wikipedia defines it as “the degree to which the source code of a program has been tested.”  The idea is that you want to measure what percentage of the lines of code in your application are executed when you run your test suite.  The “perfect” test suite would execute every single line of code in your codebase.  Being able to definitively measure that goes a long way towards validating your testing suite and giving you confidence that your tests are thorough and testing everything that needs to be tested.

So I was really happy to run across the Delphi Code Coverage tool. I was intrigued and interested, so I downloaded it and gave it a look. And I really liked it.  I decided to run it through its paces by checking the code coverage of the unit tests for my THTMLWriter project. It didn’t take me long to figure out how to use it.   It’s written by Christer Fahlgren.  He blogged about it back in 2010.  It has a couple of other committers, and it’s been an active project throughout out 2012

The project includes this note: “The 1.0 release was made possible through the generous support of DevFactory.” I thought that was cool, and so I encourage you to go to their website and check out their services.

Some things to note off the bat:

So what did I do?  Well, first I pulled the source to make sure I had it.  Then, I went ahead and downloaded the RC7 build, which has one file in it:  codecoverage.exe.  I took that file and put it in a folder along my path so I can call it wherever I need it.

Then, I read the nice simple documentation.  I was just testing it out, so I ran everything manually via the IDE just to see how it all worked.  Eventually, you’d want to integrate this into your continuous integration. So here is a quick rundown of what I did and what I found. 

First, I opened up the project options for my THTMLWriter unit test application and told the Linker to create a MAP file for the project when I build it. The tools uses the MAP file to trace all the code paths that the application under test uses.

Next, I looked for the appropriate command  line switches. 

  • I used it –e switch to name the executable that would run. 
  • I used the –m switch to name the *.map file.
  • I used the –u switch to tell the tool what code unit I wanted analyzed.  Note that the switch wants the unit name, not the file name.  You can list as many units as you want after this switch.  Alternatively, you can use the –uf switch to point to a text file that has a list of unit names (one per line) to be examined.  In my case, I’m interested in the code coverage for the uHTMLWriter.pas unit.
  • I used the –html switch to indicate that I wanted the output to be an HTML file.  This would make it easier for me to look at the results in this “by hand” method of running things. 

The resulting command line was as follows:

codecoverage -e HTMLWriterTestAppTests.exe -m -u uHTMLWriter -html

Note that the above command line assumes that the current directory of your command prompt is the directory where the files in question are located.  I actually put the command line in a small batch file in the same directory.

So then I executed the command.  The tool popped up the GUI Runner for DUnit, I pressed the Run button, the tests ran, and when they were done, the tool finished up and produced some output in the form of an HTML file.  (It also provided a FastMM dialog at the end of its run, which took a few seconds to appear).


As noted, the result was two HTML files -- one summary file:


and a file that shows me the coverage for the uHTMLWriter unit.  That has a header in it that tells me that I have 98% code coverage.  Not bad!


But the real fun part is that the file contains a complete listing of the unit, color-coded to indicate which lines were executed (in green) and which weren’t (in purple). So 2% of my code isn’t covered?  So I scanned the file and came across this:


Looks like I never wrote a unit test for the OpenLabel method that takes a string parameter.  (I have one for the parameter-less OpenLabel).  Okay, so I went back, wrote a unit test for that one, and re-ran the code coverage tool, and now I have code coverage for that method:



Nice!  The tool also pointed out that I don’t test that a number of exceptions get properly raised, so I’ll get working on those, too.  I’d like to be able to run the report and have it return 100% for my coverage. 

Overall, this is a nice and powerful tool to help you make sure that your unit tests really are running every line of code in whatever you are unit testing.  It’s another great contribution to the Delphi community.  Thanks, Christer.

Flotsam and Jetsam #61

By Nick at August 11, 2012 15:54
Filed Under: Flotsam and Jetsam, Delphi, Tech Stuff
  • I’ve never been a hardware or network geek, but after I read this post by Jeff Atwood about how easy it was to set up custom firmware on a router a few notches above the “cheap one they basically give you when you sign up for cable internet”, I thought that I might try it some day.  I put the Atwood-recommended Asus RT-N16 on my Amazon wish list, and lo and behold, my parents kindly gave it to me for my birthday in July.  I actually left it sitting on the shelf for a few weeks, unsure if I really wanted to use it until a friend at work told me about Ooma.  Ooma is a phone service that works over your internet connection.  It’s not true VOIP, but similar.  Once you buy the device and get it set up, you basically get free phone service (I guess you pay some taxes or something each month, but only like $4 or something).  The Ooma should save me $50 a month.  Nice.  Anyway, if you have an Ooma, you really need a router that supports Quality of Service so that your phone calls don’t get aced out when your 13 year old starts downloading some huge game or something.  So today, I broke out the router, and used these instructions to flash the firmware on the Asus router, and now I’m up and running with TomatoUSB.  Very cool.   My next step is to buy the Ooma box and get that set up.  I’ll keep you all posted, as I know that you are eager to be updated on every single little thing I do.
  • You know, I just love all the stuff that the folks at DevJet are doing.  First, they are the impetus behind the Delphi Spring Framework, which as far as I am concerned you should treat like part of the Delphi RTL, as well as the really cool tool Documentation Insight.  Now they have release a new product that is the mirror to Documentation Insight – Documentation Generator.   You can pre-order it for 30% off, too.  What does it do?  Well, it takes all those great /// comments/documentation you wrote using Documentation Insight (which, by the way, is bundled with Delphi XE2) and turns it into online content.  For instance, here is the documentation for my HTMLWriter project.  And of course, all the documentation for the Spring4D project is online as well.  Nice.
  • There are some interesting Delphi book projects in the works:
  • Nick’s Opinion of the Week:  I think that if someone wants to open source their software, then they should do so.  And if they don’t want to open source their software, then they shouldn’t. And if you have a different opinion than the author of the software, then you should express it respectfully.  If your “advice” isn’t taken, then you should leave it be.  Just sayin’. 

How Not To Code #2: Don’t Use Boolean Method Parameters

By Nick at August 04, 2012 13:16
Filed Under: Delphi, How Not To Code

Okay, let’s start off with a question.  What do you think this little code snippet does?


Well, I’ll bet your first guess is that it processes customer input.  Good guess!  But what the heck does that False there mean?  It’s a parameter, and presumably it means something is, well, false, or that you don’t want the ProcessCustomerInput to do something, but how can you know?  You can’t.

Using Boolean parameters means that lose information for the reader of your code.  A Boolean parameter communicate nothing about the purpose or meaning of the parameter being passed.  Is False good or bad?  Safe or not safe?  Who knows?  Just as above, you can’t figure out at all what the parameter is supposed to mean or do if all you see is True or False

So if you see that in code, the first thing you’ll probably do is to go to the method declaration, and if the parameter is well named, you might figure out what the parameter does:

procedure ProcessCustomerInput(aKeepDuplicates: Boolean);

So there you go, now you know what the Boolean parameter does – apparently it tells you whether to keep the duplicates or not.  That’s great, but the original coder may not always be so kind and clear.  So if you must use a Boolean parameter, at least make the parameter name descriptive. 

Okay, I take it back – don’t actually ever use a Boolean parameter.  Instead, here’s what I suggest would make for much clearer code:

  TKeepDuplicates = (DoKeepTheDuplicates, DoNotKeepTheDuplicates);

procedure ProcessCustomerInput(aKeepDuplicates: TKeepDuplicates);

and that way you can call


And then your code is eminently readable and clear without having to look up the method declaration.

In addition, this way of doing things is expandable.  If your business rules change, and a third way of processing customer input appears, your code is ready.  With a Boolean parameter, you are stuck with the two options of True and False.

Easy to read, clear, and ready for the future.  Just like code should be.

Flotsam and Jetsam #60

By Nick at July 24, 2012 18:01
Filed Under: Flotsam and Jetsam, Delphi
  • Hey, Flotsam and Jetsam is back!  It’s been a while.  Sorry.
  • The folks at Helpinator are running a Absolutely Insane FireMonkey Demo contest.  I say you should give it a try.
  • Jason Southwell has an interesting project going over at KickStarterNakeyMonkey.  Cool idea.  I’ve heard about Kickstarter, but never really seen it in action. I love the idea – great way to spread the word about good ideas.  Not all good ideas need $15 million in venture capital.   Perhaps you want to get in on the ground floor of the project?
  • Okay, only like two real items, but we will take what we can get for the first Flotsam and Jetsam in quite a while, eh?

It's That Time Again: Gateway Ticketing Needs Delphi Developers

By Nick at July 02, 2012 16:05
Filed Under: Delphi, General, Software Development

My company, Gateway Ticketing, is hiring again. We are looking for Delphi developers. Actually, having Delphi skills is great, but we are mostly interested in smart people that know what they are doing when developing high-quality software.  We love Delphi and C#, but in the end, those are just languages and we know that it doesn’t ultimately matter what tool you know, but whether you really know how to write clean code.

Here are some reasons why you should consider working for Gateway:

  • We are a great place to work.  I love it here.  That this is a great place to work was so obvious to me that I moved my whole family clear across the country to join this team. 
  • We are serious about being serious about software development.  We aren’t messing around here.  While we have a large legacy code base, we are all about doing the right thing the right way with the right tools.  We insist on unit tests for your code.  We insist that you keep up with the latest innovations in writing code.  We insist that you view coding the same way that Rembrandt viewed painting.  
  • We love Delphi, and we live and  breathe it here.  We are doing cool things like using the Delphi Spring Framework, Dependency Injection, Unit Testing, and other fun stuff.
  • We use C# and ASP.NET for our eCommerce solution and all the cool stuff that goes along with that.
  • We are located in beautiful Boyertown, Pennsylvania.  This a great place to live and raise a family.  We are close to everything (including Philadelphia) but have that great small town feel.  I love living here, and you will too.
  • Our customers are some of the greatest and most fun places on earth.  We sell systems to the largest amusement parks, zoos, water parks, and museums all over the world.  This is a cool industry.  Who doesn’t love a good amusement park?

Okay, look – everyone says they want to hire “rock-star developers”.  Shoot, even we do it.  That’s all well and good, but the bottom line is that we are setting our standards really high.  And if doing that scares people off, well so be it.  We don’t want people who are scared off by high standards.  We want people who are looking for places with high standards.  We expect and demand your very best – anything less and you should find a job writing VB6 code. ;-) We really are creating a world-class place to build software, and we want folks like you to be a part of it.  You are up for that, right?

Relocation assistance is available.

And of course, here are the obligatory caveats.  We are definitely looking for people to live and work here in the Eastern Pennsylvania/Greater Philadelphia area.  Please note: we aren’t currently considering remote workers.  Naturally, you must be eligible to work in the United States. I'm sorry but right now we cannot sponsor H1B visas. :-(  We don’t care where you are from or who your parents were or what color your dog is or anything like that.  We are really only interested in what you can do.  And of course, we want you to know what we can do for you, too.

If that sounds like something good to you, please contact me.

TVirtualInterface: A Truly Dynamic and Even Useful Example

By Nick at June 30, 2012 17:25
Filed Under: Delphi, Software Development, Unit Testing


This is the third article in a series about using TVirtualInterface.  The two previous articles are TVirtualInterface: Interfaces without an Implementing Class and TVirtualInterface: Next Steps.

Okay, enough with the not-all-that-useful examples.  I mean, the previous articles were illustrative, but not really “real-world useful”.

The true usefulness of TVirtualInterface occurs when you use it to create code where you have no idea what interface the user of your code is going to try to implement.  All the examples so far have shown only implementing classes where you do know which interface is being used.  The exception so far is the TReportingVirtualInterface example which reports information on any interface you pass to it.  Since we have proven that you can use TVirtualInterface to do something useful, let’s take it a step further.

A practical use of TVirtualInterface is to create a mocking library for unit testing.  I’ve mentioned numerous times the Delphi Mocks Framework by Vince Parrett of FinalBuilder fame.  Another excellent implementation of a mocking framework (as well as a bunch of other very innovative and interesting stuff) is by Stefan Glienke as part of his Delphi Sorcery framework.  Both of these use TVirtualInterface to provide a mock implementation for any interface (though the Delphi Sorcery code implements its own version of TVirtualInterface that works with Delphi XE – very cool).  Both, of course, allow you to pass them any interface, and they’ll happily mock your interface for unit testing purposes.  So why not do an example here of a very simple mocking object that you can actually use if you want?


A while back I wrote an article called The Vocabulary of Unit Testing.  In it I described the distinction between a stub and a mock.  I defined a “stub” as “a fake that has no effect on the passing or failing of the test, and that exists purely to allow the test to run.”  So, how about we build a universal stub – a class that can pretend to be any interface you want, and not do anything at all.  That can’t be that tough, can it?

Well, we already have a class that can implement an interface, but we need to find a way for that class to actually be the interface.  If you want a stub, the stub has to actually be the interface type you are trying to stub out, right?

First, since we always code against abstractions, let’s declare an interface:

  ISimpleStub<T> = interface
    function InterfaceToCall: T;

And then let’s implement it with a descendent of TVirtualInterfaceEx<T>:

  TSimpleStub<T: IInvokable> = class(TVirtualInterfaceEx<T>, ISimpleStub<T>)
    procedure DoInvokeImpl(Method: TRttiMethod;  const Args: TArray<TValue>; out Result: TValue); override;
    function InterfaceToCall: T;

Because TSimpleStub<T> descends from TVirtualInterfaceEx<T>, it can implement any interface you pass to it.  It thus overrides DoInvokeImpl from  TVirtualInterfaceEx<T> as well as implementing InterfaceToCall from ISimpleStub<T>.

First, let’s look at DoInvokeImpl:

procedure TSimpleStub<T>.DoInvokeImpl(Method: TRttiMethod; const Args: TArray<TValue>; out Result: TValue);
  // Since this is a pure stub, don't do anything!

Not much to see here  – it doesn’t do anything.  And for a stub, that is fine.  That’s exactly what stubs are supposed to do – nothing.  We don’t care what happens when the methods get called, you just need to actually be able to call them.

That’s where the InterfaceToCall function comes in.  The class knows about the type of interface being stubbed because we are passing that type in as a parameterized type.  The class itself knows how to implement that interface.  There has to be a way to get an actual reference to that implemented interface, right?  This is where the InterfaceToCall method comes in:

function TSimpleStub<T>.InterfaceToCall: T;
  pInfo : PTypeInfo;
  pInfo := TypeInfo(T);
  if QueryInterface(GetTypeData(pInfo).Guid, Result) <> 0 then
    raise Exception.CreateFmt('Sorry, TSimpleStub<T> is unable to cast %s to its interface ', [string(pInfo.Name)]);

Since TSimpleStub<T> knows the type that T is, you can call QueryInterface on the type information about T itself to get a reference to the interface in question.  And of course, once you have that, you can pass that reference anywhere you need to stub out the interface – normally as part of unit testing.

So now, you can safely call methods on the stubbed interface.  For instance, given this interface:

IActuallyUseful = interface(IInvokable)
  procedure SayHello;
  function ReverseString(aString: string): string;
  function Multiply(x, y: integer): integer;

Writeln('Implementing a TSimpleStub');
SimpleStub := TSimpleStub<IActuallyUseful>.Create;
WriteLn('Nothing should appear between this and the next statement');
SimpleStub.InterfaceToCall.Multiply(4, 4);
WriteLn('Nothing should appear between this and the above statement');

Nothing happens when you call the interface methods, but that’s by design:  stubs should do nothing.  What you can do is call them as part of your unit testing:

  MyClassUnderTest := TSprocketThatTakesAnIWhatever.Create(SimpleStub.InterfaceToCall)


Okay, so there’s a useful, dynamic way to use TVirtualInterfaceTSimpleStub<T> will work great for a stub that you expect absolutely nothing from.  But sometimes you need a fake interface that does something more than just existing, and when that is the case, you are creating a mock.  In my unit testing definitions article, I defined a mock as “a fake that keeps track of the behavior of the Class Under Test and passes or fails the test based on that behavior.”  Thus, a mock needs to do more than exist like a stub –  it needs to behave in a way that you can define.   So how about we take TSimpleMock<T> and make it do a basic mocking function – responding in a specific way to a specific input.

One of the most common things that a mock interface does is to respond with “this” when passed “that”.  How about we create a simple mock class that lets you define a specific response to a method call?

First, of course, is an interface to code against:


  ISimpleMock<T> = interface(ISimpleStub<T>)
    procedure AddExpectation(aCallName: string; aReturnValue: TValue);

The interface augments (“inherits from” is not quite right with interfaces) ISimpleStub<T> and adds the AddExpectation method.  This is the method that we’ll use to tell the mock out to respond when and interface method gets called. 

Here’s the implementing class:

  TSimpleMock<T: IInvokable> = class(TSimpleStub<T>, ISimpleMock<T>)
    FActions: TDictionary<string, TValue>;
    procedure DoInvokeImpl(Method: TRttiMethod;  const Args: TArray<TValue>; out Result: TValue); override;
    constructor Create;
    destructor Destroy; override;
    procedure AddExpectation(aCallName: string; aReturnValue: TValue);

The first thing to notice is that TSimpleMock<T> inherits  from TSimpleStub<T>, thus enabling it to “be” any interface it wants as our stub was. And of course it also implements the  AddExpection method.  It takes as parameters the name of the method on the interface that you can call, as well as a return value for when that method gets called.  In this way you can define the behavior of the mock class however you want.

This very simple mocking example assumes that you are going to be mocking only function calls as methods on an interface. Within the confines of our simple example, it doesn’t make sense to mock procedures – they basically don’t do anything as far as the simple example is concerned.  Real mock frameworks are able to keep track of whether a procedure is called, how many times it does get called, and other things associated with procedures.  This simple example also doesn’t care what parameters you pass in, it will merely return a value whenever the named method is called.   Remember, this is a simple – but useful in specific situations -- example.  Winking smile 

The implementation of TSimpleMock<T> is pretty, well, simple.  Internally, it uses a TDictionary<TKey, TValue> to keep track of the method calls and the resulting responses that are added via the AddExpectation call.  Here is the implementation of AddExpectation :

procedure TSimpleMock<T>.AddExpectation(const aCallName: string; aReturnValue: TValue);
  FActions.Add(aCallName, aReturnValue);

When you add an expectation, the class keeps track of it.  When you then call that method on the interface, it is able to retrieve the expected return value from the dictionary and return it:

procedure TSimpleMock<T>.DoInvokeImpl(Method: TRttiMethod; const Args: TArray<TValue>; out Result: TValue);
  Result := FActions[Method.Name];

(The obvious shortcoming here is no error handling – you’ll get an exception if you try to call a method on the interface that doesn’t  have an expectation entry.  Another shortcoming is that the parameters passed mean nothing – a real mocking framework would be able to provide specific responses for specific parameter inputs.    I’ll leave correcting this problem as an exercise to the reader.  Smile )

So now, when we exercise this class, it will actually return stuff that you tell it to:

This code:

WriteLn('IActuallyUseful with ISimpleMock');
SimpleMock := TSimpleMock<IActuallyUseful>.Create;
SimpleMock.AddExpectation('Multiply', 99);
SimpleMock.AddExpectation('ReverseString', 'This is actually working');
WriteLn(SimpleMock.InterfaceToCall.Multiply(6, 7));
WriteLn(SimpleMock.InterfaceToCall.ReverseString('This does not matter'));

has the following output:


Note that the responses are not what you think they would be based on the parameters (you think that 6 times 7 would return 42…), but what you told them to be in the AddExpectation call.

Now, you can use ISimpleMock<T> to provide specific feedback for a given method call.  Maybe you have an interface method which returns a Boolean value that you want to test. You can use ISimpleMock<IBooleanMethod> to test what happens when the method returns True as well as when that method returns False


Okay, so there you have it:  A useful implementation of TVirtualInterface.  Though the above examples are really simple, they can actually be used in real world testing – particularly the ISimpleStub<T> implementation. Stubbing is common in unit testing, and even though it is a very basic implementation, it can be used to stub out any interface.

None of this is useful if you know what interface you need and how you are going to implement it.  But there are cases when you don’t know what interface you will need for a particular problem, and you need to be able to flex to whatever interface the situation calls for.  Mocking and stubbing are perfect examples.  That’s a powerful and useful thing to be able to do.  Hopefully this little series has helped you see that.

TVirtualInterface: Next Steps

By Nick at June 14, 2012 06:48
Filed Under: Delphi, Software Development

Okay, so my last article was pretty fun – you got a look at TVirtualInterface and how you can use it to implement any interface.  Now, I want to be clear – the code in that article was demo code.  That is, it was purely for illustrative purposes.  I can’t think of any reason why you’d actually, in the real world, implement an interface that way. But after reading it, you should be able to see how TVirtualInterface works and how you can get it to do what you want. 

Now, in that article I promised you that my next blog post on the topic would be an example of using TVirtualInterface in a more useful manner.  But I guess I lied, because this blog post is about how you can create a slightly better version of TVirtualInterface.

So a while back, I wrote a post about getting you to “think generically” and how generics (or as I prefer to think of them, parameterized types) are useful in more ways than just collections and lists.   Well, I got to looking at TVirtualInterface and I thought, “You know, here’s a class that actually requires type information about a given type, and in order for it to do anything useful, you have to give it a type in the constructor, so hmmm…….”.  And you can guess where I went from there. 

So, consider the following class declaration:


  TVirtualInterfaceEx<T: IInvokable> = class(TVirtualInterface)
    procedure DoInvoke(Method: TRttiMethod;  const Args: TArray<TValue>; out Result: TValue);
    procedure DoInvokeImpl(Method: TRttiMethod;  const Args: TArray<TValue>; out Result: TValue); virtual; abstract;
    constructor Create;

This is a pretty simple descendent for TVirtualInterface.  The most obvious thing is that it takes a parameterized type T which is constrained to be an interface descending from IInvokable.  That enables you to explicitly declare what interface TVirtualInterfaceEx is going to implement.  You should notice, too that TVirtualInterfaceEx is an abstract class, as the DoInvokeImpl method is abstract.

So, once you have the parameterized type, you know everything you need to implement the interface.  As you know from the previous article, the thing you need to do is to provide an implementation of DoInvoke.  So TVirtualInterfaceEx employs the technique I’ve described before whereby you implement the interface in the base class and provide a “real” implementation in a separate method invoked by the base class.  So, the implementation looks like this:

constructor TVirtualInterfaceEx<T>.Create;
  inherited Create(TypeInfo(T), DoInvoke);

procedure TVirtualInterfaceEx<T>.DoInvoke(Method: TRttiMethod;  const Args: TArray<TValue>; out Result: TValue);
  DoInvokeImpl(Method, Args, Result);

The constructor is pretty simple – it is parameter-less and  calls a sibling constructor, passing in the TypeIinfo for your interface and the DoInvoke method which is of type TVirtualInterfaceInvokeEvent.  The code for DoInvoke method simply calls the DoInvokeImpl method, which, because it is abstract, descendent classes must override.

Thus, to use this class, all you need to do is to descend from it and provide an interface as a parameterized type and an implementation for DoInvokeImpl.   So, if we wanted to implement the IActuallyUseful interface from the previous example, all we need to do is:

  TActuallyUsefulEx = class(TVirtualInterfaceEx<IActuallyUseful>)
    procedure DoInvokeImpl(Method: TRttiMethod;  const Args: TArray<TValue>; out Result: TValue); override;

implementing DoInvokeImpl with the same code that was in the DoInvoke event of the TActuallyUseful class. 

By the way, I should mention that the code for these demos on TVirtualInterface, including a sneak peek at the code for the next article, is available as part of my demo code project on BitBucket.

This isn’t anything really fancy, but I liked it because it simplified the process of creating virtual interface implementations and provided another example of a good use for parameterized types.  I also like what I mentioned previously, that it clearly declares what interface it is implementing.

Anyway, I thought it was a cool little wrapper/descendent for the TVirtualInterface class.  And I promise that the next blog post on this stuff will show an example of using it in a truly dynamic way.

TVirtualInterface: Interfaces without an Implementing Class

By Nick at June 10, 2012 14:37
Filed Under: Delphi, Software Development

I would be really disappointed if we spent an hour discussing software development and I didn’t at least once say to you "Program against interfaces, not against implementations".  It’s sort of a mantra for me – a way of life if you will.  It’s a bedrock principle of development as far as I’m concerned. Programing against interfaces and not against implementations is the only way to truly decouple your code.  And if you don’t believe that decoupling your code is important, I’d like you to stop reading right now, get a small ball-peen hammer, and keep hitting yourself in the forehead until you change your mind.

So if you’ve made it this far, you’ll know that implementing interfaces is needed to use them.  You have to put some code behind an interface to make it do anything.  Normally, this is done with an implementing class:

  ISprocketProcessor = interface
    procedure ProcessSprockets;

  TSprocketProcessor = class(TInterfacedObject, ISprocketProcessor)
    procedure ProcessSprockets;

But what if you could implement an interface without having a specific class?  What if there were a way to implement any interface with a single module of code? What if you could decide at runtime how to implement an interface?  Would I even be asking these questions and writing this if those things weren’t possible?

So, yes, obviously it is.  Delphi XE2 introduces a very cool new class called TVirtualInterface. Its purpose is to allow you to descend from it and respond to any interface dynamically.  If you think about that for a second you’ll realize that this is pretty powerful. For instance, it’s the thing that lets the awesome Delphi Mocks Framework provide a mock implementation of any interface that you pass to it.

Generally, when you implement an interface, you provide a class that implements it in a specific way – i.e. that implementation becomes static at runtime. There are ways – typically via Dependency Injection – that allow you to choose an implementation, but even then you are limited to a specific set of implementations.   TVirtualInterface allows you to dynamically -- i.e. at runtime – determine how an interface will be implemented.  The examples in this article will show a fixed way to implement TVirtualInterface so you can get the basics of how to use TVirtualInterface.  In a future article, we’ll look at more dynamic ways to use this sweet class.

Here’s the public interface for TVirtualInterface:

  { TVirtualInterface: Creates an implementation of an interface at runtime.
    All methods in the Interface are marshaled through a generic stub function
    that raises the OnInvoke event.}
  TVirtualInterface = class(TInterfacedObject, IInterface)
    function QueryInterface(const IID: TGUID; out Obj): HResult; virtual; stdcall;
    { Create an instance of TVirtualInterface that implements the methods of
      an interface.  PIID is the PTypeInfo for the Interface that is to be
      implemented. The Interface must have TypeInfo ($M+). Either inherit from
      IInvokable, or enable TypeInfo for the interface. Because this is an
      TInterfacedObject, it is reference counted and it should not be Freed directly.
    constructor Create(PIID: PTypeInfo); overload;
    constructor Create(PIID: PTypeInfo; InvokeEvent: TVirtualInterfaceInvokeEvent); overload;
    destructor Destroy; override;
    { OnInvoke: Event raised when a method of the implemented interface is called.
      Assign a OnInvoke handler to perform some action on invoked methods.}
    property OnInvoke: TVirtualInterfaceInvokeEvent read FOnInvoke write FOnInvoke;

First, you should notice that TVirtualInterface descends from TInterfacedObject and implements IInterface.  The three methods of IInterface are implemented to allow the class to be properly reference counted like any other interface-implementing class.  Second, the interface that you want to implement with it needs to have TypeInfo enabled for it.  The easiest way to make that happen is to descend your interface from IInvokable.  Otherwise, you’ll need to use the {$M+} switch for your interface. Notice, too, that the comment above the class declaration says what I said early – using TVirtualInterface will let you, well, do anything you want with an interface at runtime.  Cool. 

So, in order to actually make TVirtualInterface do something, you need to create a descendent class and provide two things:  a constructor and an implementation of the DoEvent method.

Here’s an TVirtualInterface descendent that is as simple an example as I could think of:

  TSimplestVirtualInterface = class(TVirtualInterface)
    constructor Create(PIID: PTypeInfo);
    procedure DoInvoke(Method: TRttiMethod;  const Args: TArray<TValue>; out Result: TValue);

constructor TSimplestVirtualInterface.Create(PIID: PTypeInfo);
  inherited Create(PIID, DoInvoke);

procedure TSimplestVirtualInterface.DoInvoke(Method: TRttiMethod;
  const Args: TArray<TValue>; out Result: TValue);
  WriteLn('You called a method on an interface');

The only thing this will do is to write out to the console – no matter what.  You can pretend it implements any interface, and no matter what you call on that interface, it will merely write to the console. 

The constructor takes a single parameter, PIID, which is is the TypeInfo for the interface you want to “implement”.  (That’s why the interface in question must have the {M+} switch – usually via IInvokable.)  Inside the constructor, a call to a different constructor is made.  The PIID parameter is passed in, as is a reference to DoInvoke, which is a method that matches the type TVirtualInterfaceInvokeEvent.  Thus, the constructor is basically saying “Here is the type of information for the interface I’m implementing, and the method you should run whenever a method is called on that interface.”

In our case, the DoInvoke method only does one thing no matter what – writes to the console.

So, for instance, say you declare an interface:

  IGoStop = interface(IInvokable)
    procedure Go;
    procedure Stop(aInteger: integer);

And then you run the following code in a console application:

   GoStop := TSimplestVirtualInterface.Create(TypeInfo(IGoStop)) as IGoStop;

the console output will look like this:



You see the output twice because the code called two methods.  It doesn’t matter what you call – that output will happen no matter what.  It doesn’t matter what interface you pass in or what method you call, the result will be the same.

But of course that isn’t useful – to be of any use, you need to be able to know what is getting called, what is getting passed in, and respond accordingly.

Well, you can do that, because if you look at the signature of the DoInvoke method, you’ll note that when it gets called by the TVirtualInterface.OnInvoke event, it gets passed the RTTI for the method that was called, an array of TValue that contain the interface itself and all the arguments that the method was passed, as well as an out parameter of type TValue that allows you to return a value if the method being called is a function. 

So how about we simply use the DoInvoke event to report out what all that information that it receives.

procedure TReportingVirtualInterface.DoInvoke(Method: TRttiMethod;
  const Args: TArray<TValue>; out Result: TValue);
  Arg: TValue;
  ArgType, ArgName: string;
  TempKind: TTypeKind;
  Write('You called the ', Method.Name, ' method ');
  if Length(Args) > 1 then
    Writeln('and it has ', Length(Args) - 1,' parameters:');
    for Arg in Args do
      TempKind := Arg.Kind;
      if TempKind <> tkInterface then
        ArgName := Arg.ToString;
        ArgType := Arg.TypeInfo.Name;
        Writeln(ArgName, ' which is of the type ', ArgType);
  end else
    Writeln(' and it has no parameters.');

This code simply looks over and reports out about the Method and Args parameters that get passed in when the interface is invoked.  The very first item in the array is always type information about the interface itself, and the rest are the parameters, in order, as they were passed in.  Here, the code simply reports out their values and types, but of course, you can process them as you please. 

Again, that is interesting information, but it’s just a step towards understanding how TVirtualInferface works.  Let’s create something that actually does what we want it to.

Here’s a basic interface:

  IActuallyUseful = interface
    procedure SayHello;
    function ReverseString(aString: string): string;
    function Multiply(x, y: integer): integer;

Then, below is the DoInvoke method for a TActuallyUseful class that will actually do what the interface purports to do:

procedure TActuallyUseful.DoInvoke(Method: TRttiMethod;
  const Args: TArray<TValue>; out Result: TValue);
  if UpperCase(Method.Name) = 'SAYHELLO' then
    WriteLn('Hello World!');
  end else
    if UpperCase(Method.Name) = 'REVERSESTRING' then
      Result := ReverseString(Args[1].AsString)
    end else
      if UpperCase(Method.Name) = 'MULTIPLY' then
          Result := Args[1].AsInteger * Args[2].AsInteger;
      end else
        raise Exception.Create('Bad Parameter name was passed in to the DoInvoke method');

This code should be fairly self-explanatory.  It simply checks for the name of the method that was called, and then executes code using the parameter information passed in the Args parameter.  If the call is a function, the Result parameter is used to return a value.   

You should  remember that the initial item in the Args array (that is, the one at the “zero-eth” position) is the interface type itself.  The code also makes assumptions about the number and types of the parameters.  Since the code can only be invoked by the methods declared on IActuallyUseful interface, the code can make safe assumptions about the types and order of the parameters.

Now all of this code above is fairly straight-forward – we are basically simulating an implementing class in our examples.  Nothing is truly dynamic.  The code here merely shows simple examples of how TVirtualInterface works in a fairly static way. You should now be able to see how you could dynamically implement an interface using a TVirtualInterface descendent.

Coding against interfaces is critical for writing good, clean code.  TVirtualInterface is just another powerful tool in your toolbox for doing just that.

Fun Code of the Week #4

By Nick at June 08, 2012 15:14
Filed Under: Delphi, Fun Code

Adapted from my answer on StackOverflow:

function RemoveChars(const aString: string; aCharsToRemove: TSysCharSet): string;
  C: Char;
  Result := '';
  for C in aString do
    if not CharInSet(C, aCharsToRemove) then
      Result := Result + C;

My Book

A Pithy Quote for You

"Always be a first-rate version of yourself, instead of a second-rate version of somebody else."    –  Judy Garland

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.

Month List