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

TVirtualInterface: A Truly Dynamic and Even Useful Example

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

Introduction

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?

ISimpleStub

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
  ['{6AA7C2F0-E62F-497B-9A77-04D6F369A288}']
    function InterfaceToCall: T;
  end;

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

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

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);
begin
  // Since this is a pure stub, don't do anything!
end;

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;
var
  pInfo : PTypeInfo;
begin
  pInfo := TypeInfo(T);
  if QueryInterface(GetTypeData(pInfo).Guid, Result) <> 0 then
  begin
    raise Exception.CreateFmt('Sorry, TSimpleStub<T> is unable to cast %s to its interface ', [string(pInfo.Name)]);
  end;
end;

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)
  ['{16F01BF0-961F-4461-AEBE-B1ACB8D3F0F4}']
  procedure SayHello;
  function ReverseString(aString: string): string;
  function Multiply(x, y: integer): integer;
end;

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

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:

begin
  ...
  MyClassUnderTest := TSprocketThatTakesAnIWhatever.Create(SimpleStub.InterfaceToCall)
  ...
end;

TSimpleMock

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>)
  ['{9619542B-A53B-4C0C-B915-45ED140E6479}']
    procedure AddExpectation(aCallName: string; aReturnValue: TValue);
  end;

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>)
  private
    FActions: TDictionary<string, TValue>;
  protected
    procedure DoInvokeImpl(Method: TRttiMethod;  const Args: TArray<TValue>; out Result: TValue); override;
  public
    constructor Create;
    destructor Destroy; override;
    procedure AddExpectation(aCallName: string; aReturnValue: TValue);
  end;

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);
begin
  FActions.Add(aCallName, aReturnValue);
end;

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);
begin
  Result := FActions[Method.Name];
end;

(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'));
WriteLn;

has the following output:

image

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

Conclusion

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:

type

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

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;
begin
  inherited Create(TypeInfo(T), DoInvoke);
end;

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

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>)
  protected
    procedure DoInvokeImpl(Method: TRttiMethod;  const Args: TArray<TValue>; out Result: TValue); override;
  end;

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:

type
  ISprocketProcessor = interface
    procedure ProcessSprockets;
  end;

  TSprocketProcessor = class(TInterfacedObject, ISprocketProcessor)
    procedure ProcessSprockets;
  end;

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)
 ...
  public
    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;
  end;

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:

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

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

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

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:

type
  IGoStop = interface(IInvokable)
  ['{3B2171B0-D1C3-4A8C-B09E-ACAC4D625E57}']
    procedure Go;
    procedure Stop(aInteger: integer);
  end;

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

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

the console output will look like this:

image

 

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);
var
  Arg: TValue;
  ArgType, ArgName: string;
  TempKind: TTypeKind;
begin
  Write('You called the ', Method.Name, ' method ');
  if Length(Args) > 1 then
  begin
    Writeln('and it has ', Length(Args) - 1,' parameters:');
    for Arg in Args do
    begin
      TempKind := Arg.Kind;
      if TempKind <> tkInterface then
      begin
        ArgName := Arg.ToString;
        ArgType := Arg.TypeInfo.Name;
        Writeln(ArgName, ' which is of the type ', ArgType);
      end;
    end;
  end else
  begin
    Writeln(' and it has no parameters.');
  end;
end;

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:

type
  IActuallyUseful = interface
  ['{16F01BF0-961F-4461-AEBE-B1ACB8D3F0F4}']
    procedure SayHello;
    function ReverseString(aString: string): string;
    function Multiply(x, y: integer): integer;
  end;

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);
begin
  if UpperCase(Method.Name) = 'SAYHELLO' then
  begin
    WriteLn('Hello World!');
  end else
  begin
    if UpperCase(Method.Name) = 'REVERSESTRING' then
    begin
      Result := ReverseString(Args[1].AsString)
    end else
    begin
      if UpperCase(Method.Name) = 'MULTIPLY' then
      begin
          Result := Args[1].AsInteger * Args[2].AsInteger;
      end else
      begin
        raise Exception.Create('Bad Parameter name was passed in to the DoInvoke method');
      end;
    end;
  end;
end;

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;
var
  C: Char;
