Here's how I will code better in Delphi. How will you?

Disclaimer: This post contains affiliate links, which means I may earn a small commission if you click through and make a purchase, at no extra cost to you. Your support helps keep this blog running – thank you!

When it comes to Delphi, it's amazing how much I don't know, once knew but forgot, or just plain skipped over because it was too mind-boggling at the time. I took a break from reading Alister Christie's new book "Code Better in Delphi", which I purchased last night, to write this blog post.

https://amzn.to/4dE8oOq (Paperback)

While reading the bit on "refactoring", I realized how little refactoring I actually put into practice. Yes, I have Fowler's book, the second edition. And no, I haven't read it. I've thumbed through it a little in the past. I even tried looking for the "Introduce Explaining Variable" refactor Christie discusses on page 53 of his book. It turns out Fowler now calls it "Extract Variable". Keeping Fowlers "Refactoring" book on my desk, and referring to it often, is one way I am going to code better in Delphi.

It's amazing how much I don't know or once knew but forgot

I just started reading "The Observer Pattern" in Christie's book and had to stop. I bought "Head First Design Patterns" by O'Reilly, quite a few years ago. I have the 10th Anniversary edition with code examples in Java 8. My intent was to install Java on my machine and force myself to learn these patterns by following the code in the book. It didn't go so well. The authors do a great job using story to make learning fun. I just couldn't wrap my head around Java.

Christie has managed to reignite my desire to learn these patterns. I downloaded the Java source code. I plan to work my way through "Head First Design Patterns" pasting the Java source code into ChatGPT, and asking Chat to convert it to Delphi.

I will navigate through each pattern using this method. I will then revisit the same pattern in Primoz Gabrijelcic's book "Hand-On Design Patterns with Delphi". This is another way I'm going to learn to code better in Delphi. 

Another way is to revisit the Model-View-Controller method of code separation. Here is a the MVC song from 2007 I just learned about today. 

And I also want to implement "Interfaces".

Here's my list of how I will code better in Delphi:

• Finish reading Christie's book 
• Practice refactoring often
• Learn and implement design patterns
• Discover and utilize ways to separate code concerns such as MVC or MVVM
• Overcome my stumbling block of Interfaces

Use the comments below to share how you will code better in Delphi.

Enjoy
Semper Fi
Gunny Mike

https://zilchworks.com

Note: Some links in this post are affiliate links, meaning I may receive a small commission if you make a purchase. This helps support my work – thank you for your understanding.

Don't Just Code in Delphi, Think in Delphi

I have always struggled with fully understanding the object oriented nature of Delphi. I still struggle with it today. For example, I have tried to read Nick Hodge's book "Coding in Delphi" three times and can't get past page 23. I'm currently on page 96 of Pawel Glowaki's book "Expert Delphi" and had to stop because he talks about using the TTextWriter class which is a class with virtual abstract methods. Virtual Abstract Methods, are you kidding me. What the hell are Virtual Abstract Methods.

(Expert Delphi page 96) "Notice that the TTextWriter class is a class with virtual abstract methods that just define the interface to the text writing functionality so we need to use one of the text writer descendants such as TStringWriter."

Okay, so I get a small glimpse into what Pawel's talking about. These VAM's are just interface definitions. They don't really exist. The real functions exist somewhere else. In this case the TStringWriter class. I'm just barely hanging on here, but I'm hanging on.

I blame my Delphi ignorance on my lack of going back to square one and learning Delphi's OOP think from the beginning. At the time I started using Delphi I just plowed ahead and made the code work. I wanted a Windows program and that is all I cared about. Looking back at it, I'd say I forced Delphi to work like my top-down procedural thinking. I never fully embraced the Delphi OOP think.

Hodges, Glowaki, Cantu, and all the other Delphi authors out there think in Delphi. And if I want to understand them and be proficient in Delphi I need to think in Delphi too.

So, how do you think in Delphi?

You find a resource that explains Delphi in a simple straight-forward manner. Perhaps a resource that teaches you how Delphi came into being. Does such a resource exist? Yes. And I just so happened to have a copy on my bookshelf.

Here are three paragraphs from page 7 and 8. If these paragraphs speak to you like they did me, then I highly recommend you read the entire Turbo Pascal 5.5 Object Oriented Programming Guide.

The challenge of object-oriented programming (OOP) is that it sometimes requires you to set aside habits and ways of thinking about programming that have been considered standard for many years. Once that is done, however, OOP is simple, straight- forward, and superior for solving many of the problems that plague traditional software programs. 

A note to you who have done object-oriented programming in other languages: Put aside your previous impressions of OOP and learn Turbo Pascal 5.5's object-oriented features on their own terms. OOP is not one single way; it is a continuum of ideas. In its object philosophy, Turbo Pascal 5.5 is more like C++ than Smalltalk. Smalltalk is an interpreter, while from the beginning, Turbo Pascal has been a pure native code compiler. Native code compilers do things differently (and far more quickly) than interpreters. Turbo Pascal was designed to be a production development tool, not a research tool. 

And a note to you who haven't any notion at all what OOP is about: That's just as well. Too much hype, too much confusion, and too many people talking about something they don't understand have greatly muddied the waters in the last year or so. Strive to forget what people have told you about OOP. The best way (in fact, the only way) to learn anything useful about OOP is to do what you're about to do: Sit down and try it yourself.

