danvega.org: OOP state of mind In the land of CFML

OOP state of mind In the land of CFML

Thursday October 16, 2008 4:10 PM

Word Count: 210

A little background on me before I get into which may turn out to be a heated discussion but that's how we learn. I started out doing basic html web sites like most of you. I then found myself in a 2 year technical college learning a variety of languages such as Basic,C,C++ & Java. Now I truly never became skilled in all languages it prepared me for the future. I then started programming using ColdFusion and even to this day people say that does not classify me as a "real" programmer. I would of course disagree with you and say that language aside the very ideas of programming can be used across every language out there.

Now that we got that out of the way we can talk a little about Object Oriented Programming. I started picking up Action Script 3 about a year ago and absolutely love the language. While I am a ColdFusion addict (cfaddict) I am really loving the full OO structure of AS3. ColdFusion 8 is not a full OO language but it clearly exceeds it predecessors in giving you more ways to think OO.

Thinking in Object Oriented terms is really what I want to embed in your mind. When people hear the term OO they start thinking of all these complex design patterns and in the ColdFusion world developers start thinking of Beans,DAOs and Gateways. I am here to tell you that I am by no means an expert on the subject but I have learned a lot on the subject over the last year or so. There are some great minds in the community that really know what they are talking about and I encourage you to listen to what they have to offer. Here is a short but not complete list of blogger's that I believe you should be following. EDIT (There are many people you should be following not on this list, this is just a few off the top of my head who talk a lot about OO in CFML.)

So back to the discussion at hand, I know this may shock some people or even confuse others but here goes. Object Oriented Programming does not mean you have to use a design pattern. There, I said it and feel glad I got that out. Design patterns have become very popular because very smart people found solutions to complex problem. Am I saying you don't need them, of course not. They exist and continue to live on for a reason, they work! I just want to drill the idea that if you here a ColdFusion developer say he is an top notch OO programmer just because he knows how to write a DAO or Value Object that he is not exactly correct.

Ok, your with me so far and now your asking yourself well what exactly is OO. Hal Helms who is not only a brilliant person he also happens to be one of my favorite speakers. Hal stresses the point that you need to stop thinking about databases when we think about Object Oriented Programming. This is the first thing we need to do when coming up with a model.

Object-oriented programming (OOP) is a programming paradigm that uses "objects" and their interactions to design applications and computer programs. This very line is where OOP starts and backed up by a number of fundamental concepts. These concepts are all things we have heard before such as Inheritance, Objects, Classes, Abstraction, Polymorphism, Encapsulation, Decoupling, methods and properties. You will notice that no where in that statement is the word database. Before we can even begin to cross the train tracks to the other side we really need to start pounding that issue into our heads.t

I hope to start posting a lot more on this subject in the near future. I know you probably did not learn anything from this article but I just wanted to vent for a second and also post this a forum for others to chime in. Please remember I claim to be a programmer in a cubicle and nothing more. I learn just the way you do and listen closely (but think on my own) to what the smart people above preach!

1032 Views

Comments

#1 Posted By: Glyn Jackson Posted On: 10/16/08 4:57 PM

I think i was listening to Hal on a cfconversations podcast he challenged us to think about how we design, I do built my applications around the database (everyone I known in this industry does) however it got my attention!

#2 Posted By: Dan Vega Posted On: 10/16/08 5:12 PM |

Author Comment

That is what really helped me out as well. It really is hard to do though because all of our Information comes from the database. You really have to take the persistence level out of it so you can concentrate on the what before the how!

#3 Posted By: Dan Roberts Posted On: 10/16/08 6:20 PM

"ColdFusion 8 is not a full OO language but it clearly exceeds it predecessors in giving you more ways to think OO."

Please elaborate. Does your opinion on this matter swing on the inefficiency of object creation in CF -- or something else? Thanks

#4 Posted By: Dan Roberts Posted On: 10/16/08 6:21 PM

#5 Posted By: Dan Roberts Posted On: 10/16/08 6:22 PM

fyi... an error message appears after submitting comments, which is why I submitted my comment a second time

#6 Posted By: ike Posted On: 10/16/08 9:01 PM

Honestly the claim that CF is not a "blue blooded" OO language makes my skin crawl! The vast majority of people who make that claim are making it because the nature and syntax of CF's type system and/or performance metrics don't map in a symetrically perfect way to Java. Java has never and will never define what OO is, that's a far too narrow and restrictive definition. Java is a NEWCOMER to the world of OO and does things differently than SmallTalk which came a full TWENTY YEARS before it.

http://en.wikipedia.org/wiki/Timeline_of_programmi...

If you compare the syntax of all three languages, you'll find that CF more closely resembles SmallTalk than it does Java.