begin
  Result := '';
  for C in aString do
  begin
    if not CharInSet(C, aCharsToRemove) then
    begin
      Result := Result + C;
    end;
  end;
end;

The Vocabulary of Unit Testing

By Nick at May 03, 2012 23:20
Filed Under: Delphi, Software Development, Unit Testing

I talk a lot about unit testing.  And why shouldn’t I?  Unit testing is the key to writing clean, maintainable code.  If you concentrate on writing code that is easily testable, you can’t help but end up with decoupled, clean, high-quality code that is easy to maintain.  What’s not to like?

But sometimes, there are questions over the definition of terms when it comes to unit testing.  For instance, what, exactly, is a “unit”?  What does “mocking” mean?  How do I know whether I actually am doing unit testing?  In this article, I try to clear up some of those definitions.

What is a “Unit”?

The first question that comes up when discussing unit testing is, well, what is a unit?  You can’t do unit testing without knowing what a unit is.

When it comes to unit testing, I view a “unit” as any discreet  module of code that can be tested in isolation.  It can be something as simple as a stand-alone routine (think StringReplace or IncMonth), but normally it will be a single class and its methods.  A class is the basic, discrete code entity of modern languages. In Delphi, classes (and records which are conceptually very similar) are the base building blocks of your code.  They are the data structures that, when used together, form a system. 

In the world of unit testing, that class is generally referred to as the “Class Under Test (CUT)” or the “System Under Test”.  You’ll see those terms used extensively – to the point where it is strongly recommended that you use CUT as the variable name for your classes being tested.

Definition:  A unit is any code entity that can be tested in isolation, usually a class. 

Am I Actually Doing Unit Testing?

So when you are doing unit testing, you are generally testing classes. (And for the sake of the discussion, that will be the assumption hereafter…)  But the key thing to note is that when unit testing a class, you are unit testing the given class and only the given class.   Unit testing is always done in isolation – that is, the class under test needs to be completely isolated from any other classes or any other systems.  If you are testing a class and you need some external entity, then you are no longer unit testing.  A class is only “testable” when it’s dependencies can be and are “faked'”, and thus tested without any of its real external dependencies.  So if you are running what you think is a unit test, and that test needs to access a database, a file system, or any other external system, then you have stopped doing unit testing and you’ve started doing integration testing. 

One thing I want to be clear about:  There’s no shame in doing integration testing.  Integration testing is really important and should be done.  Unit testing frameworks are often a very good way to do integration testing.  I don’t want to leave folks with the impression that because integration is not unit testing, you shouldn’t be doing it – quite the contrary.   Nevertheless, it is an important distinction.  The point here is to recognize what unit tests are and to strive to write them when it is intended to write them. By all means, write integration tests, but don’t write then in lieu of unit testing. 

Think of it this way:  Every unit test framework – DUnit included – creates a test executable.  If you can’t take that test executable and run it successfully on your mother’s computer in a directory that is read only, then you aren’t unit testing anymore. 

Definition: Unit testing is the act of testing a single class in isolation, completely apart from any of it’s actual dependencies.

Definition: Integration testing is the act of testing a single class along with one or more of its actual external dependencies.

What is an Isolation Framework?

Commonly, developers have used the term “mocking framework” to describe code that provides faking services to allow classes to be tested in isolation.  However, as we’ll see below, a “mock” is actually a specific kind of fake class, along with stubs.  Thus, it is probably more accurate to use the term “Isolation Framework” instead of “Mocking Framework”.  A good isolation framework will allow for the easy creation of both types of fakes – mocks and stubs. 

Fakes allow you to test a class in isolation by providing implementations of dependencies without requiring the real dependencies. 

Definition: An isolation framework is a collection of code that enables the easy creation of fakes. 

Definition: A Fake Class is any class that provides functionality sufficient to pretend that it is a dependency needed by a class under test.  There are two kind of fakes – stubs and mocks.

