Static and Dynamic Data Typing in Java

The concept of types is crucial as you progress as a developer. I have actually written java code about 7 years back without fully grasping this concept.

It involves understanding that a class is a type by itself (the implementation type) and can also comply with other types. You then begin to not just appreciate but ensure a clear separation between specification and implementation between interface and class. Even in simple method signatures you begin to be interested and careful about method specification, pre-conditions, effects and dependencies.

I want to focus on something else today that @requires an understanding of types in OO.
The concept and use of static and dynamic data types in java.

Application programs have to remember data. The simple way is to store them in variables.
int i =2; or Customer cust = new Customer("262621");

Every piece of data (including objects) has a type. And the type defines what you can do with that element. So type defines behavior. Types have hierarchies (remember need not be a single hierarchy) but a forest of hierarchies. From this we understand the concept of a generic (higher in the hierarchy) and specific (lower in the hierarchy) types.

A static type is a simple java class that defines fields and methods. I am really interested on how java types encapsulate data. In static data typing each field is statically declared with a type and a name. The variable (the container for data) has a specific type attached to it. Then you expose this field on the public interface of the class by suitable accessory.

Dynamic typing does not define static members. In dynamic typing the container for data has a generic type that can accommodate any kind of data. The problem this creates is that whenever you store (try to remember) data in such a container you loose information as to what the actual type was. The type of data has to be remembered along with the data element as the type of the container is not the type of the data element (as in static typing). More aptly the container type has no relation to the type hierarchy of the date elements that are stored in it. At compile time you do not know what these names or types are. It immediately implies that in a dynamic data type you do not have type safety. Now let me explain what is type safety and more what is the benefit of having type safety.

Consider a static type as follows

class Customer
{
public String getCustomerId()

public Date getBirthDate()

public String getLocationId()

.. fields and method body left out
}

Now, the application dictates that a Customer is allowed a 5% discount but Agents do not qualify for this discount. If Agent is another static type in the Application then the signature of the method to calculateDiscount( Customer argcust) is defined with an argument of type Customer. So only Customer objects can be passed as parameters.

Now suppose the application is dealing primarily with dynamic types and assume both Customer and Agent classes do not exist instead we use a class called DataObject to encapsulate data. Now that same method will be defined as calculateDiscount( DataObject argcust) .
Both Customer objects and Agent Objects appear to the application developer as DataObjects(the generic container for data). Now it is upto the developer to ensure that he does not inject a dataObject with the state of an Agent and pass it into the calculateDiscount() method. Even if he does, the compiler will not complain and will result in an runtime application bug.

The important question that an arise in your mind at this point is why go through all the pain of using dynamic types when you acheive it with static typing. True - Dynamic typing introduces a problem of lack of type safety. But it does provide certain benefits and moreover there are situations where you do not need static types at all. Those situations are characterized by the use static java beans with only state and very little behavior. Classes in the domain model immediately do not fall into this category since domain models primarily are designed around behavior. But there are many layers within an application that are essentially best suited to dynamic types. The use of static type in these situations results is unwanted coupling and also more development effort in creation and maintenance.

Some of the layers are
a) edge data parsing - either from the network or from files. XML & fixed width parsing included does not require static types.

b) Application Config Information - is fundamentally dynamic in definition.

c) Relational Data Managers - That reads data from RDBMS.

Further, it is far more powerful to use codegen or bytecode manipulation to generate static types from Dynamic type objects based on some type definition (XML Config). This layer then becomes a data mediator service between the world of static and dynamic types.