Specifically, OO does *not* mean explicit types or method overloading (some of the things I've heard frequently as arguments for not being "true" OO), since SmallTalk's type system and related syntax are similar to CF and therefore have no need of explicit type declarations. Nor does it mean being efficient enough to do things in horribly INefficient ways like instantiating 100+ objects to display an HTML table with a list of 20 names and numbers (as is sometimes advocated in the Java world).

Granted, you didn't explain your basis for making the statement, I'm just attacking the arguments I see people make most often. :)

And lastly beyond my rant ;) abstraction, encapsulation and decoupling are not OO concepts. All three of those things are often done with procedural languages. I used to do them quite frequently with CF before the release of CFMX.

#7 Posted By: Dan Vega Posted On: 10/16/08 9:09 PM |

Author Comment

I can certainly say that I am only speaking from my experience. I have only been programming for about 6 years now I now nothing about oo concepts before I started with Java. One thing I can speak to though is your last statement. It is true that individually these concepts can be used in the wild. I think when you are mindfully thinking of ways to model your objects though and taking all of them into consideration you can walk the OO road. Love the comments / rants (your words :) ) so keep them coming.

Please remember I am just a guy in a cube but I have a very open mind and my knowledge to learn is why I am here!

#8 Posted By: Jason Fisher Posted On: 10/16/08 9:23 PM

Great post, Dan. Guess my earlier comments never made it into the system :( so I'll try to re-construct.

You note that an OO app should be made of objects which interact. One of the things that Hal always focused on when writing about OO was that an object has *behavior*. So, yes, an object has properties, but I think that an overly strong emphasis on an object's properties can often reflect an underlying table's columns. When we instead model object interaction as behaviors, however, then we can make a design without thought to the database. An object's properties are only there to support the communication among behaviors.

Once the app is modelled, then the persistence layer can be designed, and we may decide that multiple tables are needed to persist the properties of a single object or that multiple objects persist properties in a single table, or maybe we don't use tables for persistence at all (XML, flat file, whatever). In short, object modelling is a separate task to data modelling: one for the app, the other for persistence.

#9 Posted By: Dan Vega Posted On: 10/16/08 9:26 PM |

Author Comment

@Jason,
I am sorry about the problems with the comments. They should all be taken care of now. Great comments though, I find it really hard not to think of a database but you have to force yourself that the persistence of data should have nothing to do with the initial architecture of the system

#10 Posted By: Jason Fisher Posted On: 10/16/08 9:33 PM

@Dan,

No problem on the comments ... I pretty much captured what I was trying to say ;)

As for the DB view, I completely agree. I started my IT work years ago in DBs (dBase III, dBase IV, FoxPro, Access) and then finally got into code and CF, so I *still* immediately think in data-storage terms. Trying to step 'out' of that to architect a solution in true object terms Without Thinking Data is utterly foreign. I think I completely understand it in a theoretical sense, but I don't always succeed at applying that knowledge to overcome my own tendency to jump straight to SQL Server!qo

#11 Posted By: Sean Corfield Posted On: 10/16/08 10:55 PM

@Dan V - please explain your claim that CFML is not a full OO language. I see this claim made from time to time and no one making the claim ever seems to be able to back it up so I like to challenge it every time I see it.

As Ike says, CFML is a lot more like Smalltalk than Java - and a lot more like Ruby or Groovy - and is every bit as OO as those languages. In fact, as I point out in my Design Patterns talk, CFML can do things that Java cannot - things that Smalltalk, Ruby and Groovy can all do - and so you can reasonably claim that CFML is *more* OO than Java.

#12 Posted By: Sean Corfield Posted On: 10/16/08 10:56 PM

Oh, and one more point... The Broadchoice Workspace application was designed first and foremost as a series of collaborating objects. We chose Hibernate as our persistence engine and allowed it to generate the database from our object model. In other words, we completely ignored the database when we designed the application. It was very freeing and allowed us to build a better model, IMO.

#13 Posted By: ike Posted On: 10/16/08 11:08 PM

Just a subject that gets my dander up. ;) Because comments about CF not being OO usually amount to ad hominem.

#14 Posted By: Dan Vega Posted On: 10/16/08 11:35 PM |

Author Comment

@Sean - I think the main issue comes in to play with the lack of Abstract classes. I have always had people burn the point into my head that I should "Always program to an interface not an implementation". As you know Interfaces in CFML provide a runtime contract not a compile time one. It is because of this I always feel weird using them :)

#15 Posted By: ike Posted On: 10/16/08 11:58 PM

The idea of abstract classes falls for me into the area of "overthinking". And by that I don't mean that having an abstract class is a bad idea, because I've created a number of them myself. What I mean is that insisting that in order to be "truly OO" a language needs to have a built-in way of *gauranteeing* that a particular class will never be instantiated (or used without being instantiated) is overthinking the idea of the abstract class.

