There was a series of interesting threads on CFCDev today about
different types of objects, and how they play together to form a
complete OO system. Couple that with a pretty active week in the
CF blogosphere regarding objects, and I think it's pretty safe to say
that CF development is growing up. Definitely no longer just the
quick-fix dev tool for little apps, CF developers are starting to think
about pretty hard core development techniques, and with enough numbers
to warrant widespread discussion. That's really cool in my view,
and should bode well for the community as a whole.
I want to
sum up a few things with quick definitions/discussions as kind of a one
stop shop, rather than having to look all over, so here goes:
Objects
- A collection of state (instance data) and behaviour (methods).
A struct has state. A UDF has behaviour. An object has
both. The state should be inaccessible to the outside world; it
can only be retrieved and manipulated via methods of the object.
Some objects are very thin, with almost no behaviour, some objects are
very thick.
Business Objects (BOs) / Beans – These are
the heart of any object model. They represent the entities within
the model, and hold not only the entity state, but also entity
behaviour.
Transfer Objects (TOs) – These are
snapshots of the state of a BO, without any of the business
logic. Their purpose is twofold: 1) to make passing the data
around easier (one object, versus a bunch of individual fields), and 2)
maintain the integrity of the BO's state, without requiring the BO
itself (the TO's state is immutable, and only accessible via
getters). This should be a CFC with getters for each property of
the BO, but you can use simple "read-only" structs with similar effect.
Data Access Objects (DAOs)
- These objects provide a way for a business object's state to be
stored and retrieved from some "persistant store". Usually this
means a database, but it might be a collection of XML files, or any
number of other things. The idea is to isolate the BO from the
method in which it is stored, so you can transparently switch out
persistance mechanisms without affecting it.
Data Gateways
- These provide a related function to DAOs, but they aren't for a
specific BO (or entity), but rather for collections of entities.
So where you might have a User BO and a corresponding DAO for it's
persistance operations, you'd have a gateway object for getting lists
of users, or other such multi-entity operations.
is-a, has-a
- These are the two core types of relationships between objects.
Is-a relationships are inheritance, where you say "a Corvette is a Car
is a Vehicle". Has-a relationhips are composition, where you say
"a User has a Role which has some Responsibilities". Wherever
there is ambiguity between which type of relationship to use, the
natural instinct is usually to go with is-a, but the proper solution is
usually to go with has-a. ; )
Object Modelling
-
The process by which you define and create the set of objects needed
implement a given set of business logic. This is a VERY
complicated process, and is damn near impossible to get right on the
first try (or the third, or the tenth …). It usually starts by
identifying the entities in the model, and then identifying the
relationships, and then identifying the types of objects needed to
represent them. Once that's done, you go back and revise them,
checking for cohesion, loose coupling, appropriate use of patters, and
all kinds of stuff. Then you revise again. And
again. Simple on paper, difficult in actuality; very
much an iterative process, no matter your level of expertise.
If you're interested in using OO with CFML, I'd highly recommend the CFCDev list.
It's not particularly high-traffic (much, much less than CF-Talk), and usually
stays remarkably on-topic. You might also check out An Architects View (Sean Corfield's blog), ClearSoftware.net (Joe Rinehart's blog), and Matt Woodward's blog. Finally, I'd also recommend the ColdFusion news feed on FullAsAGoog.com, which includes all of these blogs (along with mine), plus with many others to numerous to mention here.
Comments are closed.