What are the differences between OOP in Java vs OOP in ColdFusion?
The short answer to my subject's title is there are no differences between OOP in Java and OOP in ColdFusion. For a longer answer, and some background, we need to step back 12 short hours ago...
I saw a tweet roll by my twitter stream today right before I was leaving for the Hartford User Group meeting. I remember the tweet saying something about there needing to be a difference between Java-OOP and CF-OOP. I suspect this is the tweet, although I remember it slightly differently in my head:
CF-OOP ( "Not your JAVA's OOP" ) ... and that is good!
I translated that tweet to mean that there should be different versions of Object Oriented programming based on the language you are using.
For some reason, perhaps my imagination, it seems to me that every time SoSensible and I have twitter words they are slightly combative. I'm not sure if this is intentional or if we just like to disagree in 140 characters. I, perhaps foolishly responded like this.
@sosensible OOP is one approach to software architecture. It is language agnostic. If Java-OOP & CF-OOP are different, you're doing it wrong
The reason my response may have been foolish is that it is not sensible [no pun intended] to start religious wars and then run away. In my version of the world, my tweet makes perfect sense.
Object Oriented Programming is just one a way of approaching a problem we are trying to solve. Object Oriented Programming tries to mimic entities in the real world (Objects) and define their actions (methods) and interactions. An object oriented architecture should be completely language, or platform, independent because the way that real world entities interact with each other is completely independent of a specific computer language or platform.
Procedural programming on the other hand focuses on how the computer will compute tasks. The whole purposes is to break things up so that the computer will process the tasks and solve your problem in the most efficient way possible.
As a side note, computers are fast enough these days that I'd expect performance issues between an Object Oriented Designs and Procedural Designs to be negligible.
The difference between Object Oriented Programming and Procedural Programming is all about how you model your entities and how those entities interact with each other. In OOP you create objects, which represent real world entities and you focus on the actions (methods) that those real world entities perform. In Procedural Programming, you create Abstract Data Types, which is like your own data type and the functionality that operates on that data.
Feel free to take a moment to think about your own development. Are you focusing on mimicking the real world, or are you focused on modeling your data?
For all intents and purpose, Objects and Abstract Data Types are the same. The type of objects you decide to implement and the way that they interact together is what makes a design lean more towards OO or Procedural.
When I was in college, I seem to remember a lot of examples regarding flower shops, so let's assume you live in Connecticut and want to send flowers to a friend in Virginia.
In an OO Style Approach:
You call a CT flower shop and place your order. That CT flower shop processes the order by finding a Virginia Flower Shop and passes it the order. The Virginia Flower Shop processes the order by putting the flowers together and delivering them to your Virginia friend.
So, two different flower shops are handling order processing completely differently based on the flower destination.
In a Procedural Style Approach, this may happen:
You create the order and send it to Flower Shop Flower Shop, process the order by putting the flowers together and delivering them.
So, in this situation, you are creating the order; not passing the data to the Flower Shop. And the Flower shop just knows how to handle it.
Both approaches can use a relational database in the backend to store data; and he "processing" done at the database level will probably consist of modifying the stock count.
Before ColdFusion 6--AKA CFMX--ColdFusion did not provide a facility to create either Objects or Abstract Data Types. A lot of folks claim that development in CF5 or below was in the procedural style. In most cases, it wasn't. It used a top down approach with minimal thought to encapsulation. Yes it had custom tags and includes and eventually functions, but neither were used consistently. And there was no way to encapsulate data. This was a serious problem for anyone who wanted to implement procedural (or Object Oriented) architecture in their code. It just wasn't feasible.
I got two responses to my tweet. One from John
OOP means programing with objects. Are you saying that I should require strong typed CFC arguments or I am doing it wrong?
I don't fully understand John's rebuttal, probably because he didn't fully understand my original statement. I was speaking about design principles, and I believe he responded with implementation specifics. OOP means that you model the real world. That has nothing to do with strong or loose typing.
The best response I can give to John is that If you think you're Object architecture should be different based on the language you are using, then you aren't properly modeling your real world entities and how they interact with each other. Those objects and the interactions do not change with your language.
The other response I Got came from kylerow. Gotta love Twitter, I have no idea who Kyle Row is; I wasn't even following him before now. Maybe he is following me.
language devices make a difference how you do OOP - ex: C++'s multi-inheritance vs. C#/Java single-inheritance ..
Once again, I'd tell KyleRow that he is talking about implementation details. Your model of the real world needs to be independent of the implementation details. So, in C# / Java you use interfaces, whereas in C++ you use Multiple Inheritance. That's fine, but does not really change your underlying object design now how your real world objects interact with each other.
I know that OO and Frameworks have been a bit hotbed in the ColdFusion community lately. My preaching on this topic has come up a few times in the Flextras Friday Lunch.
I think the discussion of Object Oriented vs Procedural Design is a fascinating academic discussion. But, for all intents and purposes, it doesn't matter to us folks doing development on a daily basis. Most people are using a hybrid approach, at best, and calling it Object Oriented.
I believe the real secret to successful application development is to focus on encapsulating your code so that it can be reused easily. For some reason, the strategy pattern comes to mind. I once heard it described as "Separate out what changes from that which stays the same." That is a great, important, concept which has nothing to do with your approach to architecture.
So, where am I wrong? Be prepared to explain what piece of the real world system Data Transfer Objects and Table Gateways represent.
Maybe next I'll tackle methods that return nothing.
Now my post was not against OO in any way. The point of my post is that there are differences between JAVA stye and CF based OO. You should note that they are both OO. Your response was that there basically were no differences. You can spend a week pointing out where they are the same and it will not change that there are differences. :)
You state that the performance differences are negligible in your estimation for doing OO programming. A local developer I know who does Oracle and works with Java developers has one major complaint about Java apps. He says they are slow. I don't know what the issue is but funny that real world that reputation is earned on many occasions. This does not mean that Java is in fact slow but that OO is not negated by the speed of hardware yet. This is even more of an issue in CF because developers who think intensive OO are more concerned about making things object oriented than making the software work and perform. Perhyaps you should look at some discussions on CF speed of creating objects before debating this one. It was brought up in a recent podcast that Hal did just this week FYI.
Now in a way Custom Tags in ColdFusion are like DOM objects in HTML. (Document Object Model) My point here is there can be more than one type of object. Somewhere along the line the gurus of CF stoped understanding how ColdFusion thinks and started trying to make CF think like Java because it is built on top of Java. In the real world this can be done but in different situations this may not produce sustainable code. (Like how skilled does a developer have to be to come after you to maintain your cool use of design patterns? If it takes you two year to learn the design patterns and you put it in code... and you get sick, how easy will it be to fix a bug or enhance your code for the guy who comes after you?)
Lastly, you fall into the stereotype of comparing OO to prceedural code. LOL, there are different types of objects and packaging code in custom tags is another way to DRY (Don't Repeat Yourself) your code. It is particularly useful for creating code that focuses on "View" or "Presentation". The compulsive need to put everything into a Java object is my "original" point. It was not you that started the conversation so it's a bit self serving to turn it around to me not understanding you wwhen you didn't understand my comment to start with. :)
(FYI: I believe Jeff is one of the best developers in the ColdFusion community. Kudos for his expertise. My goal to the post and writing on this topic is to expand people to consider ColdFusion a development environment with advantages that go beyound resting and running in Java. The OO focus has caused many to loose focus on the power of custom tags and more.)
First thing is around semantics -- I don't know that OOP necessarily implies design or architecture - I like the other def'n I saw in your post - 'programming with objects' - I mean, it stands for Object Oriented Programming - so to me, OOP specifically has always just been adding objects to your toolbag and then coding away. OOAD is a term I see a lot (Object Oriented Analysis and Design) which speaks more to design principles and architectural thinking.......
Second thing is - from reading the post, I think you're working definition for OOP is close to my working definition for OOAD -- even still, I stand by my tweet.... language specifics do play a roll in architectural and design issues...
Going back to the example from my tweet - the "mixin" (http://en.wikipedia.org/wiki/Mixin) pattern is straightforward with multiple-inheritance, however if you happen to be using a single inheritance language, you are going to have to jump through hoops to accomplish the same thing. Those hoops will bring along with them lower readability and therefore lower maintainability ... so I'd still say there are "architectural" decisions that are in fact dependent on language specifics.
Programming = logic + semantics (IMHO)
Frankly, it's one of the aspects that make programming challenging. Some people are very good at the logic, can break down the issues into their real world object and tasks. But might run into difficulty with semantics of a language(s).
You can have one individual who is very good with the semantics of a language. Knows how to build and optimize his references, what syntax to use to call an object, etc. But doesn't necessarily have a good grasp of real world actions and usage. We've all seen these apps. Superbly coded...but clunky interface and operations. But coded with the best methodologies, practices and patterns.
Or in reverse. You can have spaghetti code, all procedural. But that understood what the use needed and provided a much better experience.
Anyways, I'm digressing from the point. I think what Jeffry was saying is that Object Oriented Programming's logic end should be the same. But that it's symantec, syntactical side will be different with a given language.
The implementation should still be the same. If you are selling guitars. And defining them as acoustic, electric, both. That shouldn't change regardless of whether coding in CF or Java. You'll still need a guitar object, it might even inherent from a higher "instrument" object definition. It'll have attributes. And if you want to sell it, that will be a method or action that will have to be done. So you'll need that task.
John,
Sometimes it does feel as if are tweets are combative. I have no idea if that is the case or something my mind has fabricated, though.
It is entirely possible I misunderstood your original tweet, and very probable that I took it out of context. It's like walking into the living room five minutes before the series finale of Lost and asking what happened. It's not gonna make any sense without a lot of extrapolation.
The point of my post was that there shouldn't be differences between Java style and CF style OO. OO architecture should exist at a higher level than specific implementation details.
With regards to performance differences, I don't have any data to back me up; it is just a gut feel.
The wikipedia definition of an object
http://en.wikipedia.org/wiki/Object_(computer_science)
agrees with my view of the world. An object is a group of data and the functionality to act on that data. Using that definition, I do not view custom tags as objects. They do not encapsulate data and functionality, just functionality. They are, in essence, CFs version of a subroutine or procedure. Which is not OO.
Kyle,
From a theoretical stance, OOP is a term to describe one approach to programming. It is all about the design / architecture.
However, I'd be willing to accept that the term has been watered down for real world use, in such a way that all programming is called Object Oriented.
Jason,
I think you got the message I was trying to communicate.
All,
I've often heard it said that design patterns are not language specific. They exist at a higher level than implementation details. They are a way to structure your code to address certain problems. I view Object Oriented or Procedural Programming paradigms as existing existentially higher than design patterns.
It is all about the entities you are modeling and how they will interact with each other. OOP focuses on mimicing real world actions. Procedural Programming focuses on breaking things down so they are easy for the computer to process.
Of course, I'm starting to accept that real world use today may be changing the theoretical definitions from yesterday.