Frameworks vs. Object Oriented Programming
I don't use any traditional framework in my code. Call it the "No Framework" framework, or the "roll your own" framework, or spaghetti code; I don't really mind - what I do seems to work. Of course, I do want to learn more about frameworks and have tried several times, but I seem to have a mental block. Because of this, my inability to move into a standard framework, I have never thought of myself as an Object Oriented Programmer.
But, what makes an object oriented programmer? Do I use object (components, java objects) in my code? Sure I do - I wouldn't be able to live with out them. I build my own shopping cart systems. I encapsulate my form error collections. I have components that handle file uploads. I have configuration objects that encapsulate the programmatic calculations for web and server paths. I am always using the Java StringBuffer object to optimize my string concatenation and the Java String object to run powerful regular expressions. I create and/or use objects all over the place (heck I even have a ServiceFactory in one or two of my experimental apps) - so, maybe I am an object oriented programmer.
I think I have to shed this backwards mentality that I have to have this complex architecture in order to be an object oriented programmer; I think that is an outdated mentality that stems from pre-web, software development point of view. I don't use a traditional framework, but I DO use objects; I use lots of them, they just happen to exist in a more procedural environment.
Reader Comments
Seems to me you are using a page-controller framework. Ultimately, that's what spaghetti code is, but if you componentized your business logic for reusability into some type(s) of object(s), you are using the Page Controller and Object Oriented techniques. So I would say you are an OO programmer.
I know were your coming from with the framework stuff, i started using Model Glue this year and have just switched over to Coldbox http://www.coldboxframework.com/ after years of rolling my own stuff in my own way
"Model Glue just felt kinda natural for a cf developer" was what i heard about it and what i found that was true.. except for the XML bit... it felt very foreign and still does...
then i found coldbox which feels like natural CF coz there's hardly any xml
i blogged at bit about this today
http://zacster.blogspot.com/2007/05/coldbox-cfmx-framework.html
Ben sure we can code without any framework, does your own invented ways / thinking is going to impose on your team. What about new CF member/programmer, how he will get on your existing projects.
I know working with any framework certainly involve some sort of learning curve but all these are for better project control/management/enhancement across web-team.
I found myself working with framework improve coding standard and help in writing better code, as well as new MVC framework really help in understanding of OO as well, personally I started with zero knowledge of OO but keep reading/implementing and more involvement in MVC coding habit made me to think and implementation of OO [ scary world :) ]
You are OO man or not; is not the case at all but most importantly how well written your code in terms of performance/modification/enhancement. having/writing procedural code is not a crime, Ben we are living in a real world where clients deadline are more than anything else so I could say almost 99% programmers breaks OO rules to meet the deadline.
In my opinion you should give a proper try to frameworks like [fusebox] [coldbox]. These framework have many built-in things which really helpful in development speed. In my opinion I don't like to reinvent the wheel. Sean Corfield blog is really excellent for understanding of many implementations.
If you have sometime I would suggest please please read these couple of articles.
http://cfdj.sys-con.com/read/317576.htm
http://ortus.svnrepository.com/coldbox/trac.cgi/wiki/cbArticleWhyColdBoxExists
Ben, I agree with Sana. It is not important to define your code or style as OO. OO is a means to an end, not the end in itself. The important aspect is that you have reusable, maintainable, easy to understand, etc, etc code. OO principles help do that.
Using a framework does not make your code object oriented any more than using objects makes it object oriented.
Or, put in a different way: "Sticking feathers up your butt does not make you a chicken."
I agree, frameworks are a good thing; they require coding standards and provide a development environment that other developers can jump in and out of (provided they all understand the same core ideas). I did not mean to imply that I was against frameworks. Quite the opposite - I want to learn more about them.
All I was saying was that somewhere in my mind, I made the incorrect association that I could not possibly be an OOP programmer until I understood frameworks (and MVC style ones specifically).
As far as:
"Using a framework does not make your code object oriented any more than using objects makes it object oriented."
... I guess this begs the question, "What makes an OOP programmer?" Does using OOP principles make it so? Does invoke objects and using them make it so? Does using objects that have "state" make it so?
I would say (and this is, I guess, the point of my initial post) is that because this definition is so debatable, that if I use objects, I am an OOP programmer. Granted, it doesn't mean I am a GOOD one, but just that I am one at all.
Remember, just cause you are a "Web developer" doesn't mean you make good web site. And just cause you are a graphic designer means you make good graphics.... and just cause I am an OOP programmer doesn't mean I make "best practices" decisions about OOP programming.
"Using frameworks" and "Using OO" are completely orthogonal.
Fusebox was 'the' framework in CF for many years and was entirely procedural. Even today, Fusebox 5.x allows for completely procedural applications even tho' the core is pure objects. Of course, you can also write serious OO applications in Fusebox if you want.
The same applies to Mach II and Model-Glue (and ColdBox and SOS, I'm sure) - you can still write a procedural application... you just have to wrap that procedural code in a CFC.
Conversely, I was writing OO code long, long before I started using frameworks in my day-to-day life. I was doing OO in C++ back in '92 and the closest thing to a framework available was STL which didn't appear for several years. I started Java in '97 and didn't use a framework with that. My first CF code, in 2001, was also OO, but I didn't pick up a framework until Mach II in mid 2003.
["Using frameworks" and "Using OO" are completely orthogonal.]
Exactly. I think what happened to me was that I didn't know frameworks AND I didn't do anything object oriented at the time. Then there was so much talk about MVC over the past two years that I just kind of lumped the two together.
This post was the revelation that I was crazy :)
And of course, MVC is orthogonal to frameworks and OO :->
It is possible to implement MVC without using a framework or OO, a framework doesn't have to be OO (e.g. FB) or MVC (e.g. Transfer) and OO code doesn't have to use a framework or implement an MVC approach.
Ben Nadel is orthogonal to MVC and Frameworks :D
..... at least for now (dum-dum-duuuuuuuuh)
Re: "and just cause I am an OOP programmer doesn't mean I make "best practices" decisions about OOP programming" and "What makes an OOP programmer?"
I think a more apt comparison that follows the rest of your comparisons would be something more general: "just because I'm a programmer doesn't mean I write good code." Certainly an OO programmer might not always see the best design decisions, but I think it requires more than using objects. By that definition, simply creating an entire program in the main() function in Java qualifies one as using objects, and calling him an OO programmer.
But, is there value in deciding whether or not one is an OO programmer or if code is OO? I'm not sure (but I'm not opposed to the thought that there might be either).
A former colleague of mine answered my questions on the point of using OO or frameworks by likening "general" objectification and modularization of code to what a good carpenter does when building a good table. If he has any idea what he is doing, he puts the legs on with screws instead of nails. This way, if the customer doesn't like the legs or the table top, both are not lost in the conversion and each is somewhat reusable.
I have only been working with C# for about a year now and have used OO concepts since then in C#, CF and JavaScript occasionaly ever since, in order to help me view my code as more readable, scalable and reusable. If everything is not necessarily OO but is still readable, scalable and reusable to some extent, I'm doing myself a favor. If my code is none of the above, it's because I'm doing my boss a favor and getting the project completed with, possibly some serious maintenance requirements in the future.
The company I work for avoids frameworks in just about every sense and every department. It seems to keep us much more agile in our field.
Will have to read up on MVC. Not sure I've heard about it. Have I had my head up my ass with feathers?
Well, if Ben's orthogonal I want to be orthogonal too :)
I agree that OOP is a means to an end - suits some people, suits some projects. Everyone should know it from a career point of view, but that's a different issue.
Having said that, for the nitpicking fun of it I'd draw a distinction between object *oriented* programming and object programming. Anybody who has used the Windows API has done object programming - in the sense that they're programming objects - without necessarily being OO at all.
In that light, the term OOP is a bit of a gloss (as has been pointed out before). A design can have an orientation towards objects, and a language, by providing helpful language features, can likewise have an orientation towards objects. So OOP is really a shorthand way to say "Implementing an OO design, preferably but not necessarily using OO language features".
Jaime Metcher
I ahve a blog for Object oriented ideas http://fascinatingoops.blogspot.com