Widgets Delphi

Flotsam and Jetsam #43

By Nick at September 12, 2011 08:15
Filed Under: Flotsam and Jetsam, Delphi
  • Is your currency the Euro?  Well, now you can buy your RAD Studio from the inestimable and indefatigable Dr. Bob.  Bob has expanded his reach of dedication to the product and the customer to the entire Eurozone.
  • You guys know that I don’t think that Simon Stuart is really human.  Instead, I think he is some kind of android, sent here from the future to code something (in Delphi) that we need to save the world, and he's just biding his time writing things for us in the Delphi community.   Simon has produced a prodigious amount of cool stuff for us Delphi developers, and is a tireless community member.   It doesn’t seem like too much to ask to help him release Lua4Delphi before Christmas.  I made a modest donation.
  • We homeschool our kids, and my wife came to me showing me the stuff for the starting school year.  It presented an interesting choice:  All things being equal, should our kids spend their time learning to write cursive, or to touch type?  I voted for touch typing.  It occurred to me that I can’t remember the last time I wrote anything more than a note on a ToDo list. I almost never write letters or anything involving using a pen or a pencil for extended periods.  And even when I do, I don’t write in cursive.  But I’ll tell you what – I type A LOT.  (I’m doing it right now!)  Anyway, I guess we’ll have to put cursive writing up there with reading the newspaper.  I mean who does that anymore?  Winking smile I realize that we could do both, but that would mean giving up something else, and I see the two as similar enough that we should choose between the two. 
  • The TIOBE Index is out for September, and Delphi comes in a #13 with three down arrows.  Interestingly, though, if you put "Delphi" and "Pascal" together, they are in the Top 10.
  • Embarrassed that I Didn’t Know it was There Class of the Week: TAggregatedObject – very cool little class

Limiting Scope

By Nick at September 09, 2011 16:02
Filed Under: Software Development, Delphi

As a general rule, developers should limit the scope of variables as much as possible.   Keeping the notion of limiting scope in every way possible, from the big things (never, ever, ever use global variables)to the subtle little things a language can do (declare const parameters whenever possible) all can contribute to clean, easy to test code. 

Limiting scope has all kind of benefits.  First, limiting scope of a variable reduces the number of places that a given variable can be modified.  The reason we rightfully abhor global variables is there is no telling where or when a given variable might be changed.  A global variable hangs out there like that last donut in the break room.  You know you shouldn’t touch it, but oh my, it’s so tempting, and it’s so easy to just grab that variable and use it for whatever you need to do.  Limiting the scope of a changeable thing reduces the chances that it will be changed in a way that it shouldn’t be, or worse – in a way that you don’t even know about. 

Limiting scope is also, by definition, a main feature of object oriented programming.  Encapsulation is probably the first thing you thing of when you thing of OOP, and it’s basic purpose – it’s whole reason for existing, really – is to formalize the process of limiting scope.  They don’t call it “information hiding” for nothing.    The term “information hiding” really means “Hide the scope of your variables so much that they can’t be changed except in the exact way you let them be”.  Encapsulation enables you to ensure that data you don’t want exposed isn’t exposed.  And if it isn’t exposed, it can’t be changed.

Limiting scope also limits the ability for people to depend on code that they shouldn’t be depending on.  Loose coupling – the limiting of the dependencies with in a system – is a good thing.  Tight coupling is a bad thing.  Limiting scope makes it harder for one class to latch on to another class and create dependencies that make code hard to test and hard to maintain.  It also makes it harder for changes in one area of code to have secondary effects in other, coupled areas.  There is nothing worse than changing code in (metaphorically speaking) New York City, and having that change cause a bug in code all the way over in Los Angeles.  (This is commonly called “Action at a Distance” and is something that should be avoided like a bad burrito.)  

