Be-Delphi is organizing their first (of many) Delphi Developer Day on November 17th in Edegem near Antwerp. That day will be completely dedicated to Delphi and Prism.
At Be-Delphi, Devia will be holding a talk about the new LiveBindings in Delphi XE2, so be sure to grab a hold of me and say hello !
Simplify your Delphi Code using some OO techniques (Part 1)written by Stefaan Lesage on 09/03/2010
Quite often clients require me to work on their existing code to fix some problems or add some new features. Most of the time the code was initially written many years ago, and has never been refactored or improved. Most of the times this is causing the code to become hard to read, understand and even maintain.
In this series of articles I will try to show how you could easily improve your 'old' code with some simple OO techniques and some refactoring. When writing some Delphi Code I presonally have a few rules I abide by. It would probably require my a few pages to explain them all, but here are just a few to get you started with :
- Write down what your code is supposed to do
- Think before you start writing your first line of code !
- Sketch a little Class Diagram / Class Hierarchy if necessary
- If you copy / pasted the same lines of code more than twice, it's time to refactor it ! (same rule applies if you are writing the same code more than two times)
- Classes should do what they are responsible for, nothing more, nothing less
- Try to think in Objects with their responsibilities instead of thinking in procedures and processes !
To illustrate this I will be using a little example of some code which could be used in almost any application : Saving & Loading some applicaiton settings. It's a pretty simple task, but in quite a few occasions the code used to do it is ... well ... not the best example of OO development. So, lets take this example and see what we can do with our few simple rules.
A closer look at 'The Rules'
Write down what your code is supposed to do
I think pretty much every application will be storing some settings. It doens't really matter if you use a ClientDataSet, and INI File, a simple Text file or even the Windows Registry to do it. What really matters is that an application can have some settings, they user might be able to change those settings and the application will probably need to read the settings and save them.
Well that's about it really, we have written down what our code should do. Of course we might change this in the future or add some new things to it, but basically we have everything we need to get started.
An additional advantage we have now is that we have already written some very basic documentation for our code ! This is really a good way to do it, since most of the time, if you have to write the documentation once everything is finished, chances are you'll never have any documentation. Of course we still need the discipline to update our documentation if things change, but we have something to get started.
Think before you start writing your first line of code !
While writing out what your code is supposed to do, you should also get into the habit of thinking about how it's going to do it, what it will need, ... So, what our piece of code will need is :
- Some Application Settings
- Some way to load the settings
- Some way to save the settings
- Some place to save to and load from
- Some way to display the settings
- Some way to edit the settings
- Some form we will use for display / editing purposes
- Some way to use the settings in our application
In order to make it simple, we will assume that we will be storing our Application Settings in the Windows Registry for now. We could make it quite generic though and have a load / save mechanism for the Windows Registry / INI Files or any other presistance mechanism, but that's not the main focus (yet), so we'll stick with the Windows Registry.
What's next ?
Well, this is a good place to end this first article. In the next installment we'll be taking a look at some of the other rules, and maybe have a look at some 'old' code too and check how we could improve it. Meanwhile we have some time to think about what our code needs to do, and some time to sketch out a little Class Diagram as well ...