Structure and Modular Coding in an Object Oriented World

I'm sure you have read about my Sim Game Selector program in "Object Programming for Old Time Programmers - Using Tight Object coding for toggling Icon Buttons in a Window".

This Tutorial is a culmination of all my work on the Sim Game Selector. This tutorial does not have any code pieces but it will point you to two modules that I have uploaded here at AHK that may be useful to you in future projects. I will also talk about coding practices that if you are a program newbie, it is best to absorb this info now before you take on bad habits.

If you are a Sims 3 Game Player, you will find my program at "ModtheSims.info" .

Edited: added program flow

------------------------------------

[ Resourceinit => unpack icons]

[ create icon Gui menu]

[events pressmybuttons]

[events launch button]

[events save]

[events exit includes ResourceCleanup]

---------------------------------

Event driven coding has simplified much of the programming in the last 20 years. No longer do we need to monitor the status of the system unless you are writing a first person shooter or a game, a menu system just sits around until someone clicks on a menu selection, a button or an icon.

Event driven coding is simply the assigning of a routine to a button click or event. The routine doesn't execute until someone clicks the button. In autohotkey you can assign programming to events to almost anything which is why it is called autohotkey.

However this doesn't mean that we can forget Structure and modular programming as this fits alongside event driven coding. Once you have determined that your program will do something when the user selects a button to click, the scope of the modularization begins.

Both Structure programming and Modular Programming are programming paradigms or better said to be a method of programming or just a way of programmer's life back in late 1960's. Although I'm not that old, I've adopted both method of programming ever since my beginnings and I've never regreted this strict regime.

Structure programming aims at improving the code by making extensive use of subroutines, block structures, for and while loops. There are absolutely no Goto's or jumps.

Modular programming is also called "top-down design" emphasizes separating the functions of a program into independant interchangeable modules such that every piece contains everything necessary to execute only one aspect of the total function.

Object programming is the nemesis of the above two; in other words most programmers will find it difficult to use all 3 methods together effectively. Although it may seem simple to move function driven code into method driven code, many functions are not really methods. The other differences is that Objects are single self objects that has it own self contained functions that operates on it self where-as global functions operates on the many.

A good example of this is my function that reads and writes into the Window's registry. Although my object has it own method to read and write into the registry, it still uses the function call to do this. Thus any changes to the registry functions remains external to the object and keeps the "object" separate from the registry functions.

-------------------------------

Structure Programming

-------------------------------

Structure programming is really easy to follow programming style. Entry and exits are top in and bottom out, just like a function, or a sub-routine where entry point is the label and the return symbolizes the exit.

I do not like "returns" in the middle of the subroutine, as if your program encounters a problem, it could be your return scattered in the middle of all your subroutines. Always route your program flow so that it ends up at the end of the subroutine or function and only one "return" exists fro the whole structure.

Do indent your if-then and loops. This gives you the idea of the flow.

Create functions that can genericly be used for multiple purposes, such as my Regcopy(source, target).

If a function requires too many parameters, then it might not be good idea that this be made into a function call. Try not to use global variables in functions as this defeats the purpose of a function which is a total self contained program that operates on a few parameters.

-----------------------------

Modular Programming

------------------------------

When I was a youngster I really hate flow charts and the concept of top down or bottom up design. I also hated the idea of a too fine modularization where if all your module did was Print, then you should just include this as part of your code rather then calling a function. However if the function was named Logme() which implies that it could perform something greater, such as outputing the message to debugging device as well as logging the message to a text file which requires opening, append and closing a log file, then by all means separate the print to a function call so that all logging calls are from one place.

It is a fine line on the division of your program into modules. Don't divide your program into too many pieces that grinds the program into dust, but "do" divide your program into replaceable modules that can be replaced with a similar function.

My Self Resource Compactor was replaced by my "Fileinstall" script. This was my contribution to AHK script forum for bundling all your icons into your program for distribution. Both methods are valid, but I changed from one to the other when I thought DLL calls was causing problems for 32 bit machines.

------------------------------------------------------------------------------------------------

Using Structure and Modular Programming with the Sims Game Selector

------------------------------------------------------------------------------------------------

When I first began tackling the problem of building the Sim Game Selector program, I divided the whole program into functional pieces just to find out if it was feasible.

The first step was to test the feasibility of using AHK as the Graphical User Interface. This beame the GUI interface built from Smart Gui then became a stand alone icon graphic user interface. Later on when I started using Classes and objects, this module became my first example of using Class, objects and methods.

The second module that I built was the feasibility of reading and writing to the Windows Registry. This involved testing recursive function (a function that calls itself) within AHK to copy the whole Electronic Arts registry tree. Once this was done we were able to issue function calls to copy, delete and move whole registry trees with aplomb. We added global variables that contained all the Expansion and Stuff Packs that EA sold and tested them out against the registry making sure we had all the names correct. Once all this was tested, I threw all of this into a registry.inc package that I could used later for handling all the registry functions. It was a self contained package that had it own test routines, that when incorporated with the main program, the routines were usable as part of methods or called from button clicks without further worries about the validity of the registry reads and writes.

The last module was the "Resource Compactor" replaced by the "File Install" module. There are two pieces to both of these modules, the

ResourceInit() and ResourceCleanup() were replaced by #include fileinstall.txt and #include filedelete.txt which both have similar processes.

Resourceinit() checks if all the icons have been added to the end of the .EXE and proceeds to extract them to the temp directory if found. FileInstall.txt is generated by the program createfileinstall.ahk which is a short ahk program listed in the script forum which creates a "fileinstall" line to the temp directory for every file that you have in your current working ahk directory.

ResourceCleanup() deletes all the extracted icons and files from your temp directory. Filedelete.txt is also generated by the program createfileinstall.ahk which deletes every fileinstall file in your temp directory.

Thus you can see that modular programming has its benefits. Here is a summary of how the modules were replaced in the final coding.

1. the gui became wrapped up into the class by toggling the icons within the object methods. (see "Object Programming for Old Time Programmers")

2. objects replaced all the GUI event driven coding by using associative arrays thus reducing the if static1 then do icon function 1 etc... reducing program code by 50-75%!!

PressmyButtons: MouseGetPos, , , id, control

simbuttons[control].toggle()

return

3. reading and writing to the registry became part of the object but the method still called the external registry function instead of merging with the object, which also reduce the bulk of the code by using

for key, value in simbuttons

simbuttons[%key%].update_registry()

4. resourceinits() became fileinstalls and resourecleanup() became file deletes. Both were valid, but now I'm using an AHK built-in function versus an external DLL call which could have been a problem with 32 bit systems.

Review

---------

Remember that every module can be a standalone program with its own test functions. You can delete the test functions after it has been integrated with the rest of the program; or you can simply leave them as comments just in case you want to use the test functions to test out replacement coding in the future.

Although the final program code will contain interweaving of calls to the modules, the flow of the program should allow you to replace the calls to any module with similar or identical calls to a different module making updates and problem debugging easy.

Structure programming is simply the single entry and exit point for subroutines, functions and the single entry and exit flow of the main program. Don't use Goto's or jumps.

Objects should always be self contained like iconbutton.on() iconbutton.off() and iconbutton.regupdate(), but don't be afraid to mix external function calls with objects and it isn't necessary to migrate all functions into methods but use a mixture of both to keep it clean.

I hope this was helpful...

Thank you for reading..

RalphaelNinja

Sign In