The abstract class itself is nothing more than another class. The only difference is that in languages that have a built-in semantic like Java, you can guarantee that it won't be instantiated. Okay. Fine. But honestly, so what? I can't imagine why that would matter, because I can throw an error in my init() method and produce basically the same effect.

From a coding standpoint I can't see any reason why the built-in semantic would be any better than the other. That's from a coding standpoint. From an architectural standpoint you could argue for the idea that the introspection of metadata in Java allows you to determine programatically if a particular class is abstract without instantiating it, allowing conditional logic based on that information. That is a functional difference.

But again I say, who cares? The cases in which you might actually need something like that are such extreme edge cases as to be virtually inconsequential. I've been doing this for 10 years and not run into a single case in which I said to myslef "if only there were a built-in semantic for abstract classes in ColdFusion! That would make life so much easier". And I don't see that happening any time soon either.

#16 Posted By: Dan Vega Posted On: 10/17/08 12:00 AM |

Author Comment

@Sean - Something else I wish had the ability to do is method overloading. I think that when you are creating components it would be great to have a no arg constructor and one where I could setup the employee.

Empolyee()
Employee(first,last)

#17 Posted By: John Whish Posted On: 10/17/08 4:43 AM

@Joe, nice post. Spotted a slight typo; Joe Reinhart should be Joe Rinehart.

#18 Posted By: John Whish Posted On: 10/17/08 5:21 AM

@Joe, I don't want to speak for Sean, and I might be misunderstanding but you can have a no argument constructor.
In your cfc...
<cffunction name="init" hint="I am a no arg constructor">
<cfset var key = "" />
<cfset variables.instance = {} />

<cfloop list="#StructKeyList( arguments )#" index="key">
<cfset variables.instance[key] = arguments[key] />
</cfloop>

<cfreturn this />
</cffunction>
In your calling code do this to pass arguments:
<cfset argsColl = { id = CreateUUID(), datetime = Now() } />
<cfset foo = CreateObject( "component", "com.noargconstructor" ).init( argumentCollection = argsColl ) />
or this to pass no arguments:
<cfset foo = CreateObject( "component", "com.noargconstructor" ).init() />

#19 Posted By: John Whish Posted On: 10/17/08 5:22 AM

Arg, you do allow tags! Trying again... :)

<cffunction name="init" hint="I am a no arg constructor">
<cfset var key = "" />
<cfset variables.instance = {} />

<cfloop list="#StructKeyList( arguments )#" index="key">
<cfset variables.instance[key] = arguments[key] />
</cfloop>

<cfreturn this />
</cffunction>

In your calling code do this to pass arguments:
<cfset argsColl = { id = CreateUUID(), datetime = Now() } />
<cfset foo = CreateObject( "component", "com.noargconstructor" ).init( argumentCollection = argsColl ) />

or this to pass no arguments:
<cfset foo = CreateObject( "component", "com.noargconstructor" ).init() />

#20 Posted By: Sean Corfield Posted On: 10/24/08 11:53 PM

Yeah, I was going to point out what John pointed out.

In general, in a dynamic language, method overloading can be very expensive because you have to figure out at the point of call - at runtime - what all the possible matching signatures are and which is the "best" signature. And that all depends on "types" but CFML is very weakly typed so "123" is both a string and a number. At that point, overloading completely breaks down.

You do have optional arguments of course and that's usually what is really needed. Or you can go with duck typing and explicitly manage the different behaviors yourself.

For example, I just ran into a situation (in Groovy) where I wanted both:

void joinGroup(User,Account)

and

void joinGroup(List,Account)

(for multiple users). The equivalent CFML would have a single method with type="any" on the first argument and it would check if isArray() on the first arg and treat it as an array else treat it as a single user. You're still doing runtime checking but now you're in complete control.

Thinking about abstract classes and overloading makes me think you're focused on Java and you're trying to write Java in CFML which is very limiting. CFML is a great dynamic OO language but you need to draw on the experience of other dynamic OO languages such as Smalltalk and Ruby - not Java.

#21 Posted By: Aaron C Posted On: 10/27/08 12:47 PM

So is ColdFusion 8 Object Oriented? Yes. Well I wouldn't say it IS an OOP language. I would say you can write you application in an OOP technique. I believe that CF is on it's way but, not quite there yet.

I will feel more comfortable calling CF OOP once it's not as tag based. Once i can create and extend some of the built in tags. When i don't have to put <cfform> on my page i could simply write a component that can create an instance of the cfform and append other objects and then call a construtor method on the CFform Object to display it on the page. Cough cough ".NET"

I hope i don't get called a MS fanboy!

Yes, you can create complex objects, extend, access query objects etc.. So you can write an app that is fully OOP.

OOP state of mind In the land of CFML

Comments

Post Your Comment

Navigation

Favorites

Tagcloud

Archives

Blogs I Read

Recent Entries

Recent Comments

About

Stay Upated