By now, you should be quite comfortable with the idea of object-oriented programming, as well as truly sold on all its benefits. Indeed, OOP allows you to develop highly maintainable, clear, logical code that conforms more closely to a humanized version of your application. Yes, it adds some development overhead, but the benefits will be enormously clear should you, or anybody else in your organization, ever need to look at that project again.
One of the downfalls of this approach, however, is that you may sometimes have to sacrifice raw efficiency to achieve true compliance. For example, so many Web applications have simple pages that allow a user to edit an entity be it a user, a product, an order, a customer, or whatever. The non-OOP approach is quite straightforward an HTML form with a single UPDATE SQL statement to make the amendments. The OOP approach, by contrast, can seem frightening a class called Customer, with goodness knows how many methods just to update its own properties in the database. The real downer is that huge chunks of the code you'll have in each entity class that is, in the classes representing users, products, orders and customers will be replicated time and time again.
Thankfully, there is another way; it's called GenericObject. In this chapter, you'll be introduced to it and its sister class, GenericObjectCollection, and see how together they can cut your coding time in half while still allowing you to achieve true OOP compliance and all the benefits that brings.