If you really want to learn about this stuff in depth, I strongly recommend you read The Art of Unit Testing: With Examples in .Net by Roy Osherove.  For you Delphi guys, don’t be scared off by the C# examples -- this book is a great treatise on unit testing, and gives plenty of descriptions, proper techniques, and definitions of unit testing in far more detail than I’ve done here.  Or, you can listen to Roy talk to Scott Hanselman on the Hanselminutes podcast.  I openly confess that this blog post is a faint echo of the great stuff that is included in both the book and the podcast.  If you really want to get your geek on, get a hold of a copy of xUnit Test Patterns: Refactoring Test Code by Gerard Meszaros.  This heavy tome is a tour de force of unit testing, outlining a complete taxonomy of tests and testing patters.  It’s not for the faint of heart, but if you read that book, you’ll know everything there is to know and then some. 

Stubs

A stub is a class that does the absolute minimum to appear to be an actual dependency for the Class Under Test.  It provides no functionality required by the test, except to appear to implement a given interface or descend from a given base class.  When the CUT calls it, a stub usually does nothing.  Stubs are completely peripheral to testing the CUT, and exist purely to enable the CUT to run.  A typical example is a stub that provides logging services.  The CUT may need an implementation of, say, ILogger in order to execute, but none of the tests care about the logging.  In fact, you specifically don’t want the CUT logging anything.  Thus, the stub pretends to be the logging service by implementing the interface, but that implementation actually does nothing.  It’s implementing methods might literally be empty.  Furthermore, while a stub might return data for the purpose of keeping the CUT happy and running, it can never take any action that will fail a test.  If it does, then it ceases to be a stub, and it becomes a “mock”.

Definition: A stub is a fake that has no effect on the passing or failing of the test, and that exists purely to allow the test to run.

Mocks

Mocks are a bit more complicated.  Mocks do what stubs do in that they provide a fake implementation of a dependency needed by the CUT.  However, they go beyond being a mere stub by recording the interaction between itself and the CUT.  A mock keeps a record of all the interactions with the CUT and reports back, passing the test if the CUT behaved correctly, and failing the test if it did not.  Thus, it is actually the Mock, and not the CUT itself, the determines if a test passes or fails.

Here is an example – say you have a class TWidgetProcessor.  It has two dependencies, an ILogger and an IVerifier.  In order to test TWidgetProcessor, you need to fake both of those dependencies.  However, in order to really test TWidgetProcessor, you’ll want to do two tests – one where you stub ILogger and test the interaction with IVerifier, and another where you stub IVerifier and test the interaction with ILogger.  Both require fakes, but in each case, you’ll provide a stub class for one and a mock class for the other. 

Let’s look a bit closer at the first scenario – where we stub out ILogger and use a mock for IVerifier.  The stub we’ve discussed – you either write an empty implementation of ILogger, or you use an isolation framework to implement the interface to do nothing.  However, the fake for IVerifier becomes a bit more interesting – it needs a mock class.  Say the process of verifying a widget takes two steps – first the processor needs to see if the widget is in the system, and then, if it is, the processor needs to check if the widget is properly configured.  Thus, if you are testing the TWidgetProcessor, you need to run a test that checks whether TWidgetProcessor makes the second call if it gets True back from the first call.  This test will require the mock class to do two things:  first, it needs to return True from the first call, and then it needs to keep track of whether or not the resulting configuration call actually gets made.  Then, it becomes the job of the mock class to provide the pass/fail information – if the second call is made after the first call returns True, then the test passes; if not, the test fails.  This is what makes this fake class a mock:  The mock itself contains the information that needs to be checked for the pass/fail criteria.

Definition: A mock is a fake that keeps track of the behavior of the Class Under Test and passes or fails the test based on that behavior.

Most isolation frameworks include the ability to do extensive and sophisticated tracking of exactly what happens inside a mock class. For instance, mocks can not only tell if a given method was called, it can track the number of times given methods are called, and the parameters that are passed to those calls.  They can determine and decide if something is called that isn’t supposed to be, or if something isn’t called that is supposed to be.  As part of the test setup, you can tell the mock exactly what to expect, and to fail if that exact sequence of events and parameters are not executed as expected.  Stubs are fairly easy and straightforward, but mocks can get rather sophisticated.

I’ve written about the Delphi Mocks framework in a previous post.  It takes advantage of some cool new RTL features in Delphi XE2.  It’s also a very generous and awesome gift to the Delphi community from Vince Parrett, who makes the very awesome FinalBuilder. If you have XE2 and are doing unit testing, you should get Delphi Mocks and use it.  If you don’t have XE2 and are doing unit testing, you should upgrade so you can start using this very valuable isolation framework.

