"My Boss Wants To Know Why We Should Create Objects"
A good friend of mine IM'd me this morning, hot in the middle of a sales pitch to his boss as to why it was a good idea to get away from the Spaghetti paradigm and move towards some semblance of OO methodologies. Our conversation was short and sweet, but I thought I'd toss it out here in case anybody else has anything to add (or correct), for the benefit of any other developer who finds themselves in a similar "sales" position.
The Conversation
The Conversation
| MyBuddyJack: My boss wants to know, why do we have to create instances of objects and go that route? Why can't we just use cfinvoke to get the data we need and just code everything an object needs right in the same cfc. |
| MyBuddyJack: I think he is wanting to code things procedurally, but with cfcs...that's the feeling I get. But what is the advantage to coding it more OO by creating instances etc.? |
| MyBuddyJack: I just told him it is easier to maintain and change down the road. |
| Doug Boude: persistence |
| MyBuddyJack: I couldn't really sell it like I wanted. |
| Doug Boude: for example, i have a user object. If I instantiate it, then I can keep it alive and interact with it, changing things about it here and there and maintaining those changes throughout the life of the object |
| Doug Boude: if I just use invoke, I'm treating it as nothing more than a dumb collection of functions |
| MyBuddyJack: he wants to put everything into the session scope |
| MyBuddyJack: so everything is always available anywhere |
| Doug Boude: and what would BE in session? Oodles of variables sitting there beside one another, all in the same bucket, differentiated only by some naming convention, if that? |
| Doug Boude: using a CFC as an object, you collect related things together, so you always know where to go for a specific thing |
| Doug Boude: if you didn't use a User object, I'm POSITIVE he'd probably create a User structure that lived in session to hold all of the user's info |
| Doug Boude: but, the methods he needed to act upon and with that user info would all be living here and there and everywhere...little semblance to anything truly organized and encapsulated. |
| Doug Boude: to move that user functionality, then, at some later date would be a nightmare because SOME Of the user stuff would live in application.cfm, some of it would live in some UDFs, some would live here, some would live there...no encapsulation |
| Doug Boude: it would be what we have always been used to: spaghetti |
| MyBuddyJack: Yeah that's a good point. I told him that if he has an instance of a User Object, then when he wants to output stuff he just calls the object, whereas otherwise he'd have to invoke everytime to get the data he wanted. |
| Doug Boude: but stuff it all into a user CFC, and voila! it's always packaged up, ready to drop into anything |
| Doug Boude: invoke is expensive...it instantiates the object first, then calls the method, then destroys the object again |
| Doug Boude: extra overhead |
| Doug Boude: why not just breathe life into it ONE time initially and have it waiting to be called upon instead? |
| Doug Boude: i could only see using cfinvoke under two circumstances |
| Doug Boude: one, when my CFC is truly just a collection of random methods that I will need on occasion only |
| Doug Boude: or two, when I need to call dynamically named methods, which isn't possible on an already instantiated object |
| MyBuddyJack: I think I understand encapsulating everything as a benefit. But is that it? What other beneifts are there to instantiating objects OR why is that better than procedural? |
| Doug Boude: you can instantiate objects and still code procedurally |
| Doug Boude: it's really two different things |
| Doug Boude: using CreateObject does not an OO application make |
| Doug Boude: like i said, there's the savings of overhead; there's the logical arrangement and grouping of both functions, business logic, and data |
| Doug Boude: there's the re-usability factor, should that ever be a desire |
| Doug Boude: if you use objects as the main basis for your app, then one day when the light DOES go off for them and they see the beauty in MVC, moving to a new framework won't be nearly as large a pain |
| Doug Boude: it's MUCH easier to make modifications to an app when you have things arranged in objects, and without having that old common spaghetti coder's fear, "What else is going to break if i change this?" |
| Doug Boude: but putting things into CFCs and then using CFINVOKE to interact with them is like starting your car long enough to get you to the first stop sign, then turning it off again. then starting it up again when you're ready to proceed, then turning it off again at the next red light. etc. |
| Doug Boude: in that analogy, it almost looks...ridiculous to do it that way |
| Doug Boude: and, it's easy to see the extra overhead involved with that analogy...extra wear and tear on your starter, extra time needed to actually respond to the light turning green, etc. Same thing in an app |
Subscription Options
You are not logged in, so your subscription status for this entry is unknown. You can login or register here.
Re: "My Boss Wants To Know Why We Should Create Objects"
I happen to have a book lying around that is for managers looking to grok object technology.
"Object Technology: A Manager's Guide" by David A. Taylor, Ph.D. ISBN 0-201-30994-7
Fortunately, my boss isn't a developer and so doesn't bug me about my methodology.
(If anyone is interested in this book it's available on Bookmooch.)
"Object Technology: A Manager's Guide" by David A. Taylor, Ph.D. ISBN 0-201-30994-7
Fortunately, my boss isn't a developer and so doesn't bug me about my methodology.
(If anyone is interested in this book it's available on Bookmooch.)
Posted by Al Everett on August 29, 2007 at 1:39 PM
Re: "My Boss Wants To Know Why We Should Create Objects"
OO isn't inherently better than procedural coding in CF, so there's much more to consider than which is better for application development:
1) Are all the programmers, especially your boss if he's coding, really familiar with OO? It's a pretty big learning curve for folks set in their procedural mindsets, so even if it eventually helps in the long-term, you'll be severely slowed down in the short-term.
2) If there's lots of load (many thousands of sessions, or dozens of requests per second) on the site, then most CF OO frameworks don't scale under that type of load without significant work to cache page output. see cf_accelerate. Also, note that you don't want to put a bunch of objects into session scope if you could have many thousands of sessions at once, as memory could start to run low.
3) You can use a non-OO framework such as PLUM (an oldie, but goodie) as a basis to build scalable, maintainable applications. It puts CFCs (the collection-of-functions variety) into Application scope, which means CreateObject is only called once for each CFC when the app first starts up (very scalable!).
my $.02
good luck!
1) Are all the programmers, especially your boss if he's coding, really familiar with OO? It's a pretty big learning curve for folks set in their procedural mindsets, so even if it eventually helps in the long-term, you'll be severely slowed down in the short-term.
2) If there's lots of load (many thousands of sessions, or dozens of requests per second) on the site, then most CF OO frameworks don't scale under that type of load without significant work to cache page output. see cf_accelerate. Also, note that you don't want to put a bunch of objects into session scope if you could have many thousands of sessions at once, as memory could start to run low.
3) You can use a non-OO framework such as PLUM (an oldie, but goodie) as a basis to build scalable, maintainable applications. It puts CFCs (the collection-of-functions variety) into Application scope, which means CreateObject is only called once for each CFC when the app first starts up (very scalable!).
my $.02
good luck!
Posted by Aaron Longnion on August 29, 2007 at 6:37 PM
Re: "My Boss Wants To Know Why We Should Create Objects"
So one thing I thought about while reading this post is that objects are a way to organize your session variables.
You could put all your variables in session, but that would be like putting all your files in the root directory.
Think of Windows File Explorer. If you right-click on a file, you have methods called "Open" and "Properties". Openning a text file is accomplished differently than Openning an mp3 file.
But does the analogy carry to subdirectories?
If a session variable were like a file, could you explain to your manager that objects are like subdirectories?
You could put all your variables in session, but that would be like putting all your files in the root directory.
Think of Windows File Explorer. If you right-click on a file, you have methods called "Open" and "Properties". Openning a text file is accomplished differently than Openning an mp3 file.
But does the analogy carry to subdirectories?
If a session variable were like a file, could you explain to your manager that objects are like subdirectories?
Posted by Phillip Senn on August 30, 2007 at 10:08 AM