A while ago, I posted an example of creating CFC definitions on the fly using a function I wrote called StructToBean().
It essentially used the concepts of Prototype Based programming to implement the getter and setter methods on a blank CFC, so that the data of the Struct was encapsulated in an object without having to actually write the object itself.
I put that post on here while I was writing a library that was an attempt to cut down on the amount of time I spent writing simple Beans for use as Business Objects.
The basics of the library was such that I had a XML config file that defined each of the Beans that I wanted to be able to use in the system, like so (cut down version):
<property name="number" type="numeric" />
<property name="name" type="string" />
The library would then create a .cfm file on the fly, which would contain all the UDFs required to add the required getters and setters to the blank CFC.
When the specified Bean was called for, the library would create a blank CFC, and insert each of the methods onto the blank CFC at runtime, so it was ready to use.
As personal projects tend to do, this idea fell by the wayside for a while, and now I've been rebuilding compoundtheory, it's come back to me, and I've started to question whether or not it's really something I want to get behind in terms of how I build my CF applications. I'm still pretty much sitting on the fence as to whether or not I'm actually going to rewrite the code (it needs a good refactor), and utilise it in the new version of CT.
While CFCs aren't exactly prototype based, the basic flexibility of being able to utilise slots in the CFC to add and remove methods remains the same, but the question that I am wondering at the moment, is should it be used.
On one side there are alot of interesting things you can do with method injection and removal:
- Adding Object functionality on the fly
- Create Interfaces on the fly
- Faking Base class functionality
- Changing protection on methods due on the fly (i.e. remove a init() constructor once it has been called once)
- Fix bugs on the fly
But obviously there are cons as well:
- Adds a whole level of complexity to an application that is harder to document
- Breaks some core OO concepts (which may not be a bad thing, but you have to be happy about it)
- Can lead to some awefully spagettied code if not managed correctly
Now, obviously, whether or not you leverage this capability is very dependent on applicaiton requirements, your own personal views on OO Analysis and Design etc, but the usage of this functionality does exist, yet seems to be a topic that is not talked about much in the CF community.
So I ask you guys, as an information gathering excercise:
- Have you considered taking a Prototype based approach before?
- If you had, did you do it?
- If you did, what was it, and why did you do it? (I would love to hear of some places it was used!)
- If you didn't, why not?
- Would/wouldn't you consider using this approach for something in the future?
That being said, in the next few weeks (as I continue to develop the next version of CT), I'll do a follow up post on whether or not I decided to utilise the prototype based approach to developing the Business Objects for this site, and why I decided to do it, and hopefully this will get some interesting discussion going!