But again, the whole point here is to test your classes in isolation; you want your CUT to be able to perform its duties without any outside, real, external dependencies.

Thus, a final definition:  Unit testing is the testing of a single code entity when isolated completely from its dependencies. 

Fun Code of the Week #3

By Nick at May 01, 2012 17:44
Filed Under: Fun Code, Delphi
procedure ShowHourGlass(Proc: TProc);
begin
  Screen.Cursor := crHourGlass;
  try
    Proc;
  finally
    Screen.Cursor := crDefault;
  end;
end;

Tweet Expansion: Butt Time and Brain Time

By Nick at April 29, 2012 17:53
Filed Under: Delphi, Leadership, Software Development, Tweet Expansion

A while back I tweeted the following:

In software development, we often measure Butt Time, when what we need from developers is Brain Time -- which is much harder to measure.

Some tweets call for further explanation and expansion, and so I’ve added a new category called Tweet Expansion to cover posts that do just that.

Here at Gateway Ticketing, we have an interesting development and business model.  At our core, we are an ISV.  We sell a software package that we build to customers.  But, we also will customize our software to meet customer specifications.  That makes us sort of a VAR to our own product.  Thus, we do both enhancements based on customer requests and our own internal product development projects to make our product more valuable in the marketplace. 

This distinction – between internal projects and projects driven by specific customer requirements – makes for some challenging project management.  But we have a solid team here at Gateway, and we make it all work.  But because we do work that amounts to us being consultants, we end up having to closely track our developer time.  We do that for a number of business reasons, the main one, of course, is profitability.  You need to track your time to ensure that you are actually making money on a given endeavor.

Now I know that no one really likes to track their time.  It’s a pain.  It’s challenging to be accurate.  It’s hard to get time properly categorized.  But it is also invaluable for making those important business decisions. 

But there is a bigger problem with measuring time.  The only thing you can really measure is “Butt Time”.  Butt Time is the actual amount of time someone has their butt in a chair while working on an issue.  You need Butt Time to get any work done, of course.

But Butt Time isn’t really what you want from your developers.  Butt Time isn’t at all equivalent to productive development time.  Butt Time includes reading email, answering questions and generally handling any number of interruptions, meetings, and other distractions.  And those distractions, however minor, break a developer’s concentration.

And when you get right down to it, development is all about concentration.  With a coding project of any size at all, doing development requires your complete focus and concentration.  You need to build up complex data structures and patterns in your mind in order to really be productive.  Doing so takes time --  I’ve heard it described as building a house of cards in your mind.  Building that house of cards can take upwards of fifteen minutes depending upon the project.  But here’s the bummer:  It only takes a second for that house of cards to come tumbling down.  One distraction can make your fifteen minute investment disappear. 

And of course, time spent in “The Zone” – with that house of cards constructed and true, highly productive work getting done – is what we all are seeking.  We’ve all probably had that awesome experience of getting into that zone for hours at a time and wondering where the time went.  We know how cool that is – and how precious.  That’s what we want to measure – Brain Time.

But that’s a really hard thing to do.  Getting accurate, meaningful Butt Time measurements is difficult enough.  But how in the world can you actually measure Brain Time?

I’ll argue that you really can’t.  In the end, Butt Time is only a poor proxy for Brain Time.  What we need to do is to try to increase the Butt Time to Brain Time ratio by providing an environment where Brain Time is maximized as a percentage of total Butt Time.

There are ways to do that – ensuring that your developers have an office with a door that they can close is an important first step.  The book Peopleware is really the Bible for this, and Joel Spolsky has talked a lot about it as well.  Uninterrupted quite time is the key.  Leaving developers alone is the key to maximizing Brain Time.

Seriously – you need to get and read Peopleware if you have anything at all to do with leading developers.  This is the definitive book on managing software developers.  Be sure to get the Second Edition.  The physical book is, I believe, out of print, causing the price to be pretty high,  but I was delighted to notice that you can now order it on the Kindle

