> 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.
Most OO languages allow the use of static classes, don't they? In those
cases, you're not interested in creating instances of objects, you simply
have an object that contains a bunch of useful, related methods.
As for why you'd use "static" CFCs instead of UDFs, I'd suggest the facts
that they generate documentation and can be used easily within Dreamweaver
MX as two reasons.
> I prefer a single, architecturally solid construct over
> multiple ways to do things that violate the very benefits
> that they are supposed to bring.
I prefer to use languages that let me do what I want to do, rather than ones
that tell me what I should do. Ease of use and flexibility are closely
related. Granted, I wouldn't mind at all if CFMX provided a CFCONSTRUCTOR
tag like BlueDragon does, but if I want to write OO code, I'll use an OO
language. If I want to be able to mix procedural and OO code to my liking,
I'll use CF.
Dave Watts, CTO, Fig Leaf Software
http://www.figleaf.com/
phone: 202-797-5496
fax: 202-797-5444
[Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