There are big, well known ways of limiting scope – objects, making a variable local to a method, etc. – but there are a lot of smaller, more subtle ways to limit scope as well.  I’ve tried to list a number of ways that you can limit scope in your Delphi code:

  1. No global variables.  None.  Zero.  -- This one isn’t so subtle, but it’s really, really important.  It’s really easy to make sure that you never ever declare a variable as global.  In Delphi, you can do it, but you never should.  In languages like C# and Java, you actually can’t, strictly speaking, declare a global variable – everything has to be in a class -- but you can create a field on your main class that is pretty much the same thing.  Delphi is more flexible and will let you declare a global variable.  But just because you can doesn’t mean you should.  So don’t.
  2. Don’t create anything. Instead, ask for what you need.  This topic is a big one unto itself and gets into the question of dependencies and dependency injection.   But if you try to never actually create anything in the constructor of your class and instead, pass the constructor existing instances of what it needs, you can limit the scope of a given class.  Better yet, if you use a full blown dependency injection container, you can very severely limit the scope of your classes and still benefit fully from their functionality. 
  3. Put everything you can in the implementation section of your units.  The implementation section is the friend of a Delphi developer trying to limit scope.  Things in an implementation section can’t be seen outside the unit. If you can put a unit name in the implementation uses clause, do it.  If you can declare a class definition in the implementation section, do it.   Putting something in the implementation section of  a unit ensures that it scope doesn’t expand beyond that implementation section. 
  4. If a variable can be local to a routine, do it. This goes along with “No global variables ever”, but it needs to be said. If you can declare a variable in the scope of a single method, do it. 
  5. Use constants whenever possible.   If you are never going to change the value you assign to a variable, why make it a variable at all?  Get in the habit of making something a constant, and then only making it a variable if it needs to be.  Do this even inside your methods. 
  6. If you can declare a parameter as const, do it.  A const parameter can’t be changed, and thus declaring it as such means you are limiting its scope. 
  7. If you can make a variable private, do it.  If you can’t, make it protected. If you can’t do that, make it public.  Only make something published if it has a very specific reason to be.  This one is a little trickier, because there are OOP principles to be considered.  But generally, make field variables private, and give access to them through protected members.  This way, while the data can be changed,  the actual storage device itself is not directly accessible.  In addition, you can control the ability to change the internal data through a setter method.
  8. Provide notification systems in your setters to monitor changing data.  Sometimes, you might have data that needs to be changeable, but is sensitive for some reason.  As as result, you want to perhaps monitor and maybe even prevent the changing of your internal data.  You can use something as simple as an event in the setter method, or something more robust and flexible as the Observer pattern. 
  9. Don’t reach into another class.  Or even better, don’t create classes into which someone else can reach.  This gets into the Law of Demeter, which I’ve discussed before

That’s just a list I came up with this week while working on this post and thinking about this topic.  What are other little methods and techniques that you all use to limit the scope of your variables?

Flotsam and Jetsam #42

By Nick at September 03, 2011 00:02
Filed Under: Delphi, Flotsam and Jetsam
  • Interesting Delphi XE2 Item of the Week:  TComponent now implements the Observer pattern. 
  • Very Cool Video of My Friends and Former Co-Workers of the Week: FireMonkey Developers Speak I have to say that:
  • I have fleshed out my Embarcadero Blog Content page that includes links to the two main series of articles that I wrote on my Embarcadero blog.  I still have some formatting to do, but the content should be all there.  I’m trying to grab all the content I can from my old Embarcadero blog, as they need to shut it down for legal reasons (as I understand….).  If you can think of anything I did there worth keeping (that might be be  hard, I know….. Smile) let me know.
  • "It is always painless to depend on interfaces."
  • Hey, I take my position as an Admin at the Delphi UserVoice page seriously, and I’ve been a bit busy.  The XE2 release has made things a little more fun there…
    • I just marked as "Completed" over 3800 votes on Delphi's UserVoice page. Not bad for a day's work.  And not bad by Embarcadero in delivering all that asked for functionality.
    • Now, with all those votes freed up, the most requested item is Better GUI separation and abstraction.  Is that really the thing that the community wants most?
    • I closed a bunch of “laundry list” items that would be impossible to close.  They were things like “Make the IDE Better” with a list of seven things they wanted to see.  How could you ever really close that as “Done”?  I encouraged the posters to create new requests for each individual request instead.
    • I’d recommend all you fine people go there and enter your requests as well as peruse the list and cast your votes.
  • I’ve been trying to build things with my son, and  being a boy, he likes weapons and destruction.  We started with a trebuchet.  I think it will likely be a while before we work our way up to this, but hey, we can dream. 

