I agree with you for the most part. I think the addition of CFCs
to CF is a big step forward, but the partial implementation of
OOP is frustrating (the lack of overloading and interfaces are my pet peeves).
However, I think it's okay that CF is not full OOP. The solution
for me is to use a mix of CF and Java, each doing what it does
best. To me, CF runs circles around JSPs and tags for
presentation, while Java is superior for modeling business
objects and processes.
So, I use a MVC architecture, with CF handling the VC and Java
the M. Mach-II appears to provide a nice framework for cleanly
separating the responsibilities between CF and Java. I'm doing
this on a current client project and so far have been pleased.
Dave Jones
NetEffect
At 11:56 AM 3/31/04 -0400, you wrote:
>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]