Another thing we need to do is to respect – indeed, celebrate – those developers that are quiet and don’t say much.  We have a not small number of developers here at Gateway that, well, don’t say much at all.  They come to work, write great code, and go home.  They don’t have a lot to say.  But sadly, we don’t always respect this.  I’m as guilty of anyone of too often saying super-clever things like “Stop being so boisterous, Meredith” or “Did you say six words today?”, instead of recognizing that Meredith is maximizing her Brain Time and, by being quiet, not breaking other team members’ concentration.  Being quiet is a very valuable virtue in a software developer – both because they themselves are being productive and they aren’t breaking other’s concentration -- and we should give honor and respect to that.

Butt Time is easy to come by and fairly easy to measure.  Brain Time, however, is a precious and hard to measure commodity that needs to be nurtured and respected.

Flotsam and Jetsam #59

By Nick at April 23, 2012 14:39
Filed Under: Flotsam and Jetsam
  • The comments are working again.  My apologies go out to those folks who were kind enough to try to comment but weren’t able to.  I don’t know what the problem was – it went away when I deleted my “Little boxes” box in the sidebar.  When I rebuilt it using pretty much the same code, it all kept on working.  Gremlins, I guess.  In any event, all should be well, and thank you to those of you who took the time to let me know about the problem.
  • More on Delphi Marketing:  I wrote about Delphi marketing a little while back, and here’s more proof that they are busy and really doing a great job.  Tim Del Chiaro has the list of online webinar and events that happened just in the first quarter of this year alone. That is a very long and interesting list of webinars you can view to learn about Embarcadero products, what they can do, and why you might want to buy them.  That’s what marketing folks do – let you know that the product exists, what it does and why you need it.  More good stuff continues to come out of the folks in Scotts Valley, and you should be giving credit where credit is due if you aren’t.
  • I’m a big fan of Documentation Insight by DevJet, and they have recently released version 2.0 of this great IDE tool. I heartily recommend that you buy it and start writing /// comments for your library code – and any code at all, for that matter.  Visit the What’s New page for information about this excellent tool. 
  • Jeff Duntemann pointed to these really cool pictures of the interior of the Hindenburg.  Now, of course, the name “Hindenburg” is synonymous with “horrible, flaming disaster”, but one would assume that had the thing not been filled with hopelessly flammable hydrogen, that blimp travel might have become popular.  I don’t know about you, but I think that a trip on such a ship would be really, really cool.  Blimps are a common site today – no big sporting event happens without the famous overhead shots from the Goodyear Blimp – and I for one would love to take a trip across the United States in a blimp at a reasonable altitude for seeing the sites.  I’m surprised such a service isn’t available – I can’t imagine that I’d be alone in such a desire.
  • Dennis Landi – long time Delphi guy – is looking for a Delphi developer in the Washington, DC area.  

Comments Working.

By Nick at April 22, 2012 08:27
Filed Under: General

Okay, it looks like comments are working now.  

It seems that my little box of flair (links to Facebook, etc) was causing the problem.  I deleted it for now.

What a bother.

Comments Broken?

By Nick at April 11, 2012 19:05
Filed Under: General

I notice that I haven't had any comments since April 1, and now I've gotten some emails from some of you kind folks pointing out that commenting doesn't work.  

Is that still the case? (Feel free to answer at nickhodges@gmail.com if it is....)

Sorry about that -- I'm not sure what the issue is.

Using Anonymous Methods for Inversion of Control

By Nick at March 31, 2012 17:26
Filed Under: Delphi, Software Development, Unit Testing

Introduction

I’ve written an entire series of articles about Dependency Injection and the Inversion of Control.  I’ve exhorted you to decouple your code and to ask for your dependencies instead of creating them yourself.  I hope you’ve listened.

Now I’m going to discuss another way you can invert the control of your code – by using anonymous methods.

Anonymous methods were one of two major language features added in Delphi 2009 – the other being generics.  Generics are probably easier to understand and use as they have a great use case with collections.  Anonymous methods are a little harder to understand because their use and their purpose are not as easily seen.   I hope that you’ll start seeing their advantage after reading this post.

Basic Idea

The basic idea is pretty simple – anonymous methods allow you to pass code, i.e. functionality, like any other variable.  Thus, you can ask for  functionality via an anonymous method just like you can ask for a dependency via an interface.  Because you can assign code to a variable – or even pass code directly into a method – you can easily invert the control of your class by passing in code to your class instead of embedding it in the class itself.