Greatest Blog Post Title Ever?

By Nick at August 15, 2011 03:51
Filed Under: Delphi, General, Software Development

Okay, more from my Embarcadero blog. This is kind of becoming a greatest hits combined with a trip down memory lane. I particularly remember this conversation-turned-blog-entry. It was the result of a late-night, late-in-the-development cycle conversation that had us all laughing very, very hard.

  • Okay — so I’m reading Steve Trefethen’s blog, and he links to what, in my personal opinion, is the greatest single title for a technical blog post ever —The Windows Shutdown Crapfest.  Doesn’t get any better than that.
  • So I read the thing, and it’s, well, amazing.  They have a whole team of people that do nothing but work on the Start menu.  That team had a whole team of people that works purely on the Shutdown experience. 
  • This fact above led to a discussion here on our release team about whether there is one guy on the C# compiler team who works only on the opening curly brace feature.  Does he have pair programmer that works purely on the closing brace?  When they work together, do they have to face each other? Does the Opening Curly Brace guy always have to sit on the left of the Closing Curly Brace guy? And what if Opening Curly Brace guy wants to keep working, but Closing Curly Brace guy wants to go home?  Does this result in a syntax error?  I have to know these things.
  • Now, if you think the above sounds ridiculous, then I think you’d should actually read the whole article.  It’s an amazing tale of Kafka-esque development processes.  Dude had to wait up to three months for his code to actually reach the product. 
  • And I thought that we had a convoluted release process here.
  • Yes, we are getting a little giddy.

(Note: this blog post was written by a committee).

Calculating Pi

By Nick at August 10, 2011 02:36
Filed Under: Delphi

More Stuff I found on my Embarcadero Blog. I believe that my unusual use of the case statement caused a bit of a stir.  I still like using case in this way….

This was fun to write.  I read this interesting post on StackOverflow, which had an answer about asking interview questions, and this was the example he gave:

Given that Pi can be estimated using the function 4 * (1 - 1/3 + 1/5 - 1/7 + …) with more terms giving greater accuracy, write a function that calculates Pi to an accuracy of 5 decimal places.

Now, I don’t get to do much coding anymore, but hey, I’m not completely out of it, so I thought I’d try my hand at it. This is what I came up with:

function CalculatePi(aIterations: Cardinal): Extended;
  Counter: Cardinal;
  Denominator: integer;
  Counter := 0;
  Denominator := 3;
  Result := 1;

    case Odd(Counter) of
      True:  begin
               Result := Result + (1/Denominator);
      False: begin
               Result := Result - (1/Denominator);
    Denominator := Denominator + 2;
  until Counter >= aIterations ;

  Result := Result * 4;

Now, again, I’m no Barry Kelly, and I’m sure that this could be optimized, but I was pretty pleased with that in a ‘that’s what I would have hacked out in an interview" kind of way.  :-)

The more iterations you pass in, the more precise it gets, obviously. I actually didn’t answer the full question (I skipped the precision part), but casual testing shows that about 10,000,000 iterations gets about 5 decimal points of accuracy. In fact, 10,000,000 iteration produces 3.14159275358978, which is pretty accurate.

Nick’s Public Code Repository Update

By Nick at August 09, 2011 05:42
Filed Under: Delphi, Software Development

Some of you may remember the TextScrubber project I was writing about back on my Embarcadero blog.  (I’ll update that page really soon, like today…).  I’ve made two changes with that project:

  1. I’ve updated it to allow you to set it to run automatically on Windows startup.
  2. I’ve moved the repository from SVN and SourceForge over to Mercurial and BitBucket.

Now this may be a bit of an inconvenience to some of you, and I apologize.  First, if you don’t have the Mercurial command line tool installed, you should.  I’d venture to say that if you don’t have at least the command line tools for SVN, Git, and Mercurial installed, you can’t really call yourself a  true developer.  Second, I’m a Mercurial guy, and BitBucket is Mecca for Mercurial guys.  So you can get the code there.  Third, since I am now a Mercurial guy, SourceForge is no longer my cup of tea.  I’m going to move all my code there over to BitBucket.  (Note – this will not include the TurboPower projects, which I don’t consider “my code”….). 