I'm convinced this little 124 page resource will give me the solid foundation of Delphi think that I've  been missing. I was so excited to find this little gem and what it offers, I had to stop reading and tell you guys about it.

A copy is available on archive.org

Enjoy!

Semper Fi
Gunny Mike
zilchworks.com

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. (wayback machine link)

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 (https://goo.gl/PNq7bY). 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.)

Amazon: https://goo.gl/MVybeZ

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. (https://goo.gl/B7U5RR) 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    |
+--------------------------------+
ForwardOne 
ForwardTwo
AttackLeft
AttackRight
EnPassant

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:
Pawn1.PawnMovement.ForwardOne
Pawn1.PawnMovement.ForwardTwo
Pawn1.PawnMovement.AttackRight
Pawn1.PawnMovement.EnPassant

Don't Think this:
Pawn1.ForwardOne
Pawn1.ForwardTwo
Pawn1.AttackRight
Pawn1.EnPassant

Enjoy!

Semper Fi,
Gunny Mike

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.

BOOM!

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
SOLID = JJDIDTIEBUCKLE

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.

Enjoy!

Semper Fi,
Gunny Mike

How to Replace Global Variables by Using a Static Class

One of the first things I used to do when creating a new Delphi application was add a copy of the almighty global.pas unit to the project. I'd immediately go in to this file and start tweaking this and tweaking that so it would work with my new application. And, I made sure to ALWAYS add Globals to the uses clause of every new form I created.

My Delphi buddy Bob Wight, who is Scottish and speaks with a very heavy brogue, called his "Globs". Which stood for globs.pas. I remember him saying, "The programmer's life. Another day, another global." It sounds really cool with his Scottish accent.

Anyway, I thought this was the normal way of doing stuff. I thought every Delphi programmer did this. I never challenged it. Not ever.

Now, as I'm re-learning Delphi all over again for the first time, I hear several Delphi people, in the various Delphi hangouts, say stuff like, "Never use global variables" and "Pretend like global variables don't exist".

I'm thinking to myself... "Okay how the heck do you program if you can't use global variables?"

So, last weekend learned how to replace global variables in my Delphi application by using what is called a static class. It turns out that a static class can simply exist without having to be instantiated. That is pretty cool.

A static class can have constants, variables, functions and procedures. Its like having global variables on steroids. I have replaced my globasl.pas file with a file called ApplicationInfo.pas. I've included a copy of this file below.

This is a fairly new concept for me and it will no doubt go through some changes and refactoring. But so far, I'm liking it.

Here's a couple ways I'm implementing the use of my TAppInfo static class.

procedure TfmMain.FormShow(Sender: TObject); begin Label1.Caption := TAppInfo.AppInfoCopyright; Label2.Caption := TAppInfo.AppInfoWebsiteName; end; procedure TfmMain.Label2Click(Sender: TObject); begin TAppInfo.GoToAppInfoWebsiteURL end;
The cool part is the Intelisense... I just type TApp and hit [Ctrl] + [Space] and I can pick the item I want. No more "Globs" for this Marine!

ApplicationInfo.pas
unit ApplicationInfo; interface type TAppInfo = class public const AppInfoWebsiteName : string = 'www.creditcardmath.com'; AppInfoWebsiteURL : string = 'http://www.zilchworks.com/buynow.asp'; AppInfoCopyright : string = 'Copyright 1994-2014 © by Michael J. Riley. All rights reserved.'; AppInfoName : string = 'Credit Card Math'; class var AppInfoPathData : string; AppInfoPathLocal : string; class constructor Create; class function SetAppInfoPath(CSIDL:integer): string; static; class procedure GoToAppInfoWebsiteURL; static; end; implementation uses ShellApi, Windows, Winapi.SHFolder; // ---------------------------------------------------------------------- // Added: 07-12-2014 after reading the comment by Uwe Raabe // https://www.google.com/+UweRaabe // http://www.uweraabe.de/Blog/ // ---------------------------------------------------------------------- class constructor TAppInfo.Create; begin TAppInfo.AppInfoPathData := TAppInfo.SetAppInfoPath(CSIDL_COMMON_APPDATA); TAppInfo.AppInfoPathLocal := TAppInfo.SetAppInfoPath(CSIDL_LOCAL_APPDATA); end; class function TAppInfo.SetAppInfoPath(CSIDL:integer) : string; var LStr: array[0 .. MAX_PATH] of Char; S : string; begin SHGetFolderPath(0, CSIDL, 0, 0, @LStr); S := LStr; Result := S + '\' + TAppInfo.AppInfoName; end; class procedure TAppInfo.GoToAppInfoWebsiteURL; begin ShellExecute(0, 'open', PChar(TAppInfo.AppInfoWebsiteURL), nil, nil, SW_SHOWNORMAL); end; // ---------------------------------------------------------------------- // Commented: 07-12-2014 after reading the comment by Uwe Raabe // https://www.google.com/+UweRaabe // http://www.uweraabe.de/Blog/ // ---------------------------------------------------------------------- (* initialization TAppInfo.AppInfoPathData := TAppInfo.SetAppInfoPath(CSIDL_COMMON_APPDATA); TAppInfo.AppInfoPathLocal := TAppInfo.SetAppInfoPath(CSIDL_LOCAL_APPDATA); *) end.
Enjoy - Semper Fi,
Gunny Mike

end.