One of the principles of Inversion of Control is “Don’t call us, we’ll call you”.  That is, if a class needs something, the class itself should ask for (call) the functionality, rather then doing that functionality itself.  If a class needs to, say, record the processing of widgets as it happens, it should ask for a widget recording class and record things using the dependency that is passed in.  A class should not create it’s own instance of a widget recording class and then use it.

Given that example, it’s not difficult to see how one could pass recording functionality into a class as an anonymous method. 

Doing it the “Normal” Way

Let’s use the above discussion in a code example.  As noted, perhaps your class needs to record the processing of widgets.  Typically, you might do something like this in order to use good dependency injection techniques:

type
  IWidgetRecorder = interface
    procedure RecordWidgets(aNumberOfWidgets: integer);
  end;

Then, you’d pass an instance of that interface into your class:

var
  MyWidgetRecorder: IWidgetRecorder;

...

MyWidgetRecorder := TWidgetRecorder.Create;
MyWidgetProcessor = TWidgetProcessor.Create(MyWidgetRecorder);

You’d store the widget recording interface and use it in your class as needed.  And that’s an excellent thing to do – your class is decoupled completely from the recorder, and you are using constructor injection to ask for your dependency. 

Again, this is a great technique, and probably preferable most of the time.  I don’t want to leave the impression that what I discuss below is always a replacement for good, sound use of interfaces. However, it may not always be what you want to do.

IOC with Anonymous Methods

As noted above, you can use anonymous methods to invert the control of your class.  Perhaps declaring an interface and instantiating a class to implement it is too heavy.  Perhaps the dependency is really simple and straightforward.  In those cases, using a simple anonymous method to inject your dependency might be a better solution for decoupling your code.

For instance, you can declare an anonymous method type:

type
  TWidgetRecorderProc = reference to procedure(const aCount: integer);

This will allow you to declare code that takes an integer – presumably the count of widgets being recorded – and does whatever you need it to without bothering the class that uses it.

From there, you can use this type in your classes:

type
  TWidgetProcessor = class
  private
    FWidgetRecorder: TWidgetRecorderProc;
  public
    constructor Create(aWidgetRecorder: TWidgetRecorderProc);
    procedure ProcessWidgets(aNumberToProcess: integer);
    property WidgetRecorder: TWidgetRecorderProc read FWidgetRecorder write FWidgetRecorder;
  end;

This simple class declaration takes an anonymous method as a parameter to its constructor, and then exposes that function as a property. That’s a bit of a commitment – you may not always want to do widget recording.  If you wanted, you could not pass the anonymous method in the constructor and simply assign it to the property as desired. In any event, the widget recording functionality is implemented externally, and your class merely depends on the anonymous method type. 

Then, you can implement the class as follows:

{ TWidgetProcessor }

constructor TWidgetProcessor.Create(aWidgetRecorder: TWidgetRecorderProc);
begin
  inherited Create;
  FWidgetRecorder := aWidgetRecorder;
end;

procedure TWidgetProcessor.ProcessWidgets(aNumberToProcess: integer);
begin
  WriteLn('Processing ', aNumberToProcess, ' widgets.');
  WidgetRecorder(aNumberToProcess);
end;

Now, you have a class that can record widgets any way you want to – to the console, to a file, to email, a database -- whatever.  And you don’t have to know anything about the implementation of how the widgets are recorded. You just have a variable that refers to the code, which you can easily call in your code. 

Using Your New Widget Recording Tool

So, now we have a TWidgetProcessor that can record widgets with an anonymous method.  Cool – but how?  Well, you simply declare an anonymous method and pass it in.  Here’s an example which just writes out to the console:

procedure ProcessSomeWidgetsAndRecordToConsole;
var
  WidgetProcessor: TWidgetProcessor;
  RecorderProc: TWidgetRecorderProc;
begin
  RecorderProc := procedure(const aCount: integer)
                  begin
                    Writeln('The Widget Recorder recorded ', aCount, ' widgets');
                  end;


  WidgetProcessor := TWidgetProcessor.Create(RecorderProc);
  try
    WidgetProcessor.ProcessWidgets(Random(100));
  finally
    WidgetProcessor.Free;
  end;