My intent is to make my BitBucket page a central location for my code. I’ve created a “NickDemoCode” project to publish code I use to demonstrate things.  I’ve got a couple of other small projects there as well. I’d like to do what Marco did and have it be part of, but I can’t seem to figure out how to do that.  (Anyone have any ideas? My ISP is pretty unhelpful, and this is not my area of expertise….)

So, if you are into great, awesome code, I’d recommend checking for updates to my public repository every 15 minutes or so.  You don’t want to get left behind.  Winking smile

Flotsam and Jetsam #40

By Nick at July 27, 2011 07:50
Filed Under: Delphi, Flotsam and Jetsam, Software Development, TechBiz

Getting Giddy #4 Fixed

By Nick at July 10, 2011 11:52
Filed Under: Delphi, General, Software Development, Unit Testing

Okay, so I was getting all these emails about the fourth article in my “Getting Giddy” series of articles.  You guys kept saying it was missing and I kept saying “Hey, it’s right here!”.  And then finally I noticed – #4 and #5 were identical.  I must have done something stupid somewhere.  Well, I was able to track down the original article on my hard drive and restore it.  So now, the fourth article is as it should be, and all seems well with the universe.

Sorry for the confusion, and I appreciate the interest that these articles have generated.

Flotsam and Jetsam #39

By Nick at July 10, 2011 09:25
Filed Under: Flotsam and Jetsam, Delphi

Flotsam and Jetsam #38

By Nick at July 07, 2011 00:26
Filed Under: Delphi, Flotsam and Jetsam, Software Development

A Bunch of Stuff I’d Like to See Embarcadero Do

By Nick at July 05, 2011 13:22
Filed Under: Delphi, Tech Stuff, TechBiz

There are a bunch of things that I’d like to see Embarcadero do.  I’ve listed and discussed some of them below.  I’ll probably think of more later.  Winking smile  They are in no particular order, and they are not grouped in any particular way.  They are a bit random, and range from business decisions to minor technological decisions. Where it makes sense, I’ve linked the titles to the entries on so that you can vote for the items if you see fit.

I’d like to see Embarcadero:

  1. Provide an Enterprise-level MVC web framework for Delphi.  This almost seems like a no brainer to me. Ruby on Rails has had a profound impact on web development and development in general.   In the .Net world, MVC has become the leading ASP.NET development method,winning over hearts and minds from WinForms.  The general idea of MVC is becoming the norm for much of the development world – separate those concerns!. Delphi’s new RTTI capabilities would actually make this kind of framework very, very possible and very, very cool.  And Delphi already has a very powerful and capable web infrastructure to build on:  good, old, and venerable WebBroker.  There are even existing frameworks out there that could be leveraged, including the G Framework.   There is a business opportunity here for Embarcadero, if not for an enterprising third-party Delphi developer.  A native, ISAPI based MVC framework in Delphi?  That would be very, very sweet.
  2. Stop trying to do other stuff and invest in Delphi.  This one has been one of my huge frustrations over the years.  Delphi is a profitable product, but no matter who owns or runs the show,  the profits always seem to get skimmed off to fund other “next big thing” projects of, well, questionable benefit at best.   Remember “SDO” taking the market by storm? Yeah, me neither. AppWave seems to be interesting and have a lot going for it, but I personally would rather have seen that effort invested back into Delphi.  I hate to think about where Delphi might be today if it hadn’t been used to fund other projects and instead been allowed to use it’s profits for it’s own development.  Delphi could use a year or two of un-distracted attention from its owner. 
  3. Create a Javascript/HTML development tool.  I’ve always said “As assembler is to the Intel chip, so Javascript is to the browser”.  James Governor has it right:  “Learning Javascript used to mean you weren't a "serious software developer". Today, not learning Javascript means the same thing.”  A powerful, feature rich RAD development tool for Javascript and JQuery would be really cool and a great new product for Embarcadero.  Maybe RADPHP could be steered in that direction?
  4. Make Dependency Injection part of the RTL: If you haven’t figured it out yet, I’m a big believer in Dependency Injection.  So much so, that I think that if you aren’t doing Dependency Injection, then you are doing it wrong.  Incorporating a DI Container into the Delphi RTL would be very cool.  Again, Generics, anonymous methods, and the new RTTI makes is very easy and powerful, and there are open source projects to leverage and build on (like my favorite, Delphi Spring).
  5. Do one thing at a time and do it really well:  This is the one that I wish they would do the most:  Take the product forward one step at a time. For instance, the next release should have as it’s main focus 64-bit Delphi and only 64-bit Delphi. That’s it.  Other improvements can be made, of course, but clearly that should be the “big one”, and it should be the only “big one”.  Don’t try to do two or three “big ones” in a single release. Make each release focused on a big, single step forward, executed thoroughly and solidly.  The product will be fine as long as it shows steady, sustained improvement.  Many large improvements executed all at once is not what the market wants.  Focus and deliberately move forward.

