I hear a lot of OOP fans say that OOP makes large applications "easier to maintain", and the question always comes to mind "Easier for whom?". If I ask "Who will be maintaining my application?", the answer is "ColdFusion developers", and if I ask "Which programming paradigm are ColdFusion developers generally more comfortable with?", I would have to say the answer is "Procedural". Here in the Orange County/Los Angeles area, it's hard enough to find a decent CF developer without limiting my search to the small amount of people that claim to be OO programmers (and some of those aren't even really OO programmers, they just need a job and will say anything). Not to mention that the CF Developers that really do know OOP are often more expensive than their procedural counterparts.
I am not an OOP guru, so my opinion may not be firmly planted in reality, but I don't think the size of the application really matters when it comes to deciding weather to develop it in pure OO code or to develop it using procedural code and maybe sprinkling in some OO concepts where it makes sense.
I have developed some pretty massive systems, but I don't see how using a pure OO design would have made those applications any easier to maintain. If anything, I think it would have been even more complicated then it already was. It definitely would have slowed down my development (which is not an option for some high pressure, deadline driven, work environments).
I think the most important part of making an application maintainable is making sure that, not just you, but anyone who is proficient with your chosen language will be able to follow the code and understand how it is organized (without having to spend a week or two with Hal Helms to wrap their head around OOP). If, one day, CF developers are all generally more comfortable with using the OO paradigm, and the WACKs are all written so that new CF developers learned how to do OO right from the get go, then I would definitely be on board the OO bandwagon with everyone else, but I just don't see that happening as it would defeat one of the main benefits to programming in ColdFusion: being easy to learn.
I'm not against OOP. If I were developing video games or something in Java, then OOP is definitely how I would go, because OOP is the norm for Java developers. Also, I would definitely be open to spending some time fine tuning OOP concepts in my mind by applying them in some ColdFusion sample applications, just because I am already familiar with CF and it would allow me to concentrate my learning efforts on the OOP concepts rather than learning a new language.
However, while I think OOP is good in theory, and there are a lot of ways I use it's basic concepts to improve the way I write my procedural code, I just don't think I'll personally be using a pure OOP approach in real CF applications anytime soon.
I don't think either paradigm is fundamentally better than the other. I just think they are two ways of doing the same thing. In the long run, how you choose to organize your code is up to you, and I believe the general consensus, among OO and procedural programmers alike, is that it is important to keep your code neat, organized, consitant, and wherever possible, you should try to identify parts of your code where you can write generic modules/custom tags/functions/components/objects/etc so that when you need to change some bit of logic, you only need to do it in one spot.
Comments (9) |
6573 Views
If you are looking for an experienced, professional, and reliable ColdFusion development company, contact PALADEM today.
HOWEVER, OOP does allow code reuse among the same application, and that is something that many procedural programmers lose. I have seen hundreds of apps that have thousands of .cfm pages, each with thousands of lines of code, each doing almost the exact same thing. You wouldn't even need OOP, just a few functions, includes, whatever...
Using OOP principles you end up with a consistent API, consistent UI (not guaranteed, but it does help), and maintainabilty.
You stated that it is difficult to find a CF programmer that programs OOP well. The problem that I see is that there are very few CF programmers who know how to program. Period. I sometimes find that since CF has such a small learning curve, people jump into it, call themselves programmers, and write all kinds of terrible apps that give ColdFusion a bad name.
So maybe we don't need to write OOP style code, but I would at least recommend that we know what it is, know the advantages of it (if any), and create goals for ourselves of writing solid code.
Ben Nadel is a great example of a great CF programmer- he knows that he doesn't know everything, so it is his objective to be constantly learning and bettering his apps.
So should OOP be the goal, or should solid, maintainable, commented code be what we are after?
"The problem that I see is that there are very few CF programmers who know how to program"
This is very true, I have hired developers that were "Senior Developers" at other companies for years, and then had to teach them how to not write terrible code anymore, but usually that does not involve teaching them concepts that are foreign to them, just stopping them from writing sloppy code because they are lazy, and forcing them to follow a few rules that ensure things stay organized.
If I had to take those same people and try to explain what Inheritance, Abstraction, Encapsulation, and Polymorphism mean it would be much more difficult.
Solid, maintainable, well documented code is definitely the goal.
I've been in the opposite situation where I was the new CF developer telling the "Senoir(Old) Developer" about doing things "well" instead of in a sloppy fashion. Lets just say my views to do things "well" were frowned upon and the thought of OO scared him silly... so I moved on. I'm not here to fix the world just to code to the best of ability.
Even though I'm an advocate of OO I sometimes wonder about peoples use or I should say overuse of the principles in CF. Even though CF has Objects/components it is no Java or C#. I would really like to see the CF OO language features get a power hit so they are more hardy. CF leaves a lot of weight on the developer to make sure they extend, implement, or override functions/properties correctly. In the end this allows for mistakes to be made in the OO structure. So fingers crossed for the CF9 release being focused on the language like CF6 was.
The number of years someone has been a developer does not indicate the quality of that work experience. There are a lot of people that just move from one maintenance job to another who maybe get good at "MacGyver-ing" existing applications to meet the ever changing needs of their employers, but never actually build an entire application from the ground up. I don't think that means they aren't capable of doing it, but it would be a bit of an eye opening experience for them. It's a lot harder to learn how the differences between different design patterns, frameworks, and programming paradigms, when you are never doing any new development.
I was lucky enough that my first few ColdFusion jobs were positions where I have been the "web-architect", but I have also had the "web-handy-man" jobs and can see how I could have easily fallen into the other category if things had been different.
However, the main point of this post really, is that I don't a lot of the "web-architects" that are over implementing OO in their apps just because they think it will be more maintainable (for them) are really truly thinking about who else might be maintaining this application in the future. Chances are pretty high that a "web-handy-man" is going to come along and jerry-rig your work, and you don't just need to make it as easy as possible for him to do that, you need to make it as easy as possible for the owner of the application to find a web-handy-man that can work on the application. And let's face it, most of the "web-handy-men" out there are more comfortable with procedural code.
spaguetti code programmer. It is almost like a sin.
Like there is no middle ground or bad OOP. Also recruiter ask for OOP and if you don't
mention it you are in the second.
Great Blog.
I've been a web architect for several years. I think there needs to be a clear distinction between OO design and OO programming. In OOD, you are designing with concepts that make it easier to change parts of the application without dependency on other parts. OOP is implementing an OO design in all (or nearly all) objects of some type. As a programmer, to make the leap from OOD to OOP requires that you know how to create applications using objects. However, just as your code should be programmed to an interface and not an implementation, your design should not be (or at least attempt to not be) dependent on the language in which it will be implemented. Granted, each language has its own nuances, big and small, which make certain design implementations easier, but the design shouldn't require it.
As for OOP and maintenance, if you define maintenance as the daily routine of making sure code runs, then OOP doesn't make anything easier, and can, make things more complex as the programmer needs to conceptualize decoupled objects and understand complex object interactions. However, from an architectural standpoint, when the application needs to change because of the ever moving targets of the business shift, then OO design (not necessarily OO code) makes it easier to code. The concepts behind good OO design can, in large parts be applied to procedural programming. A lot of CF web apps end up nothing more than procedural code wrapped in components and some data beans. So you've created objects but the overal design is still procedural.
It all boils down to experience. All the times we looked at code and said, "next time I should it this way". After you've said that to yourself often enough, you might find that OOD isn't so bad after all.
If you re-read the post and pay particular attention to the last few paragraphs, you'll see that I am not saying that OOP is bad, I think it can be very good in the right context. Also, I want to clarify that I don't think the ColdFusion language is the reason that I personally wouldn't implement a purely object oriented application. My primary point can be seen in the first paragraph. Right now, most CF developers are more comfortable with a procedural application than with an OO application.
So if I am building a large application, and I want to make sure that it will keep on running I should take into consideration the currenty climate of the cf developer community to ensure I will be able to also maintain a staff of developers. If I implement an OOP application in today's market, I would have a more difficult time finding developers with the OOP experience I require, and will probably also have to pay higher salaries for the developers I do find.
Even if I should decide that I really like OOP and I want to grow the CF OOP community by hiring promising procedural CF developers that want to learn OOP and teaching them. Then I am adding all that learning curve and I loose my rapid development cycle, one of the primary benefits to developing in CF in the first place.
I personally feel that a good staff of procedural CF developers working on a well implemented procedural CF application would be just as effective as a good staff of OO CF developers working on a well implemented OO CF application. But in today's market, I personally can't justify the extra trouble/expense of trying to find good OO CF developers. If the tables were turned, and most CF developers were more comfortable with OO programs, then I would implement all my applications in that paradigm.
Regardless, of the paradigm I use, it will probably turn into spaghetti code once I (the original architect) leave the company, or move on to the next project, if I don't leave someone there that will enforce the coding standards that I implemented.
So, in closing, this was not an article about "My paradigm is better than yours". It is simply saying that before I decide to implement any particular programming paradigm, or even a particular framework, I need to think about how that choice will impact my time line, my budget, and my ability to staff a development team.