I've been busy lately providing training in implementing object orientation (OO) with ColdFusion components (CFCs) to several companies. I've found that most ColdFusion developers approach OO as something to "layer on" over their traditional programming practices. Even many Java developers make this mistake, which means that they don't often see many benefits from a foray into object orientation. The error stems from a lack of understanding. OO design is fundamentally different from procedural design, so a major shift in thinking is required in order to gain the benefits of greater code maintainability and reuse.

The concept of abstraction underpins all other principles and practices of object orientation. In his book, Object-Oriented Design with Applications, Grady Booch (one of the authors of the Unified Modeling Language) defines abstraction in the following way:

"An abstraction denotes the essential characteristics of an object that distinguish it from all other kinds of object and thus provide crisply defined conceptual boundaries, relative to the perspective of the viewer."

Abstractions are concerned with the simplification of reality, sparing users the myriad of details that may be associated with that reality. All abstractions have two things in common: an interface and one or more implementations. Users of the abstraction simply need to learn the interface, ignoring what may be a bewildering level of detail in the implementation. Abstractions make it possible for people like me to drive cars and run dishwashers.

Abstractions are not new to object orientation. In fact, you're very familiar with one particular abstraction: ColdFusion. When you want to send an e-mail, for example, you use the <cfmail> tag. CFML is an abstraction of a lower-level language, Java. Java itself is an abstraction of a still lower-level language. There's nothing you can do in ColdFusion that you cannot do in Java, but we value ColdFusion because it provides a simple interface to the complexities of the underlying languages.

When we undertake the creation of an object-oriented design, we engage in the process of creating and defining abstractions -- at least we do if we want a good design. But people engaged in application design too often mistake their mission: they think they're writing code instead of designing abstraction layers. Thus, they concentrate on the implementation and neglect to abstract the details into a simpler interface.

Let me provide an example. Recently, I spent a week at a large bank helping developers "get their heads around" object orientation. I find it helpful to use examples related to the client's domain, so we began by talking about banks and the banking system. What I wanted them to derive was a domain model - an abstraction of their world that could be modeled in software. What they quickly began work on was a data schema for a relational database.

I expected this: most developers look to the structure of the relational model to provide structure to their code. But databases - at least in the OO world - exist only to make it possible to persist objects. It's the objects - those abstractions of the real world - that provide an OO program with its ability to accomplish tasks.