That’s all for now – I’ll probably have more as I think of them, but that ought to be food for thought for while

Accessing Private Stuff with Interfaces

By Nick at June 27, 2011 08:38
Filed Under: Delphi, Tech Stuff

I have to admit that the following code surprised me.  I guess it makes sense, but I wouldn’t have guessed that you can expose private functionality via an interface like this.  Interesting. 

program DoPrivateStuff;




  ITestInterface = interface
    procedure DoThisPrivateThing;
    procedure DoThisPublicThing;

  TTestClass = class(TInterfacedObject, ITestInterface)
    procedure DoThisPrivateThing;
    procedure DoThisPublicThing;

{ TTestClass }

procedure TTestClass.DoThisPublicThing;
  Writeln('Doing a public thing');

procedure TTestClass.DoThisPrivateThing;
  WriteLn('Doing a private thing');

   Test: ITestInterface;

    Test := TTestClass.Create;
    on E: Exception do
      Writeln(E.ClassName, ': ', E.Message);

Getting Giddy with Dependency Injection and Delphi Spring #5 – Delphi Spring Basics

By Nick at June 26, 2011 13:12
Filed Under: Delphi, Software Development


Remember, you can download the Delphi Spring Framework on Google Code.


Okay, so we are finally at the point where we can actually start using a framework to do some of the things that we want to do.  So far we’ve seen how the Law of Demeter is important to good code design.  We’ve looked at how important it is to write testable code by reducing the dependencies between objects, and we’ve seen how it’s good to code against interfaces and to keep our constructors simple. I’m finally going to make good on my promise to show you how to write useful code in a unit with nothing in the interface section. 

I hope I’m doing a good job describing why and how you want to use a Dependency Injection framework.  I hope by the end of this, you can see how to use the Delphi Spring Framework.  However, I’m doing a very imperfect job of describing the motivations and reasons behind why you want to do dependency injection. However, all is not lost – I strongly recommend that you watch this outstanding episode of DotNetRocks TV, where a really smart guy (with a delightful Canadian accent – he sounds just like my brother-in-law) named James Kovacs explains the whole underpinnings of Dependency Injection and why it’s good.  He does the presentation in C#, but don’t let that put you Delphi guys off --  the ideas are all there. 

Problems With “DI via Constructor Parameters”

In the last episode, I talked about two rules that you should follow:

  1. Always code against interfaces
  2. Keep your constructors simple

We looked at how exposing only an interface will create clean, uncoupled, and testable code, and how keeping constructors simple will decrease one classes dependency on another.  We saw an example of what I called “Dependency Injection via Constructor Parameters” (DICP) where you don’t create internal classes yourself, but let them get passed in via parameters on a constructor. 

DICP allows you to create the services (classes) you need outside of the consuming class itself, but it still requires that you create specific classes you want in specific places in your code.  Despite having a certain level of inversion of control, you are still coupled to the specific class.  Consider the following code, based on our Pizza Oven code from the last installment:

  MyPizzaOven: TPizzaOven;
  MyPizza: TPizza;
  MyPizza := TPizza.Create;
  MyPizzaOven := TPizzaOven.Create(MyPizza);

This code is better than creating the TPizza class inside the constructor of TPizzaOven, but we still have the problem of the TPizza class and the TPizzaOven class being coupled together via the uses clause – TPizzaOven needs to know about the TPizza class and how it is declared. 

