Tuesday, August 15, 2006
Designing for the future
Most programmers doesn't take care of the future of the software they're writing, they just try to make it work and send it to the market. But many times, when a customer asks for a change, very large portions of the code must be rewritten. This is specially known in applications that share Database, Business Rules and User Interface.
A large portion of Object Pascal developers came from Delphi, where one tend to think in a Delphish (RAD) way, placing data aware components inside their UI forms, then adding another form and placing more data components inside it and so on (with forms i mean TForms and TDataModules). This method of working, can be very rapid in small applications, but in enterprise-class software this approach can cause more headaches than applauses.
Must be a better way
The first step to architect your software for the future is to identify what parts can be classified into Database, Business Rules and User Interface, i'll call them packages (don't confuse with Borland Package Libraries) so you'll end writing Database package, BR package and UI package. Each package must have an interface to communicate with the world (other packages), so if you whant to execute a function (or method) that retrieves information from a database, just call the Database package and access to the required method.
Supouse your application uses a Database package that connects to MySql, and your customer uses an Oracle server. It's easier to create a new package for Oracle than rewriting the whole program.
The same rule applies to user interfaces. Using modules like i propouse, your application's Business Rules can be shared by Win32 UI, GTK UI, Web UI or something else without re-coding busines rules and database access for every UI client.
It's not rocket science
This method of working receives the name of MVC (Model-View-Controller), a Design Pattern used mostly in modern web environments (in Java and .NET especially), but applies to any object oriented language and fills very well in Object Pascal.
To communicate different packages, i recommend not to use any platform nor language native feature. With simple shared libraries (like i explain in this post), you can create portable, cross-platform applications that works for the future.
Feel free to express your opinions about this approach.
A large portion of Object Pascal developers came from Delphi, where one tend to think in a Delphish (RAD) way, placing data aware components inside their UI forms, then adding another form and placing more data components inside it and so on (with forms i mean TForms and TDataModules). This method of working, can be very rapid in small applications, but in enterprise-class software this approach can cause more headaches than applauses.
Must be a better way
The first step to architect your software for the future is to identify what parts can be classified into Database, Business Rules and User Interface, i'll call them packages (don't confuse with Borland Package Libraries) so you'll end writing Database package, BR package and UI package. Each package must have an interface to communicate with the world (other packages), so if you whant to execute a function (or method) that retrieves information from a database, just call the Database package and access to the required method.
Supouse your application uses a Database package that connects to MySql, and your customer uses an Oracle server. It's easier to create a new package for Oracle than rewriting the whole program.
The same rule applies to user interfaces. Using modules like i propouse, your application's Business Rules can be shared by Win32 UI, GTK UI, Web UI or something else without re-coding busines rules and database access for every UI client.
It's not rocket science
This method of working receives the name of MVC (Model-View-Controller), a Design Pattern used mostly in modern web environments (in Java and .NET especially), but applies to any object oriented language and fills very well in Object Pascal.
To communicate different packages, i recommend not to use any platform nor language native feature. With simple shared libraries (like i explain in this post), you can create portable, cross-platform applications that works for the future.
Feel free to express your opinions about this approach.