The trouble with viewing the application through the lens of the database schema is that, while the relational model is an excellent one for storing data, data is the wrong abstraction layer for application design. (Data itself is an abstraction: we don't store actual dollars in a database, we store numbers that stand for dollars.)

In tackling the challenge of a complex application, we need to employ a "divide and conquer" strategy. Large problems are composed of several constituent problems; each of these smaller problems can be further broken down. Every level is an abstraction, with its own stable interface and an implementation that is subject to change. This is the essence of object-oriented design.

Our challenge in writing applications is to derive abstractions on multiple levels. The needs of the system's users must be abstracted, the details of the system itself must be abstracted, and, finally, the underlying business area or domain must be abstracted. This threefold abstraction process has been formalized into a design pattern called Model-View-Controller, into which each component of an application fits. User interfaces are the purview of the view layer, the workings of the base application machinery fall under the command of the controller, and the business domain is the responsibility of the model.

View components are usually the least interesting to programmers, although they are the most interesting to actual clients. The controller is often implemented as a framework. In the ColdFusion world, both Fusebox and Mach-II are controllers for applications. The model layer must be individualized for each business and each domain. The creation of a domain model consists of abstracting base elements, from which we build up larger elements until we have a good abstraction layer that can serve many individual applications.

Let's go back to the bank example. One of the base elements of any banking system is the idea of a currency issued by a country. Procedural programmers might represent this by a string such as "euro" or by a number that represents the currency. In OO land, we abstract the notion of a currency as an abstract data type.

We're used to thinking of data types in terms of boolean values, numbers, or strings. But OO's data types tell us what kind of behavior the data type is capable of in addition to what kind of information the data type can hold. In other words, a data type has both properties and methods. If this sounds like the description of a ColdFusion component (CFC), you're quite right: CFCs are abstract data types. To model a currency, we would create a Currency CFC that looks something like this:

<cfcomponent displayname="Currency">
	<cfset variables.name =  "null" />
	<cfset variables.country = "null" />

	<cffunction name="init" access="public" 
      returntype="Currency" output="false">
		<cfargument name="name" 
             type="string" required="true" />
		<cfargument name="country" 
            type="string" required="true" />
		<cfset setName(arguments.name) />
		<cfset setCountry(arguments.
             country) />
		<cfreturn this />
	</cffunction>

	<!--- getters and setters --->
	<cffunction name="getName" access="public" 
     returntype="string" output="false">
		<cfreturn variables.name />
	</cffunction>
	<cffunction name="setName" access="public" 
     returntype="void" output="false">
		<cfargument name="name"  
            type="string" required="true" />
		<cfset variables.name = arguments.
             name />
	</cffunction>

	<cffunction name="getCountry" 
      access="public" returntype="string" 
        output="false">
   	<cfreturn variables.country  />
   </cffunction>
	<cffunction name="setCountry" access="public" returntype="void" output="false">
  <cfargument name="country" 
  type="string" required=
  "true" />
   	<cfset variables.country  
      = arguments.country  />
   </cffunction>
</cfcomponent>

When I showed this to the class, most people thought I had missed an amount property. Otherwise, how could we model something like depositing $500? All that the Currency CFC should do, however, is abstract the idea of a currency - not a specific number of dollars. To reflect an actual transaction, such as a deposit, we should create an abstraction of a transaction.

To do this, we ask ourselves, "What is common to all transactions?" We might decide that all transactions have a currency, a specific quantity of that currency, and a bank account. We would then create another abstraction/CFC: Transaction.

<cfcomponent displayname="Transaction">
	<cfset variables.currency = "null" />
	<cfset variables.quantity = 0 />
	<cfset variables.bankAccount = "null" />

	<cffunction name="getCurrency" 
     access="public" returntype="Currency" output="false">
   	<cfreturn variables.currency  />
   </cffunction>
	<cffunction name="setCurrency" 
     access="public" returntype="void" 
      output="false">
   	<cfargument name="currency" type="Currency" 
     required="true" />
   	<cfset variables.currency  = arguments.
     currency  />
   </cffunction>

	<cffunction name="getQuantity" 
     access="public" returntype="numeric" 
     output="false">
   	<cfreturn variables.quantity  />
   </cffunction>
	<cffunction name="setQuantity" 
     access="public" returntype="void" 
     output="false">
   	<cfargument name="quantity" type="numeric" 
    required="true" />
   	<cfset variables.quantity  = arguments.
     quantity  />
   </cffunction>

	<cffunction name="getBankAccount" 
     access="public" returntype="BankAccount" 
      output="false">
   	<cfreturn variables.bankAccount  />
   </cffunction>
	<cffunction name="setBankAccount" 
     access="public" returntype="void" 
     output="false">
   	<cfargument name="bankAccount" 
    type="BankAccount" required="true" />
   	<cfset variables.bankAccount  = arguments.
     bankAccount  />
   </cffunction>
</cfcomponent>

Notice that the bankAccount property is not a string or number, but an object of type BankAccount -- another abstraction.

The class thought that I had also missed another important aspect: the type of transaction, such as "deposit" or "withdrawal." They expected to see a property labeled transactionType. While we might do this in procedural programming, in object-oriented programming we rely on types rather than labels so we would subtype Transaction with a Deposit CFC and a Withdrawal CFC. The simple UML diagram showing the relationship between components for a simple banking model might look like Figure 1.

If this strikes you as a lot of "stuff" for something so simple, you're not alone: most of my students thought that I was exaggerating abstraction to make a point. Even a humble address is abstracted into its own abstract data type. Why? First, abstracting the idea of an address into its own type allows for consistency of addresses (as well as code reuse) for any component that needs an address. Second, is it not likely that we will have to accomodate different types of addresses? The one I've shown works for U.S. locations, but other areas organize their addresses differently. I can now subtype Address to reflect these different address types.

When we design around abstractions, we help ensure that the inevitable changes that will occur over the life of a program are localized to a few components - and that code that relies on the component's interface will continue to function. With the release of ColdFusion MX, ColdFusion's implementation underwent a drastic change, but the interface represented by its tags and functions remained the same - and the applications that were built to rely on that interface continued to run.

Thinking in terms of abstractions is not a natural process for most of us. Since it's code that makes the application work, we tend to think of ourselves as suppliers of code - coders. But defining ourselves in this way devalues our work and creates code that is fragile against the realities of business needs that continuously evolve. Abstraction layers provide a bulwark against the dangers of raging complexity.

When programmers (aka, "abstraction builders") struggle with object orientation, it's seldom the syntax of any particular OO language that trips them up. Rather, the difficulty usually lies in coming to terms with abstraction itself. But the benefits are well worth the work.