Saturday, May 13, 2017

Program to an Interface and not an Implementation

I have been struggling with trying to understand what it means to "Program to an interface and not an implementation." Nick Hodges said if he could teach new developers one thing it would be "program to an abstraction, not an implementation". This is the same thing. (

So I asked Hodges to explain this to me. Instead of trying to regurgitate some sort of answer that might come up short of what I was looking for, he sent me a link to a fascinating thread on StackOverflow ( This really is a great read. After reading it I was close to understanding but still not getting all of it.

I have recently started reading Head First Design Patterns by Eric Freeman & Elisabeth Robson. This book does an absolutely fantastic job of describing the GoF design Patterns that Uncle Bob so bluntly told me I need to understand. To be quite honest, I never would have bought this book solely based on the cover. (Not buying this book would have been a mistake.)


On page 11 of Head First Design Patterns they point out Design Principal #2: "Program to an interface and not an implementation." They do an excellent job of explaining what this means. My ability to understand what they mean... "Not so much". This is even after reading page 11 three times and reading the entire SO link Hodges sent me.

Why am I so dim?
How come everyone else gets it but me?

Ah ha, it hits me.

Each Delphi Unit has an Interface section and an Implementation section. In Delphi these sections are like Public Scratch Paper and Private Scratch Paper. ( All Delphi noobs are taught to stick stuff in the Interface section that you want to share with other units and stick stuff in the Implementation section that you don't want other units to have access to.

That is NOT what it means to "Program to an Interface and not an Implementation."

I had to unlearn what I had known about Interface and Implementation because of my 25+ years of Turbo Pascal/Delphi. And relearn that there are different meanings associated with Interface and Implementation. Sometimes it takes the light bulb a long time to go on

My end goal in all of this "new learning" is to understand Dependency Injection and how to put DI to use when I design/redesign software. I'm slowly getting there. Delphi's Interface and Implementation sections have different usage and meaning than the OOP Design Principle: Program to an interface not an implementation.

So, what does it mean to "Program to an interface and not an implementation"?

You have to figure this out on your own. I'm not trying to be a smart ass here. Once you get it, you'll get it. Asking someone for a quick 5 minute explanation won't do it. You'll have to dig and keep trying until it makes sense for you. In learning this concept some people use widgets. Some use sprockets. Some use ducks. I like chess.

Think about the simplest piece in a chess game. The Pawn.

What's the same about every pawn?
What's different about each pawn?
If you forget about color, how many different pawns are there? 8, 1, 3, 4 ?
What about the pawn to the far-left?
What about the pawn to the far-right?
What about the pawn that reaches the last row?
How many different moves does a pawn have?
Do all pawns have the same moves?

Trying to understand what it means to "Program to an interface and not an implementation" requires a different way of thinking.

Here is my completely oversimplified chess example:
| PawnMovement (Interface)       |

| PawnMovementImplementations    |

So to me learning how to "Program to an interface and not an implementation" means making sure your pawn has movement not what the pawn's movement is.

Think this:

Don't Think this:


Semper Fi,
Gunny Mike

Thursday, April 20, 2017

Gunny Meets Uncle Bob - Part 1

The last few days have been very interesting. It started when my friend Jon Aasenden posted a link to a you tube video called "SOLID Principles of Object Oriented & Agile Design" by some guy named Uncle Bob. This wasn't the first time I heard about Uncle Bob. Nick Hodges made a reference to something called SOLID in his book which is supposedly Uncle Bob's principles of object oriented design.

I bought Nick Hodges book "Coding in Delphi" over two years ago. I actually bought two copies. My first purchase was the printed edition. I went back and purchased the pdf version a couple months later after I decided I didn't want to type the examples if I could cut and paste them.

Anyway, I made it to page 28 and no further. I had a mental block about something and never worked through it. It's been sitting on my bookshelf unopened for over two years. It's amazing how fast time goes by. I have since learned that Nick has two more books. "More Coding in Delphi" and "dependency injection in delphi".

So after watching the Uncle Bob's video I decided to buy three of his books; "Clean Code", "The Clean Coder" and the yet to be released "The Clean Architecture".

I came home from work yesterday and "The Clean Coder" had been delivered. I was so excited. I couldn't wait to read Chapter 1.


I haven't felt this inadequate in a long time. Thank you Robert "Uncle Bob" Martin. In less than twenty pages you humbled this US Marine.

I went on Facebook and whined about how inadequate Martin made me feel. To my surprise a couple of highly respected friends mentioned they too had felt the same way after reading his stuff.  That was a little comforting but I still felt like crap.

According to Martin I'm supposed to give my employer 40 hours a week and then spend another 20 hours a week on my career. Learning, reading, practicing.

I'm also supposed to understand and describe the 24 patterns in the Gang of Four (GOF) book plus have a working knowledge of many of the patterns in the POSA books.

I scrambled around and googled for the 24 GOF patterns. Found a clean, concise 8-10 page pdf. Read it real quick. Check - That's done. I'll do the POSA stuff tomorrow. It's late. I'm tired. I'm going to bed.

Day Two:

I woke up this morning a little early because I had to pee. I came back to bed and tried to fall back to sleep. But I couldn't get Martin and what he said out of my head. I kept thinking, "I haven't got time for all this crap, I need to learn Dependency Injection. That's what started this whole thing anyway."

Then it hit me.

I started thinking about chess, and how Jimmy O'hara used to kick my ass every time we played chess back when we were both twelve years old. That was forty-six years ago. He'd take my queen within the first four to five minutes. Oh did I get pissed when that happened. I now had to play without my strongest piece.

Then I thought. Wow, chess was a really complicated game. It took a long time to learn how to move them 16 different pieces around. Wait a minute there aren't really 16 different pieces there are only 6 different pieces. I spent a lot of time learning how those 6 pieces moved.

Then it dawned on me.

If I want to be good at my craft I have to identify the chess pieces of my craft and learn how to move them. Wait a minute. Didn't Martin just tell me last night that I need to understand the 24 GOF patterns. He did. Aren't those the chess pieces of my craft? They are.

How can I expect to be good at my craft if I only give a casual glance at the chess pieces I need to use in my craft. I can't. Bingo.

Then it hit me again.

What about the POSA books and those designs?

I like to play golf. I started playing golf when I was twelve. Yup forty-six years ago. Learning golf was hard and it took a long time to get good at it and to learn how to use of each club. Hey wait a minute. I see a pattern here. Why can't I treat the patterns in the POSA books like golf clubs. If I want to be good at my craft I have to learn what each club does and how and when to use each one of them.

But wait there more. What about SOLID? Hey Gunny, how do you reconcile SOLID like you did using chess for GOF and golf for POSA?

JJDIDTIEBUCKLE The twelve leadership traits.

I spent twenty years in the Marine Corps. It's all about leadership and leadership traits. I lived, breathed, taught, and honed those twelve traits. I need to do the same thing with SOLID.

This works for me. You need to find a way to make it work for you.

Gang of Four Patterns = Chess
POSA Patterns = Golf

This journey I'm taking with Uncle Bob is not in the least a passive journey. If I want to fully embrace my craft (software development) I need to dedicate myself to it the same way I did for chess, golf, and leadership within the Marine Corps.

Time to strap it on.


Semper Fi,
Gunny Mike

Saturday, March 25, 2017

Google, Mobile, and You. Are You Good?

I put my Delphi development on hold a few months ago so I could work on creating a responsive website for my software. The hardest part for me was trying to find a layout I was happy with. I took a little inspiration from the Embarcadero Communty website. I settled on a Bootstrap 9 X 3 layout. And now it's done and I can move on.

It's only been a couple days but I have already seen a 300% increase in traffic to my website.

Dave Collins from Software Promotions has put together a 5 minute video that talks about Google's big shift toward mobile first indexing. I strongly encourage you to watch this video. Mobile-friendly isn’t necessarily mobile-friendly

I'm just an Independent Software Deveopler like many of you. I felt compelled to share what I have learned over the past three months. We all love Delphi and the opportunities it gives us to create software and apps. You can have the best software or app out there but if people can't find it, it's not a good thing. Don't let this happen.

I look forward to getting back at it. It feels good to know thay my development efforts will have a fighting chance.

Semper Fi,
Gunny Mike

Tuesday, December 6, 2016

EMBT Webinar: Overcoming Monetization Challenges Using Licensing

Embarcadero Technologies is teaming up with the Association of Software Professionals to bring you Jessica Dewell of Red Direction.

Calling all owners, founders, CEOs, and all leaders whose company has products for sale right now! You will receive actionable and immediately useful information to review, evaluate, and evolve your product catalog to stay competitive…and profitable.

When you finally figured out how to make your products fly into the hands of customers that want it … something changed, and what worked before no longer does. A very important, and often overlooked place to start is with the product catalog. (More)

Sign Up Today

Embarcadero Technologies Webinar:
Wed, Dec 14, 2016 9:30 AM - 10:30 AM PST
Wed, Dec 14, 2016 2:30 PM - 3:30 PM PST
Wed, Dec 14, 2016 5:30 PM - 6:30 PM PST?

Gunny Mike

Friday, August 12, 2016

How to use the SET LOG MESSAGE Feature Within ElevateDB

The more I use ElevateDB the more impressed I get with this product. Last week I visited the ElevateDB support forum, most likely related to a syntax issue I was trying to resolve. As I read through some of the posts written by other users, I came across a very curious and interesting tidbit of information. A user mentioned the following:
"If you add a log message before the OPEN Crsr, you will see that the function is executed for each row."
This certainly got my investigative juices flowing. I had to find out what he meant. He was referring to the SET LOG MESSAGE statement. There were no pictures to show how to implement this log message feature so I began digging around and figured out how this works.

ElevateDB comes with it's own GUI called ElevateDB Manager. It's similar to the SQL Server Management Studio (SSMS) Microsoft distributes.

Here is a screenshot of a New.SQL script inside ElevateDB Manager

The SQL script is a simple loop from 1 to 100 that displays a log message each time X is a multiple of 7.

If you execute this script it tells you that "The script was executed successfully in 0 seconds". But where are the log messages?

You have to turn them on.

With the Explorer > Log Messages visible you see all the SET LOG MESSAGE statements. The log messages continue to accumulate each time you execute a script. There are two undocumented ventures available within the Log Messages pane: Save and Clear.

Simply right click anywhere within the log message pane you have an option to either Save or Clear the log messages.

I love the SET LOG MESSAGE feature and use it all the time. I find it extremely helpful and I hope you do as well.

Semper Fi
Gunny Mike

Sunday, April 24, 2016

A Better Way to Present and Organize Error Messages in Your Delphi Applications

I'm in the process of totally redesigning an application I wrote 25 years ago. Today, I decided to look for a better way to present error messages to my customers. In the past I simply littered my code with bunch of technical speak ShowMessage('bla bla bla technical speak bla bla bla'); code fragments.

With the help of Google, it didn't take long to find out that the best approach is to use "Apologetic" language in error messages. This has a positive effect on your customers.

I've never liked the idea that the standard ShowMessage gets positioned centered on the screen. I'd rather have a messaged display centered on the window where the error occurs. I also don't want my error messages scattered all over the place. So, I set out to do two things;
  1. Display error messages that are centered on the form where the error occurs
  2. Centralize all the error messages in one place
I created a separate unit for the express purpose of managing and displaying error messages:

This makes it very easy to keep track of all the error messages. It also lets me easily create similar but slightly different error messages for any given situation. I can also group related error messages by using a simple number scheme.

I'm a big fan of code completion Ctrl+Space. When I need to include an error message I simply type zmsg Ctrl+Space and up pops the code completion window with all the available error messages that I can choose from.

zmsg Code Completion

Semper Fi
Gunny Mike

P.S. As far as using "we" inside the error messages. I asked my wife if she was okay with an application giving this type of feedback and she said it was fine with her.

Sunday, February 21, 2016

Real World Justification for Purchasing Component Source Code

I'm working on a database project using Delphi 10S Update 1. The database I'm using is ElevateDB, which is written with Delphi. I licensed the ElevateDB VCL Standard version without source code back in 2011 and maintain my annual subscription. I'm very happy with this product.

I ran into an issue where inside the IDE both the 32-bit and 64-bit platforms display data in a grid when all the components are connected and active. However, when I run the application the 32-bit version works great but the 64-bit version gives me an Access Violation.

I read that the initial Delphi 10S had a problem with the 64-bit compiler. I figured that since I upgraded to Delphi 10S Update 1, I didn't have an issue with the 64-bit version of the compiler.

What I failed to realize and only realized after three or four days of frantic postings on the ElevateDB support form, was I was using compiled DCU's. These DCU's, both 32-bit and 64-bit versions, were compiled using the initial Delphi 10S release. Therefore, the 64-bit DCU's were built with the initial flawed Delphi 10S 64-bit compiler.

Shame on me for not understanding and realizing this in the first place. If I had, I would not have acted the way I did.

This brings me to the topic of this blog post. If I had purchased the source code version of these components I could have simply done a build all and the problem would have been solved. I don't remember my reason for not purchasing the source code version. Perhaps it was the added expense. Perhaps it was my thinking "I'm never going to monkey with the code and didn't need it".

The thought never entered my mind that I could wind up with flawed DCU's because they were built with a flawed Delphi compiler.

Lesson Learned!

Semper Fi,

Gunny Mike