still relatively new to OO but moving over to the Mach-II framework has
helped me get a better understanding for it. I personally use
createObject(), I haven't seen a need to use <cfinvoke>.
I have a feeling that with Blackstone you will see true Constructors
make their way into CF since a lot of people have this same gripe.
As far as it moving to a full fledged OO based language, I'm not sure CF
will ever move to that. It will probably stop a lot of CF developers
from upgrading if they have to learn OO programming. I think that is the
reason a lot of people went with CF, so they can do complex things
easily.
Ben
-----Original Message-----
From: Nikhil Madani [mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 31, 2004 10:57 AM
To: CF-Talk
Subject: CFINVOKE vs CreateObject - Flogging OOP!
I have a deep sense of loathing for the use of CFC's with cfinvoke given
that Macromedia meant the latest CF release to be an "object-oriented"
version. I'm aware that they do not claim it to be a completely OO based
language like Java for example, but to me the valuable patterns that OO
theorists developed over the years to help model real-world scenarios
are lost without some of the constructs.
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]
