Frustration

Damn I'm getting frustrated. Trying to build a DAO in CFC. A DAO is a Data Access Object. In Object Oriented Programming (OOP) you build mini programs called objects (that's not how a technical person would describe it, but f*** em). Each object does a job, so in a calculator you might have a display object that prints out the numbers on the display, a set of button objects that can be pressed - each one with a different value, a calculation object that does the maths etc etc. It's a method of building a program in the same way that we build things in the real world.

Another example would be building a house. Building an OOP house would involve designing a Brick object - you would then replicate that brick object and connect all the brick objects together to produce your walls. You'd also have window and door objects which you would replicate and use as... windows and doors. it's a duff example in that you wouldn't build a house program - please don't get confused an think I'm describing how a 3d model of a house is constructed - It's the concept we're looking at. Our naff house has been built using three things - Bricks, windows and doors. As I the builder I designed each of these things once, then replicated them. This is the OOP fundemental - reuse. Lots of little objects that can be reused and repurposed.

It's a great idea, except it is hellishly frustrating. A key principals is that every object you make is free standing. What good is a brick if it needs to be used in confunction with a window! A brick is a unique unit that doesn't rely on anything else. Imagine building a house in the real world and watching the side wall crumble because you didn't insert a window in it. This principal that everything is free standing makes sense - but it's a git!

Making something free standing is hellishly hard.

You might think the problem is in the detail. but lets go back to that house. Bricks, Windows and Doors. Ahh, but what about the tricky bits in a house like the bricks at the corners that have to be shorter to fit in. Or the pipe work that goes round the house, that must require all sorts of different lengths and angles. Surely that makes things very hard. Well it does complicate things, but it's actually OK. OO allows for that. You can build a basic brick, and then create a variation of that brick called Half-Brick. It's still a brick, it's just a variation of one. It shares most of the same properties. It's just different in the one respect of length. (To any programmers gnawwing the qwerty keys and protesting that length should be a property, half-brick is stupid - get stuffed I'm illustating a point. Hold your nubbin and be patient).

To me the difficulty lies not in the detail, but in the wide picture. The stuff that is taken for granted. The house is built on land. Land is not flat. The house needs footings to plumb it into the ground. There needs to be a road going to the house. It needs to know it's orientation to the road. It needs an address if letters are to arrive. It needs plans to be legal.

I'm straying to far down an analogy. What I'm ranting about is the fact that every OOP project I'm involved in seems flawed by the fact that at some point the application meets the real world. The real world has infinate variation. To intigrate with the real world you need to know certain things. As soon as those certain things come into play the objects need to be subtly varied to make them fit. But that subtle variation ain't so subtle. They're the same variations that had to be written in non Object Oreinted code. They're the same conditionals that were there before. Trying to create an object that fits all circumstances nearly always becomes a lie.

Let me put it a less meladramatic way.

Programs are tools. They are there to do a job. The job that needs to be done defines the logic that we must code into our tool. The program fits around the problem, not vice versa.

Whatever form the program takes it must fit around the problem that is there to be solved. Building it in objects doesn't seem to take away that underlying fact.

I s'pose I've ranted myself into a conclusion to my own unpossed question. An object oriented approach isn't better than a Proceedural approach (the old school way of programming). It's just different. It will suit some situations better than others. The programmer is still required to understand the problem that the tool is solving. The twisted logic required to fit in with the world will still be there in either case.

It shouldn't matter how you approach a problem. What matters is the quality of the solution. (In a program that is ease of use, ease of maintenance, cost etc... it's a long list). What bugs me about programming, and technology as a whole, are those that say "Do it this way", "This way is best", "This way is standard". The illusion that there are standard problems exaserbates this issue. rarely are two things the same when you look at the details. Our society believe there is white and black, when there is only grey (and green, yellow, blue, red, pink, misty, opaque, checked and lost-in-the-post).