The Campaign Against Unnecessary Object Orientation

if you know oop inside out, you are in a better situation to critizise it. To get to this point, you have to do everything in your new mindest.

Pete,

I am at a kind of interesting place right now. After hearing Clark Valberg talk at the last NY CFUG about Interface Driven Design, I went ahead and prototyped a small task-management application. Clark's idea (and those with the FLiP mindset - FuseBox Lifecycle Process???) preach that full prototyping upfront leads to faster, better development. In theory I agree, so I set out to test it for myself.

So, I have the full design file mockup (Adobe Fireworks). Then, I took that design and made a full *functional* prototype. I say functional, but it is not doing any code. Just flat files that can click through to pages with hard coded values.

I have not yet moved from the prototype to the full ColdFusion version... and that's where it gets tricky. The application is about 9 pages long. And from the prototype, I really can see what is needed. I can show others and get feedback and before any real ColdFusion code is put down, I am going know more or less that the application will be successful as long as it does what the prototype does.

So, for this small, 9 page application, where the upfront design suggests that maintenance will not be a huge issue.... is it worth doing this in OOP? Let's say I did the whole thing in an old-school, proceedural way; I could probably finish off the entire app in less than a day. I'm not talking code generation or anything fancy... i'm just talking nose to the grind stone put my head down and muscle through it.

If I went the OOP route, it would take much longer. Between creating beans and gateways and services and controllers and all the time *NOT* really being sure how it all fits together... it would take days to do (optimistically), and at my skill level, would probably not turn out as nicely as the procedural counterpart.

So what to do? One the one hand, I want to learn OOP and I feel that it can have great benefits for large projects. But on the other hand, I feel that this app might just work *better* if I were not to use OOP.

I think what I might end up doing is doing it procedural at first and then perhaps re-doing in OOP. The app is small enough where this is a very possible idea.

Anyway, that's my two cents worth of frustration on the matter.

Pete,

I want to say No to all of those. My small task management app is basically a glorified ToDo list that has:

Clients
Staff
Tasks (joined to staff / clients with extra info)
Teams (join of staff to clients)

That's all there is to it. As you can probably guess, 8 of the 9 pages in the app are the list / edit pages for the above 4 items. So yeah, in the interest of time (i am doing this for work but in my OFF hours, so no pay) I just want to get it done.

Then, if we start to use it at the office, which I hope that we will, perhaps I can sell my boss on expanding the functionality and rebuilding from the ground-up in OOP on the company's dime :)

I'm one of those people who has accused OO zealots of insisting that every last single page app be fully be-patterned and multi-tiered and what-have-you. But on your request for specific examples, sadly I can think of none.

Here's what I think: the problem is that programmers who don't embrace OO are constantly told they are dinosaurs, they need to get with the OO program or get a new career, they need to skill up quick or get left behind. I think that's where the ideas that zealots think everything should be OO are coming from.

I'm actually in both camps - I do some basic OO-style stuff AND some procedural stuff with Fusebox 4.1 - and while I can see the OO benefits, which is why I use it in particular situations, I also work a bit on systems that totally don't need the complexity. I am actually working on a system where both approaches are used within different areas of the same app, for quite specific reasons.

Here's what I reckon: long live diversity in programming!

Where I work we do mostly small business sites and a lot of basic 'query it / output it' type scripting. Many of the jobs, there is NO reusable code, even if you wanted to. That's just how small some sites are.

I have worked on other sites that require a lot of functions / methods to be built to keep the thing maintainable. I keep CFML away from HTML as much as possible without taking a full on OO stance.

I've played around with a lot of OO principles, but they simply do not fit most of our sites.

There is nothing wrong with OO approaches, in fact you can do some really nice things with OO ideas, but it is overkill in a small site, adds unnecessary complexity to what should be simple. A simple script that runs a query or 2 and outputs results will ALWAYS run faster than the overhead of most frameworks also. (not that frameworks are the issue here though.)

So I think there needs to be a balance, and the best techniques for the job need to be applied.

For sure. I mentioned it as fact - not a reason for choosing.