OOP Terminology : Part VII - Beans

When people talk about beans in OOP what the heck are they on about? Well, the term bean comes from the Java world where there are different types of beans. It is called a "bean" just because it fits in with the coffee themed naming convention (Java is a type of coffee).

In ColdFusion, when people talk about beans it simply means an object that holds data, has a constructor (to create an instance of your class) and has accessors (getters and setters) to get and manipulate the data. Here's an example of what an book bean might look like in ColdFusion terms:

<cfcomponent hint="I represent a book">

  <cffunction name="init" hint="I am the constructor">
    <cfargument name="title" required="true" />
    <cfargument name="author" required="true" />
    <cfargument name="isbn" required="true" />
    
    <cfscript>
    variables.instance = StructNew();
    
    setTitle( arguments.title);
    setAuthor( arguments.author );
    setISBN( arguments.isbn );
    </cfscript>
    
    <cfreturn this />
    
  </cffunction>
  
  <!--- set accessors (aka mutators) --->
  <cffunction name="setTitle"
    access="public"
    returntype="void">
    <cfargument name="title" required="true" />
    <cfset variables.instance.title = arguments.title />
  </cffunction>
  <cffunction name="setAuthor"
    access="public"
    returntype="void">
    <cfargument name="city" required="true" />
    <cfset variables.instance.author = arguments.author />
  </cffunction>
  <cffunction name="setISBN"
    access="public"
    returntype="void">
    <cfargument name="isbn" required="true" />
    <cfset variables.instance.isbn = arguments.isbn />
  </cffunction>

  <!--- get accessors (aka mutators) --->
  <cffunction name="getTitle"
    access="public"
    returntype="string">
    <cfreturn variables.instance.title />
  </cffunction>
  <cffunction name="getAuthor"
    access="public"
    returntype="string">
    <cfreturn variables.instance.author />
  </cffunction>
  <cffunction name="getISBN"
    access="public"
    returntype="string">
    <cfreturn variables.instance.isbn />
  </cffunction>

</cfcomponent>

A word of caution!

Whilst the above example is a bean, you are getting none of the benefits of OO (but doing all the work), because this is just a glorified data holder. We could write this much easier using a ColdFusion struct. One of the common traps that people fall into when moving from procedural to OO code (myself included) is to think that this is OO. In fact you are creating an anti-pattern, often called an Anemic Domain Model.

How to avoid an Anemic Domain Model

Think of what your objects would be able to do in idealised world instead of the real-world. For example wouldn't it be great if my book could; tell me when it was last read, check that any new values are valid, save it's self in a persistant state, tell me which people have read it.... I'm not saying that all these behavours should be in your objects, just that they could be in your object!

• Posted in:
• ColdFusion
• OOP

10 comments

1. You will also hear a Bean refereed to as a Value Object or VO for short.
   
   Comment by Dan Vega – October 16, 2008
2. @Dan, thanks for the comment. You're right that sometimes Value Objects are referred to as beans. Just to confuse matters Data Transfer Objects (DTO) are sometimes called Value Objects (VO)!
   
   For anyone else reading VO/DTO's are objects that don't do anything but store data which can be read and written to using accessors. These are a good example of an anaemic object.
   
   Comment by John Whish – October 16, 2008
3. I sort of interchange Bean and "Business Object". Is that incorrect?
   
   Comment by Ben Nadel – October 16, 2008
4. Hi Ben, a BO has a constructor and accessors so IMHO it's a bean :)
   
   Comment by John Whish – October 16, 2008
5. In addition, I prefer to say Business Object instead of bean, as to me, a BO is a more specialised version of a bean. As Dan pointed out, a Value Object is also called a bean and that is just a dumb object which a BO isn't.
   
   Comment by John Whish – October 16, 2008
6. Ok cool.
   
   Comment by Ben Nadel – October 16, 2008
7. Yarr, you bring up an interesting point about anemic objects. However, I disagree about objects persisting themselves in an ideal world. While we do not want anemic objects, we also do not want bloated objects that do too much.
   
   The most confusing part of switching to an object oriented mindset in CF is object persistence. How/Why/When should objects be stored? These are the current questions I am trying to address and would like any feedback.
   
   Comment by Bradley Moore – October 16, 2008
8. @Bradley, I was just trying to point out that we should think of what we'd ideally like an object to be able to do rather than what it actually does in the real world.
   
   I didn't mean that the object itself should necessarily have the SQL/code in it to persist itself, but that it makes sense that the object knows how to persist itself by calling a separate DAO/Gateway/insert_your_DAL_here object. So the service layer just calls:
   
   myObject = CreateObject('my.cfc.);
   ... do some stuff ...
   myObject.Save()
   
   not
   
   Book = CreateObject( cfc.path.book );
   ... do some stuff ...
   
   BookDAO = CreateObject( cfc.path.bookDAO );
   BookDAO.Save( Book );
   
   I don't really want my service to know that to store my Book object it needs to know that it needs to use a BookDAO. I just want it to know that the Book can be saved.
   
   Of course I might be talking rubbish - it's just what makes sense to me :)
   
   Comment by John Whish – October 16, 2008
9. Ah, I get what you mean and it makes sense to me.
   
   Comment by Bradley Moore – October 16, 2008
10. @Bradley, glad I made sense (quite unusual for me!) I've amended the last paragraph to hopefully make my meaning clearer.
    
    Comment by John Whish – October 17, 2008