Even if we re-declare TPizza as an interface – IPizza – we still have to know how to create an instance of TPizza for the IPizza interface, and we aren’t all that much more decoupled than we were before – TPizzaOven still has to know about the specific declaration of TPizza. In fact, the code above really wouldn’t change at all if the MyPizza variable were an IPizza instead of a TPizza,right?

But what if there were a way to get an interface implementation without having to know anything about the specific implementation of that interface?   Now that would really decouple things and truly separate the interface from the functionality. If only there were a framework written in Delphi that would let you do this.  If only……!

The Spring Container

Okay, I was joshing – there is such a thing:  The Delphi Spring Container does exactly that.  A Dependency Injection container is a class that can hold references to interfaces and classes that implement them.  You can register specific implementations of interfaces in the container.  If you need an implementation of an interface, you ask the container, and it provides a reference to that implementation via the given interface.   When you need an implemented interface, you reference only the container, and thus there is no direct connection between the class needing the implementation and the implementation itself.  Pretty sweet, huh?

So how does this work?  The first thing you’ll likely want to do is to create a singleton implementation of the Spring Container.  I’ve created the following unit called uServiceLocator, which wraps up the Spring Container in a Singleton:

unit uServiceLocator;



  function ServiceLocator: TContainer;


  FContainer: TContainer;

function ServiceLocator: TContainer;
  if FContainer = nil then
    FContainer := TContainer.Create;
  Result := FContainer;


The uServiceLocator uses the Spring.DI unit from the Delphi Spring Framework where the TContainer class is declared. I have named my container "ServiceLocator" because it, well, locates services. SmileYou can use this unit anywhere you need to register classes and interfaces, as well as anywhere you need to use those registered interfaces.

TContainer is a powerful class that leverages both Generics and anonymous methods to let you register classes that implement given interfaces.  In later articles, I’ll delve a little deeper into the mysterious inner workings of TContainer, but for now, we’ll just look at the practicalities of how it is used.

Registering With The Container

Now, if you want to use the container, either to register classes with interfaces, or to consume a given interface, all you need to is use the uServiceLocator unit and not any unit that actually declares classes.  In fact, you can declare your classes in the implementation section of the unit and leave only an interface in the interface section.  Remember the uNormalMathService unit from last time?   Now, we can declare it as follows: 

unit uNormalMathService;


  IMathService = interface
    function Add(a, b: integer): integer;
    function Multiply(a, b: integer): integer;



  TNormalMathServiceImplemenation = class(TInterfacedObject, IMathService)
    function Add(a, b: integer): integer;
    function Multiply(a, b: integer): integer;

{ TNormalMathServiceImplemenation }

function TNormalMathServiceImplemenation .Add(a, b: integer): integer;
  Result := a + b;

function TNormalMathServiceImplemenation .Multiply(a, b: integer): integer;
  Result := a * b;

procedure RegisterNormalMathService;



First, note that the IMathService interface is the only thing available for use outside of the unit. Everything else is hidden in the implementation section.  Obviously, the “money code” here is the RegisterNormalMathService procedure. This is where the implementation of IMathService gets registered.  The procedure itself gets called in the unit’s initialization section, so the mere act of using the unit ensures that the TNormalAdditionService is registered and available for use by any other unit that uses the ServiceLocator.  The call to ServiceLocator.Build simply ensures that the TContainer is ready to answer requests for implementations of interfaces.

So what is happening in the RegisterNormalMathService call?  It’s almost self-explanatory.  The code performs pretty much as it reads: “Register the class called TNormalMathServiceImplementation, which implements the IMathService interface, under the name "Normal”.  (That’s what the last string parameter is – a named reference to the interface.  This allows you to register multiple implementations of a given interface and request them by name).

Nota Bene:  if you are going to provide multiple implementations of a given interface, you can declare that interface in a separate unit, use that new unit in the implementation section, and end up with no code at all in the interface section of your unit.  See, I told you it would work.  Winking smile

And once the service is registered, you can use it in a completely decoupled way:

unit uCalculator;



    uServiceLocator, uNormalMathService;

  TCalculator = class
    FMathService: IMathService;
    constructor Create;
    function Addition(a, b: integer): integer;
    function Multiplication(a, b: integer): integer;

