What is an Object as a Struct?
Let's say you have an object and you'd like to turn it into a struct. What does that really mean, and what should the code do?
Rebuilding my Base Object
As you might have guessed from my last few postings, I'm doing a ground up "clean up" of all of my LightBase code. The starting point is to give my base object a quick going over . . .
Storing Instance Data in Beans vs. IBOs
As part of my generic getters and setters I like to put my instance data for all of my beans into a struct so there is no chance that instance data and methods will overwrite each other (which might otherwise be a possibility if both ever had the same names). But when I start to play with IBO's, I have two types of data to store - instance/object data and class data . . .
What do you put in your Base Object?
Creating a base object that all of your CFC's extend is a powerful technique, but one you've got to think carefully about . . .
Generic Getters
When developing Object Oriented code, it's important to encapsulate the variables contained within an object. That way, you can vary the internal implementation of an object without having to find and change all of the methods that call the object – providing you don't change the structure or the behavior of the methods for that object.
Adding State to your Business Model
In a recent posting, I looked at how it could be useful to model some of your business objects as state machines. In this posting I wanted to do a thought experiment about how you could build the concept of state right into a business object so you would be able to declaratively describe states and then the object would be smart enough to provide the appropriate attributes, validations and methods automatically, throwing an error should you try to access/modify information or undertake an action which was not valid in the object's current state . . .
Modeling Business Objects as State Machines
Often business objects in even fairly simple systems go through a number of states within their lifecycle. For instance, you can't ship an order that has not yet been placed and a user that hasn't logged in can't view their account. This post looks at how thinking about state when designing your objects can help you to write more maintainable applications.
E-commerce – Orders and Addresses
The thing I love about building even very simple e-commerce applications is that they can bring up sufficiently complex classes of design problems to make them a great testing bed for new ways of implementing web applications. Today I want to look a little at the old “orders and addresses” problem to see if it can provide any more generalized insights into Object Relational Mapping . . .
One Service Class Per Business Object - Not as Bad as You Think . . .
For a while I've noticed that a number of people who I respect in the ColdFusion world recommend that you not reflexively have one service class per business object. I want to suggest that actually it's a pretty useful default approach - especially if you want to develop consistent, maintainable applications - quickly and cost effectively. As always, looking forwards to feedback . . .
