Overview‎ > ‎Executive Overview‎ > ‎

Objects Overview

We think Automated Business Objects makes it easy to create sophisticated business logic, even if you are new to much of the underlying technology.  This page is provided as a mercifully brief summary of some key technology topics around business logic: Object Orientation, Hibernate, frameworks and so on.




Object Basics: Classes and Object Instances

Most languages have provided "data structures", which can be used to represent database rows.  The problem was that exposing "raw data" makes every access responsible for maintaining data integrity.

For example, certain changes to an Order (paid flag, change amountTotal, inserts, deletes etc) may require an adjustment to a Customers balance.  It is unwise to presume every such access - spread out of hundreds of thousands of lines of code - will get it right, every time.

Objects address this by combining the access code into the data structure.  So, in our example, an Order Data Structure becomes an Object Class.  This class (perhaps a java file) defines the data, and provides "subroutines" (now called methods) that comprise the only means of accessing the data.  So, for example, you see code like this:

Purchaseorder order = new Purchaseorder();

order.setDate(new Date());

order.save()

In the example above, Purchaseorder is a class that provides methods to 

  • create Purchaseorders, and 
  • access (set and get) data (such as date), and
  • save the order to disk
The Purchaseorder class might look somewhat like this:

public class Purchaseorder implements java.io.Serializable {

private Long orderNumber;  // data in object (called "instance variable")

private Date date;         // more data  


// methods to get/set order# for users of this class

public Long getOrderNumber() { return orderNumber; } // method to acquire order#

public void setOrderNumber(Long orderNumber) { this.orderNumber = orderNumber; }

... etc 


order is an object instance (often shortened to instance or object) of the Purchaseorder class, here created by new Purchaseorder().  In database terms, a Class corresponds to a table, and a row corresponds to an instance.

You might also acquire instances of Purchaseorder by reading them from disk:

order = getObjectById(Purchaseorder.class, 1L);  // read purchase order 1 from disk (or cache)


In physical terms, Objects are usually coded as a Java source file.  Java Objects are name scoped into packages that together serve a useful function (e.g., mycompany.accounting or ourfirm.inventory).

They are compiled into Java Classes, an executable platform-independent file.  A typical application is composed of many classes packaged into a jar file (essentially a zip).  

Groovy is an attractive alternative

Groovy enables you to write the equivalent of Java classes, where the accessor methods are not required.  This makes it much easier to write domain classes, and logic classes.  You can see a downloadable example here.

Key Object Concepts

Some key concepts are described below.

Encapsulation

This was introduced above: a Class combines the data and the methods to access that data.  The contract is that the class is responsible for maintaining integrity over any use of public methods.

Information Hiding

Closely related to encapsulation, this means the class hides whether data is stored or computed on request.  So, aCustomer.getBalance() may simply return a stored value, or access the Purchaseorders to sum the balance.  The key point is that this enables the Class to change the strategy without affecting calling code (rather like adding / dropping a relational index).

Inheritance

Here is where things depart rather radically from traditional data structures.  You can build one class that extends another, meaning that it adds new data / methods while re-using the existing ones.  For example, HourlyEmployee may extend Employee, adding in wage and union.

There is no counterpart to inheritance in relational database, representing one aspect of what is often called the impedance mismatch.  A heated topic - discuss with care.

Interface

A strongly held principle is that classes should be distributed both as the Object Class and as an Interface.  An Interface is a class definition that defines the calling sequence of all the code.  Users of the class program to the interface, where the actual instances might be from any class that implements the interface.

This enables alternate implementations of the class to be substituted without changing calling code.

Java Beans, POJOs, Domain Objects

Note the order.getOrderNumber() method above.  This is an important convention: for each Instance Variable, define a set and get method for caller access.  A POJO (Plain Old Java Object) is a simple Java Bean with no other code in it.  In the context of database applications, these are often called Domain Objects.


Hibernate/JPA - Domain Objects

Hibernate and a later version standardized as JPA (Java Persistence Architecture) provide mechanisms for Java Programmers to write and write Java Domain Objects from a relational database.  The basic idea is
  1. Define a Domain Object - a Java Object representing a table, with attributes for columns (e.g., Domain Objects for Customer, Order etc)
  2. Annotate the Domain Object to signify the database mappings (see here for an example)
  3. Invoke Hibernate APIs to read/write Domain Objects

Frameworks and event oriented programming

Building a modern web application is quite complicated, so there are many packages called frameworks that can help.  A framework is a set of classes that automates useful things to reduce your work, such as reading and writing html pages.

To enable their users to extend the package without requiring its source code, frameworks provide events that are callouts to your code.  So, for example, a GUI (Graphical User Interface) framework might provide a Button object, which provides a "clicked" event for you to program (ie, handle the subroutine - method - call made by the framework to your code).  This is called event oriented programming - the framework is "in charge", calling your code as required.

Frameworks are not limited to GUIs.  There are also frameworks for persistence (see the discussion on web apps), and other areas.


Web Applications

These concepts play into how we might build a web application.  A web application reads data from a database, presents it to the user, and provides buttons to save/submit changes back to the database.  Or, it may process electronic messages from another system.


Spring: injection

The whole concept of interface-based programming becomes very difficult to achieve when you introduce frameworks with the need to extend portions of them.  Why?

Let's imagine you are using a GUI framework, and you've extended the Button class to meet your needs.  Which is great when your code instantiates the button (calls new Button()).  But in all likelihood, it was the framework that performs this instantiation.  So your class exists, but is never used.

Spring tacked this problem by providing conventions for object creation, and by providing xml-based properties files to designate the desired class to instantiate for a given interface.  So you just designate your class in this properties file, and Spring-based frameworks suddenly instantiate your class rather than the basic one.

This is often called Injection, since your class instances are injected into "blind references" made in other classes, perhaps inside the framework.

Comments