end;

All this code does is declare an anonymous method that matches the declaration of TWidgetRecorderProc and writes the information out to the console.  That’s pretty simple.  But what if you wanted to write it out to a file?  Easily done without changing the TWidgetProcessor class at all.

procedure ProcessSomeWidgetsAndRecordToFile;
var
  WidgetProcessor: TWidgetProcessor;
  RecorderProc: TWidgetRecorderProc;
const
  cFilename = 'WidgetRecord.txt';
begin
  RecorderProc := procedure(const aCount: integer)
                  var
                    SL: TStringList;
                    S: string;
                  begin
                    SL := TStringList.Create;
                    try
                      if TFile.Exists(cFilename) then
                      begin
                        SL.LoadFromFile(cFilename);
                      end;
                      S := Format('%s: %d widgets processed', [DateTimeToStr(Now), aCount]);
                      SL.Add(S);
                      SL.SaveToFile(cFilename);
                    finally
                      SL.Free;
                    end;
                  end;

  WidgetProcessor := TWidgetProcessor.Create(RecorderProc);
  try
    WidgetProcessor.ProcessWidgets(Random(100));
  finally
    WidgetProcessor.Free;
  end;
end;

Of course, you could write a similar anonymous method to record the information to a database, send an email, or any combination thereof. 

And just as importantly, if you want to test The TWidgetProcessor class, you might want to do so by passing in a TWidgetRecorderProc that does absolutely nothing:

  RecorderProc := procedure(const aCount: integer)
                  begin
                     // Do nothing, as this is a stub for testing purposes
                  end;

And of course if your classes are easy to test, then they are very likely well designed.  The ability to stub out functionality as above is a hallmark of well designed classes.

Conclusion

So now you have another tool in your Dependency Injection/Inversion of Control tool box.  The power here is in the ability to decouple functionality from the class that needs that functionality. Anonymous methods provide a nice way to wrap up functionality in a single variable.   Instead of injecting an implementation of an interface, with anonymous methods you can inject a specific chunk of code that will provide the functionality.  Either way, you end up with testable code that will be more maintainable in the future.

(I have included the full source for this demo, as well as other demos, available on my Demo Projects repository on BitBucket.org)

Flotsam and Jetsam #58

