TACG and the OO Paradigm

Building blocks for better software ...

TACG and the OO Paradigm

Users of object oriented programming languages are familiar with data abstraction, but that is not the same as data access layers. Although, data access through TACG is implemented in object oriented fashion it certainly does not have to be implemented as such. TACG's implementation benefits from certain object oriented tenets that include the following:

First, encapsulation which is the bundling of data and methods that operate on that data together in one place. TACG generated classes have properties that are columns in tables and have methods that perform operations on those tables.
Second, information hiding which protects data within an instantiated class (object) from being manipulated outside of the developers intent. This is referred to as data abstraction. TACG classes utilize class properties which shield the actual data from being manipulated directly.
Third, properties of a class have the added benefit of having accessors and mutators that can in fact implement function when a property is accessed or changed. Changing properties in TACG generated classes will often effect changes on other properties, public or private. For an example, when a property is set in a TACG generated class, an indicator property is also set so that it is easier for subsequent code to check for nulls, empty strings and other means of checking for the presence of data. This method is also easily transferred from one programming language to another.

All of these tenets ensure that a class is easily maintained and reusable which are other benefits of object oriented programming.

It is often difficult to develop a system of relational tables that match an system of objects and their relations even if tables can be thought of as objects. It is often not practical to do that either. Lets take for an example an employee object. An employee could have the following properties:

ID
Start Date
Birth Date
Title
Current Salary

Perhaps, the way that the employee object is implemented in a relational table is such that a history can be maintained on that employee. Let's suppose that a requirement is that we keep the entire salary history of an employee:

ID Time stamp
Start Date
Birth Date
Title
Current Salary

Instead of updating a single table row, we insert a new one when there is a change to employee information and a time stamp becomes part of the key to identify the current employee status. While this case may seem over simplified, and there are indeed other means for capturing changes to the employee information, the point is that the object definition and the table definition can be different in varying degrees. Table Access Code Generator helps solve some of these difficulties by generating data access classes that isolate tables from objects.

Why not try TACG?