OOP Terminology : Part II

July 09, 2008

I traditional write procedural code as I am used to letting the database define how the application is developed. In OOP objects define how the application is developed, not the database. This makes it much easier to cope with changes to the data structure (anyone ever had a client change how something should work?)

In my first post on OOP Terminology I wrote about Inheritance, Polymorphism and Encapsulation. This time, I'm looking at Abstraction.

If we are building an application which handles members of staff then we can represent them in a Employee.cfc.

<cfcomponent displayname="Employee">

  <!--- define what we know about the Employee --->
  <cfset variables.instance.name = "" />
  <cfset variables.instance.house = "" />
  <cfset variables.instance.street = "" />
  <cfset variables.instance.city = "" />
  <cfset variables.instance.county = "" />
  <cfset variables.instance.country = "" />
  
  ... get and set methods for instance variables ...
  
</cfcomponent>

OK, let's go back and look at what we've got again. Only one of those instance variables we defined is specific to the Employee - name. All of the others are dealing with the address. This is where abstraction comes into play. We can create a Address cfc to deal this information.

<cfcomponent displayname="Address">

  <!--- define what we know about the Address --->
  <cfset variables.instance.house = "" />
  <cfset variables.instance.street = "" />
  <cfset variables.instance.city = "" />
  <cfset variables.instance.county = "" />
  <cfset variables.instance.country = "" />
  
  ... get and set methods for instance variables ...
  
</cfcomponent>

Our Employee cfc can now be simplified.

<cfcomponent displayname="Employee">

  <!--- define what we know about the Employee --->
  <cfset variables.instance.name = "" />
  <cfset variables.instance.address = "" />
  
  <!--- get methods for instance variables --->
  <cffunction name="getName" 
    returntype="string"
    access="public"
    hint="I return the name">
    <cfreturn variables.instance.name />
  </cffunction>
  <cffunction name="getAddress" 
    returntype="Address"
    access="public"
    hint="I return the name">
    <cfreturn variables.instance.address />
  </cffunction>
  
  <!--- set methods for instance variables --->
  <cffunction name="setName" 
    returntype="void"
    access="public"
    hint="I set the name">
    <cfargument name="name" 
      type="string"
      required="true" />
    <cfset variables.instance.name = arguments.name />
  </cffunction>
  <cffunction name="setAddress" 
    returntype="void"
    access="public"
    hint="I set the address">
    <cfargument name="address" 
      type="Address"
      required="true" />
    <cfset variables.instance.address = arguments.address />
  </cffunction>
  
</cfcomponent>

Note that the getAddress method (function) and setAddress address argument both have a type of Address. This is because we are passing the Address object which is now a custom data type. This is a key difference between a procedural style of using components and the OOP approach.

If you tried to use the Employee.cfc it wouldn't work because we haven't told to Employee class what the Address object is. As I'm only dealing with terminology in these posts I'll save that for another day. If you what to know how, then have a look at ColdSpring and Lightwire. Both of these handle the problem for you with Direct Injection. I hope to do a post later about what Direct Injection is.

So why is this useful?

Now that we have the Address class (remember a class is our component), we can use it for any other objects that need an address. This promoted code reuse - so less typing, it also means that we can actually use the methods of the Address object in our Employee cfc.

3 comments

  1. @John,

    Good stuff.

    Comment by Ben Nadel – July 09, 2008
  2. @Ben, glad you liked the post. I was trying to write my terminology posts to keep up with your OOPhoto posts but you're just too prolific! :)

    Comment by John Whish – July 11, 2008
  3. @John,

    Hopefully I'll have a new one for you shortly ;)

    Comment by Ben Nadel – July 11, 2008

Leave a comment

If you found this post useful, interesting or just plain wrong, let me know - I like feedback :)

Please note: If you haven't commented before, then your comments will be moderated before they are displayed.