This week we were LIVE on Ustream.TV!
To put it simply, our topic covered the basics of OOP for ColdFusion Developers, including the basic object oriented programming principles and the concepts of encapsulation, inheritance and polymorphism. The resources discussed today were Mark Mandel’s ColdDoc and the open source ColdFusion component libraries known as cfcommons.
Join us again next week!
Listen Now!
Direct Download!
Download It!
Loading ...
#1 by Zarko on April 16, 2010 - 8:23 am
Quote
I lol after Miki’s comment about polymorphism
#2 by Tony Garcia on April 16, 2010 - 9:51 am
Quote
Hey, great show guys. Didn’t have a chance to attend live, but good job on doing an overview on such a huge topic.
I have to say, though, that I don’t agree with the notion that you SHOULD use interfaces when doing OO development in CF. Of course, everyone has their own preferences and biases in the way they code, but in my opinion interfaces aren’t necessary in CF and they are more about trying to make CF more like Java. Java needs interfaces because it’s a statically-typed language. But ColdFusion is dynamically typed, so you can use “duck typing” (type=”any” or type=”component”). And in a lot of ways this gives you more power and flexibility than statically-typed languages. Other dynamically-typed OO languages like Ruby and Smalltalk don’t have interfaces either (and I’ve actually seen it written that “interfaces have no place in dynamically-typed languages”). I think it’s important to realize that “proper” OO can be different depending on the language on whether it’s dynamically or statically typed and as CF developers we should try to embrace dynamic typing as one of its strengths and not always look to the Java way of doing things. It’s interesting that Hal Helms was mentioned as the person who introduced Brian to OO programming because he is also of this school of thought. I think this blog post by Sean Corfield does a good job of expressing why interfaces can be considered superfluous in ColdFusion:
http://www.corfield.org/blog/post.cfm/Interfaces_in_ColdFusion
#3 by Brian Carr on April 16, 2010 - 10:31 am
Quote
@Tony, thanks for your comments – I’m very glad you like the show.
The subject of interfaces is a pretty touchy subject for CF’ers for some reason. To each his own I say. CF is definitely dynamic – one of it’s greatest strengths. I do however feel that strong-typing has it’s place in CF as well, which is likely where our opinions diverge. I do not believe that every argument / return type for every CFC method should be “any” – in fact I feel quite the opposite. I think both return types and method arguments should be strongly typed in almost every case. This way developers can realize the benefits of type-safety at compile time AND contract understandability which in my experience surfaces up problems much earlier in the development cycle – which I prefer. So having said that I’m sure you can see why I’m such a fan of interfaces – an important and very valuable CF capability – I stand by my original statements.
Hal Helms may have started me down the road to OO, but I’m o.k. with not agreeing with him on this point.
#4 by Micky Dionisio on April 16, 2010 - 10:37 am
Quote
@Tony-
Thanks for the feedback man! You gotta get on chat
I’m going to have to disagree with you. The very definition of using an interface is to establish a contract between your objects and to support a clear an concise expectation between objects.
I do not think that statically typed vs dynamically typed languages are a valid reason to say interfaces are useless. Interfaces are a consideration for your software architecture, not a language. CF supports interfaces even though it __is__ a dynamic language. This is because they know that interface based development is a key principle for good software design. I’ve developed OO apps in a multitude of ways and flavors, OO without interfaces, OO with lots of inheritance, OO with lots of abstract classes etc, and there is ALWAYS a reason to use interfaces. Given some apps require less of them but you will always want to, as much as possible, code to an interface.
Why? To offer extreme flexibility WHILE maintaining proper contracts, e.g. (ensure you’ve got the right types and returns).
I disagree with Helms and Corfield… It’s like saying, “hey you can make all your methods return a type of ‘any’ and thats soooo flexible!”. That’s nonsense, sorry…
#5 by Micky Dionisio on April 16, 2010 - 10:43 am
Quote
@tony-
One more thing, comments from Corfield/Camden/Helms/etc on what they think about interfaces ASIDE, I’d like to get a little bit more input on why you might think that interfaces aren’t necessary, especially for ColdFusion.
What’s your experience with it in CF (or other languages) that pushes you to the side to think that it’s not a good thing?
Thanks man
#6 by Mike Chandler on April 16, 2010 - 10:51 am
Quote
Being that I’m still a newcomer to the world of OO as it relates to ColdFusion, I’m definitely interested in hearing more about Tony’s position on using interfaces.
@Tony, would you be open to discussing this with us on the next show? I know Dan Vega has a similar position regarding interfaces but I believe he’s tied up at cfObjective next week.
It would be very helpful for me to hear everyone discuss their positions and hear the counterpoints openly, and I’m sure it would be useful for our listeners as well.
What are everyone’s thoughts on that?
#7 by micky on April 16, 2010 - 10:53 am
Quote
Great idea Mike! Tony let’s try to get you on a call yea?
#8 by Brian Carr on April 16, 2010 - 11:04 am
Quote
Of course I’m just happy to be here
An open discussion on the topic would be fun.
#9 by Tony Garcia on April 16, 2010 - 11:30 am
Quote
Like I said, everyone has their preferences and styles when it comes to coding. And in the CF world there are those who prefer strong typing and those who don’t. And we just happen to fall on the opposite sides of that fence. I just felt that it came across in the podcast that to do OO in ColdFusion you SHOULD use interfaces (even though you might not have intended it to come across that way), and I think it’s important for people to know that there are different ways for people to implement OO in ColdFusion and that it doesn’t make your code any “less OO” if you don’t use interfaces. (And as much as I respect you, Mickey, I don’t think it’s cool to dismiss people’s points of view as “nonsense”, be they Helms/Corfield, or Joe Blow Developer. We should all keep an open mind about stuff, as you yourself said in the last podcast).
My experience was coming from front-end HTML/JS development to back-end procedural CF development before I got into OO CF. I don’t have any experience with statically-typed OO languages, which is probably why I had such a hard time seeing the point of hard typing and interfaces in a dynamically-typed language. Whereas I can see why people with a Java or C# background coming to CF would prefer to use interfaces because they are used to that sort of thing. When I first started doing OO, I hard-typed everything, but then when I switched over to duck typing I found that it gave me a lot more freedom and it just fit a lot better to the way I do things and I experienced no drawbacks, really. I’m not saying everyone should do things my way, but it’s just one way of doing things.
A couple of other points:
Mikey, I am not against “coding to an interface”. I think that’s really important. But people should realize that “coding to an interface” is a principle of OO programming and doesn’t necessarily require the use of “interface” (the language construct).
Brian – you mentioned that strong typing gives the developer the benefit of type-safety at compile time. That’s true – in Java! In CF, there is no compile step, so any errors you run into are going to happen at runtime. Hard typing an argument in a CFC isn’t going to prevent you from accidentally passing in an object of the wrong type in your code and you won’t catch that until runtime. Just like if you duck type your argument and you accidentally pass in an object that doesn’t have the right method signatures, you’ll get a runtime error.
Also, my opinons about interfaces aren’t just because I’m blindly following Helms and Corfield. But once I found out that these CF “luminaries” (who also have a lot of experience on other dynamic and static OO languages) shared my views, I felt more confident that I wasn’t way off with what I was thinking.
#10 by Tony Garcia on April 16, 2010 - 11:39 am
Quote
Yikes! I missed the comments about me coming on the show as I typed my last comment.
Guys — I’m flattered that you want to have me on. But I’m no OO guru and I’m not really debating your position. There’s nothing wrong with using interfaces if that’s your preference. But I also think there’s nothing wrong with NOT using them.
Besides, I think I would feel outnumbered if I came on!
#11 by Brian Carr on April 16, 2010 - 11:50 am
Quote
@Tony – there most definitely is a “compile step” in CF, it’s just not something you do manually. Everytime you create a CFC or a .cfm file, CF compiles that into a collection of java classes (and each time you change a file). You will also most definitely see compile time errors if CFC’s implementing interfaces don’t adhere to the stated contract. All of which aids in the proper usage of system objects and improved understanding of object behaviors. Early problem detection is much improved under these scenarios. Early detection of runtime errors is the icing on the cake.
I’ll simply end by restating that interface-based development has many, many benefits and the hybrid nature of CF means that developers can leverage those benefits very easily. We are definitely going to have to agree to disagree on this point.
#12 by Mike Chandler on April 16, 2010 - 11:50 am
Quote
Tony, no debate is necessary. I’d just like to get a different point of view in front of the people who are listening, and in front of people like me who are still getting used to these concepts. I can assure you that it would be a respectful discussion. Give it some thought please. I think it would be hugely helpful considering we’re trying to attract open minded individuals into exploring these new concepts, and understanding all the different routes you can take.
#13 by Micky Dionisio on April 16, 2010 - 11:58 am
Quote
@tony-
I definitely keep an open mind about anything and everything that comes my way. I get my butt handed to me on a daily basis with new ways of thinking about and approaching software development
Regarding interfaces and their “usefulness” I have some very strong opinions of it rooted in a lot of experience. Apologies if I came off a bit strong, I don’t mean to, but you have to know thats where it’s coming from. It’s the whole reasoning of suggesting to return “any” or an extremely generic type like that web-inf component type because its “flexible” is not right.
And to your point about interface techniques you’re totally right. You have three main choices of how you want to code to an “interface”. Most of the time you want to choose an actual interface construct unless you need to inherit some state which means you can use an Abstract Class. The last resort should be inheritance, bleh.
Would love to have you on man, it would be good to openly debate this topic. Bring some friends!
Nonetheless, I stand by it and encourage every single CF developer out there to utilize interfaces period, regardless of language. It will make you a much better software engineer, I promise.
#14 by Tony Garcia on April 16, 2010 - 12:07 pm
Quote
@Brian — Yes, I know that CFMs and CFCs compile down to java classes. But you have to run the code to see the errors, nonetheless. You can’t catch errors before running the code like you can in Java. So to me, that might as well be runtime.
But you’re right, we just have different viewpoints on the matter. It was just important to me that people are aware of the other viewpoints.
@Mike — I’ll think about it. I might feel better about it if we could maybe wait a week and also get Dan or Sean C on with me.
@Micky — man, I just realized I misspelled your name TWICE in that last post! Sorry Micky!!!
#15 by Mike Chandler on April 16, 2010 - 12:09 pm
Quote
Tony, that’s a more than reasonable request! I’ll reach out to them. Thanks much!
#16 by Micky Dionisio on April 16, 2010 - 12:18 pm
Quote
@tony – np man, believe me im used to it!
#17 by Brian O. on April 17, 2010 - 5:17 pm
Quote
I enjoyed the podcast. Besides using the extends attribute in cfcomponent in my Application.cfcs, we have not really used OOP. Our environment consists of multiple apps as part of a web portal Intranet maintained by 3 developers, still using CF8. I see the value of OOP, especially in CF9, but the lead developer is concerned about any loss in performance even with gains in maintainability. Our server environment may be allowed to move to CF9 later this year. It would be good to discuss in a future show about how to transitionally refactor existing procedural code to OOP. I have the freedom to make incremental changes if performance is not affected significantly. We use CFCs extensively, but mainly for CRUD and as a container for functions. Our CFMs for the most part either invoke CFCs directly or via an intermediate CFM. At this time we are mainly making system improvements, but new systems occasionally pop up and are given to me. So I may have the opportunity to start a new effort using OOP at some point, but I’d prefer to test it with an existing system as a proof of concept like I have done with AJAX. All our systems have a basic need for CRUD operations and reporting needs. We are not using Flex or Flash at this time. The kinds of apps we have are 2 basic types.
1) Document repositories with meta data for which users with varying permission levels need to perform CRUD operations including searches and display of PDFs, spreadsheets and Word Docs. We use gateways and the latest CF8 AJAX and customized Ext capabilities.
2) Multiple systems that involve things like procurements, configuration management, action item tracking, issue tracking, etc. and their meta data which are manipulated again via CRUD operations including searches.
Also I’d be interested in any references you’d recommend that might help me in taking my next step. Real examples would also be great.
#18 by Chung on April 21, 2010 - 11:15 am
Quote
Hey Guys! Great podcast yet again! Sorry about getting to it just now.
OOP gets a bit easier after you do it but still a ton of things to learn. I still don’t think I’m doing it right but there’s just so much conflicting information out there about what it what and what should be OOP in CF that I just said “screw it” and choose the parts I like and smashed em together.
#19 by Mike Chandler on April 21, 2010 - 11:35 am
Quote
Hey Chung!
I completely understand what it’s like to reach the frustration point and mash together an approach that simplifies your development but doesn’t necessarily adhere to standards. My advice would be to try to keep fighting the fight and avoid that.
Let’s chat offline and see if we can apply some of this stuff to GK. I think you’re close, you just need to have that “breakthrough” moment and you’re almost there.