Take for example the lack of constructors and overloading. So many useful design patterns are dependent on these very basic OOP constructs.
Even if one allows CFMX leeway on this issue (I can understand that the learning curve can be steeper for newbees with all the OOP bells and whistles) and come back to the core of object-orientation, which is encapsulation, CFMX fails horribly to justify <cfinvoke>.
Encapsulation is at the core of OOP- an object is defined as having some properties and certain behaviors. The idea is to keep those two tightly combined in one logical unit. Instantiation is another core behavior - creating and using a particular instance of a class(object) makes perfect sense. After all a class is but a template.
With that in mind- <cfinvoke> is blasphemy in the name of Object Orientation!
<cfinvoke> encourages the design and usage of CFCs as a mere collection of (potentially unrelated) functions. Without instantiation, initialization of properties and proper use of instance methods, of what benefit is a CFC?
You could always use a UDF instead or even a custom tag.
I remember seeing Ben Forta's commments somewhere about this- that its ok for CF not to go the whole hog in being OO based since after all it is a rapid development scripting tool. I agree in principle but the half-hearted fence-straddling constructs somehow unsettle me very much. I must admit that I've worked with C++ and Java for years before I ever started with CF and that definitely colors my view of the issue.
I prefer a single, architecturally solid construct over multiple ways to do things that violate the very benefits that they are supposed to bring.
What do you think?
[Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