By Nick at March 24, 2012 20:59
Filed Under: Delphi, Flotsam and Jetsam
  • The annual RAD Studio survey is out. (UPDATE:  Apparently the link I gave was unique to me, so I've removed it.) I strongly recommend you take it if you are a Delphi/C++Builder/Prism kind of guy.  I can assure you from first hand experience that the results of this survey are very valuable and are used by Embarcadero to make decisions.  So please fill it out and let Embarcadero know what you think.
  • Awesome Quote by Nick of the Week: “The real cool part of it is that proper unit testing is a "virtuous circle". The more you write unit tests, the more you see how to write testable code. The more you write testable code, the more you tend to remove dependencies. The more you remove dependencies, the more decoupled your code is. The more decoupled your code is, the easier it is to test, and thus you write more unit tests, and start it all over again.”   I wrote that in a conversation about unit testing in the Delphi newsgroups.
  • Awesome Follow-up Quote by Dalija Prasnikar of the Week: After someone claims that unit testing can become “wheel-spinning”:  "Exactly opposite. It is quite hard to start the process rolling at the beginning. But once you get going it gets easier and easier, and you write new code faster and with less bugs and when you do write bugs, you find them in matter of seconds instead hours. And you end up with code that is easy to maintain and change. What more could you want?"
  • Sure enough, the denizens of Wikipedia have determined that this blog is “not notable”.   “Notability” is the magic word for Wikipedians, though often I think the definition that they use for it “Stuff I’m not interested in” or “a word I can use to control my little fifedom of the web’.  I will note, though, that my entry has appeared to prompt a complete reworking of the disambiguation page for “Flotsam and Jetsam”, so I’ve got that going for me, which is nice.  I can understand the need for Wikipedia to maintain a level of neutrality and objectivity, but I do think that it can get out of hand, with small-minded people enjoying their power a bit too much.  In any event, I do love Wikipedia, and use it probably more than any other site on the web.  One could even make the argument that it is mankind’s greatest achievement.  Perhaps I will in a future blog post.  Winking smile

Authoring Generics: A Simple First Step

By Nick at March 20, 2012 00:39
Filed Under: Delphi, Software Development

Consumer or Producer?

By now I suspect that most of you have heard of generics.  Perhaps you have started using them via the Generics.Collections unit, where you can find TList<T>TStack<T>, etc.  The Delphi Spring Framework contains an even more sophisticated set of collections and interfaces to those collections, including the very powerful IEnumerable<T>

These are all very useful classes, and our code is made much simpler, easier to maintain, and more type-safe because of them.  But using them merely makes us consumers of generics.  If we want to truly take advantage of generics, we need to become producers of generic classes.  It’s a big step to see the benefit of generic collections, but the truly big step is to start seeing opportunities for the use of generics in your own code.

A Contrived, Simple Example

This past weekend, some of my team members and I attended the C-Sharpen event here in Philly.  It was a valuable day, made particularly so by the presentations given by Steve Bohlen.  He gave an excellent presentation on the topic I discussed above – how we need to start thinking as producers of generics and not merely consumers.  In that presentation, he gave a simple example of how generics are powerful and can make your code simpler, more effective, and more powerful.  So, I’m going to show that example here.  It’s a bit contrived, but very illustrative of how to think about generics.

First, consider the following code:

type

  TOrderItem = class
    ID: integer;
  end;

  TOrder = class
    ID: integer;
  end;

  TCustomer = class
    ID: TGUID;
  end;

Now this code is very simple – a set of classes that might represent a simple order entry system.  But right away, something should occur to you.  All three have something in common – they are entities in your system. Down the road, you may want to act upon all the entities in your system, so you might create a superclass like so:

type

  TEntity = class  
  end;

  TOrderItem = class(TEntity)
    ID: integer;
  end;

  TOrder = class(TEntity)
    ID: integer;
  end;

  TCustomer = class(TEntity)
    ID: TGUID;
  end;

But you might be frustrated because you want your TEntity class to have an ID field that is in use by all descendants, but that pesky TCustomer class can’t oblige – it needs a GUID for its ID tag instead of an integer like the other classes.

Instead of fretting about the different types of ID tags, how about just create one that doesn’t care what type it is?  Well, this is where the power of generics comes in.   How about you give the TEntity class a parameterized type – a generic – as  it’s ID, and then just tell all the classes what type their ID tag will be?

type

  TEntity<T> = class
    ID: T; 
  end;

  TOrderItem = class(TEntity<integer>)
  end;

  TOrder = class(TEntity<integer>)
  end; 

  TCustomer = class(TEntity<TGUID>)
  end;

Now, given the above, your entities can all have ID’s, but you don’t have to have the same type for all of them.  If a TEntity descendant needs an ID of a different type, you can just descend from TEntity and pass the correct ID type in the class declaration.  

Again, the example is quite contrived, but I think it does a nice job of showing how you can starting “thinking generically” and not just accept a rigid type structure. 

In addition, it illustrates why the more formal name for generics is “parameterized types”.  The type in the brackets is passed in to the type declaration, and then used within the class, just as method parameters are passed in to functions and procedures. 

A simple, contrived example, sure.  But hopefully it illustrates how generics can be used to turn you from a consumer of generic classes to making them a common tool in your code.

 

Update:

As a number of commenters have pointed out, my original example was sub-optimal.  Rather than post a "correction" post, I've taken the liberty of updating and improving the original article.

New Blog Theme

By Nick at March 18, 2012 00:41
Filed Under: General

As you  have no doubt noticed, I updated the theme to my blog.  I was never really happy with the one I've had for about a year now, so I tweeked and existing BlogEngine.Net theme to my liking. It appears to be working and looking fine, but l can't test it on all the browsers you people have, so please let me know if you encounter any problems or oddities.  

One problem I am having is getting the lists, especially nested unordered lists, to work right.  Not sure what is going on yet, but I'm learning.  

Flotsam and Jetsam #57

By Nick at March 16, 2012 18:23
Filed Under: Flotsam and Jetsam, Delphi

My Book

A Pithy Quote for You

"There is nothing so useless as doing efficiently that which should not be done at all."    –  Peter Drucker

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