How to : Implementing business objects
Implementing business objects
Classes that encapsulate business rules lay the foundations of a true object oriented application.
Implementing Business Objects
This article is the first of a series in which we'll be exploring the many facets of implementing a true object oriented application. Along the way we'll take in almost every aspect of application design and challenge some of the accepted ways of writing a Delphi application. The fundamental concept behind this approach is encapsulation: to design a set of classes with well-defined interfaces (methods) that operate on properties. These concepts will pervade the entire application and will greatly affect the way in which data is stored and presented. I would recommended readers to study Francis Glassborow's C++ column; although the Delphi object model lacks the completeness (and the complexity) of C++, the concepts of good class design are independent of language.
Most typical Delphi applications written today are not object oriented. Just because the language has an object model and many existing and new classes are used, this does not mean that the application can be regarded as truly OO. Code reuse has finished with dropping third party components onto forms, and interdependencies between forms and units quickly proliferate. Future opportunities for changing application fundamentals (such as switching database or moving from 2-tier to 3-tier implementation) are severely limited or very expensive to contemplate. Writing the application in a true OO fashion would facilitate, rather than restrict, these opportunities. However, writing such applications requires a mind shift, accompanied by an initial lack of productivity, that most development teams are loath or unable to consider. Over the course of these articles I hope to demonstrate some of the fundamentals which will help developers make the move to implementing better applications. The resultant systems will always be more reliable, maintainable, consistent, flexible, reusable and generally perform better than an application written in the standard fashion. In particular, the benefits of code clarity are such that for large applications, one written in a truly OO fashion can require significantly fewer maintenance resources than the same application written traditionally. I should perhaps justify these benefits of an OO application further: I believe that few IT advocates with something to sell (in this case the vision of better applications) should get away unchallenged!
The enhanced reliability of OO applications comes from the fact that data and operations are encapsulated in well-defined classes. The compiler itself will encourage correct class, method and property usage through strong type checking, and having unique rather than duplicated code means that future changes to a single routine are pervasive throughout the application. A consequence of the correct usage of classes is that the relationships between them are self-evident and a far greater proportion of the code written is actually implementing the "meat" of the application, rather than worrying about details such as how data is actually stored persistently. This makes the application significantly easier to maintain, a factor further simplified by greater consistency throughout. As we shall see, using class inheritance extensively both increases productivity and reliability, but also imposes consistency. This consistency is evident in the way that code is laid out and how classes behave, but also to the extent of how data is stored and how the user interface is presented. As much of the functionality is provided in base classes, it is possible to quickly change their behaviour to fundamentally affect the application (such as changing the interface to be html-based, rather than form-driven). These base classes can be designed to be application-independent, so that the second application written this way gains an immediate productivity boost. A good set of base classes can provide up to 50% of the code in a medium-sized application, an obvious benefit from a time, cost and reliability standing. It is only reasonable to highlight that making the switch to "real" OO development is non-trivial and should only be undertaken for the first time with experienced assistance, or for a project of small size without urgent deadlines. It should also be stressed that an OO solution does not dictate other classes that must (or must not) be used within the application. If a company has developed their own visual components, uses those of a third party, or has standardised on a particular database platform then there is no reason why these cannot be used (with one significant exception). Developing an OO application is about applying a consistent set of design patterns rather than dictating what components should be used.
Focused classes
The first step in designing any object-oriented application is thinking about..