constructor TCalculator.Create;
  FMathService := ServiceLocator.Resolve<IMathService>('Normal');

function TCalculator.Addition(a, b: integer): integer;
  Result := FMathService.Add(a, b);

function TCalculator.Multiplication(a, b: integer): integer;
  Result := FMathService.Multiply(a, b);


In this case, the “money code” happens in the class’s constructor, where the ServiceLocator is asked to “resolve” (i.e., provide) a working instance of IMathService, using the implementation registered under the name 'Normal'. The Container then goes and looks into its list of registered items, finds the correct implementation, creates an instance of that class, and returns it as an interfaces.  All of that happens “auto-magically” inside the inner-workings of the TContainer class.

Later on we’ll see how you can control the lifetime of the created classes, pool them, or create instances as a Singleton.  You can even have complete control over how the resulting class is created via the power of anonymous methods. 

Note that the class knows nothing about anything other than IMathService.  It does use the uNormalMathService, but the implementation of that class is completely hidden.   The only reason that uNormalMathService is in the uses clause is because that is where the IMathService interface is declared.  If you really want, you can do as the quote block above says and declare the interface in a separate unit and not even require the use of the unit that implements IMathService at all.


Thus, we have a simple example of using the Delphi Spring DI Container that completely decouples the implementation of a class from the consumer of that class.  In the above example, the TCalculator class knows nothing of nor is connected in anyway to the implementation of the IMathService interface.  All of this happens inside of the Delphi Spring container. 

So far, this is just a simple, basic look at what the Delphi Spring Container can do.  The Delphi Spring Framework can actually automatically and seamlessly create implementations for interfaces without writing any code at all.  So stay tuned for that in coming installments. 

Flotsam and Jetsam #37

By Nick at June 22, 2011 03:06
Filed Under: Delphi, Flotsam and Jetsam, Tech Stuff
  • Marco Cantu has published his new book on Delphi XE.  I’ve been given an advanced copy (thanks, Marco!) and as you’d expect, it is excellent.  We are going to buy some copies here at Gateway Ticketing for use in our transition to Delphi XE.  As with everything Marco does, it is highly recommended
  • There a new Facebook group for Delphi Developers that seems to have a lot of activity.  You might consider joining.  It would be good for Delphi people to congregate in a single place on Facebook to share links and information, and this might be the place. 
  • And speaking of Facebook, you can now ’Like’ Embarcadero’s AppWave on Facebook.  I’m still not clear on exactly where all this AppWave thing is going, but it does look interesting.  I wonder what affect the “appstore” in Windows 8 will have on it.  I guess one advantage that AppWave has is that it is here right now, and Windows 8 is still pretty much vaporware at this point.
  • I went to see the Green Lantern this past weekend.  Highly recommended – I have no idea what all the bad reviews were about.  Great comic book movie.  (Those reviewers know that the Green Lantern is a comic book movie, right?)  The tech angle here is that it was the first time that I had seen a movie in 3D.  My take?  I never want to see a movie – any move, I don’t care if it’s a “blockbuster” or not – in 2D again. It was a terrific experience. This is a great feature that will definitely get me in the theater more. I have been going to the theatre less and less because of Netflix, but if I can see the upcoming Harry Potter movie in 3D, I will.  Looking forward to it being the normal experience on TV.
  • David I has been at Borland, Inprise, Borland, CodeGear, and now Embarcadero for 26 years.  He’s seen it all.  Congratulations to a titan of the industry – and a great guy.  I’ve known David for many years – since I met him at a PC User group at the Naval Postgraduate School in around 1994 – and it’s been an honor to be his friend.
  • I love a good story like this:  Throw Away that Hotel Soap.  There is staggering waste in our economy (anyone buying cases of plastic bottles of water – I’m looking at you…) and this is the kind of thing I love to see.

Flotsam and Jetsam #36

By Nick at June 19, 2011 04:51
Filed Under: Flotsam and Jetsam, Delphi

My Book

A Pithy Quote for You

"Nothing is wrong with California that a rise in the ocean level wouldn't cure."    –  Ross MacDonald

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.