Page 3 of 6
Posted: Tue Mar 01, 2005 6:08 am
by CoderGoblin
While I must admit I have only browsed through the current posts. I find people get confused between Object Classes and Functional Classes.
"True" OOP has objects which may have dependencies, common example shown in textbooks, a car needs to have the motor switched on before it goes forward by pressing the accelerator. Pressing the accelerator when the car ignition is off doesn't do anything.
Functional "classes" are in reality just a list of common functions grouped together, without any real dependancies. When dealing with PHP this is often the most commonly seen "OOP".
I have through the years written code in COBOL, FORTRAN, ADA, Java, Visual Basic, LISP and a few others. True OOP is not something that can be written without careful design first. In fact to produce it you need to spend about 40% time designing the system, 10% of the time coding, 30% testing and 20% documentation. In the real world people do not like paying for the design, testing and documentation. The design is after all the Requirement Specification isn't it

, why should the customer care about documentation other than a user guide and testing is not required if you did the coding correctly is it ?
With PHP I think we tend to drift more towards rapid prototyping projects to demonstrate the page layout etc to clients, hence the development of the "functional classes" OOP.
I think both have a role to play and can be useful. The key is well documented/annotated code and I recommend PHP documentor at
http://www.phpdoc.org/ to help with this even if only for internal use.
I am now ready for the flames....
Re: OOP
Posted: Tue Mar 01, 2005 9:45 am
by McGruff
Black Unicorn wrote:The only drawback I find [..with OOP..] is that debugging is slightly less straightforward
You'll love unit testing (there's a link to SimpleTest in my signature). Testing pretty much eliminates debugging frustration. And it has a ton of other benefits.
Posted: Mon Mar 07, 2005 1:44 pm
by BDKR
CoderGoblin wrote:
True OOP is not something that can be written without careful design first.
Couldn't agree more. But I hold that the good design practices have a dramatic effect not only on an OO finished product, but also a procedural one. Procedural code can be looked at and broken down into distinct building blocks as well as OO code. As a matter of fact, I say that procedural code that is realized in this manner is Object Oriented (that is if you accept that the existence of objects is not required for an OO solution).
Anyway, I think it's unfortunate that there is still this 'OOP is the golden path' stuff floating around. It's been proven over and over again that one paradigm can suffer the same issues as any other. We should be able to transcend this stuff at a higher level and that level is design. RDD and OOD as a matter of fact.
Posted: Mon Mar 07, 2005 2:30 pm
by McGruff
I think you're right that nicely organised functions would display some of the characteristics of an OOP design but the procedural alternative would merely be a hamstrung version, comically bending over backwards to maintain its procedural purity. If someone had got to that level of understanding, it should be pretty obvious that OOP has much more to offer.
Personally I feel more and more strongly that the OOP debate is a complete waste of time. There is no debate: procedural simply doesn't cut it. OOP is a tried and tested paradigm and has been for some time. There is so much nonsense talked about the subject on the internet and I don't like to see learner programmers being misled.
Sorry BDKR - and others - but it's got to be said.
Posted: Mon Mar 07, 2005 4:01 pm
by BDKR
McGruff wrote:I think you're right that nicely organised functions would display some of the characteristics of an OOP design...
Actually, that's not at all what I said. I used the term OO, not OOP.
McGruff wrote:
...but the procedural alternative would merely be a hamstrung version, comically bending over backwards to maintain its procedural purity. If someone had got to that level of understanding, it should be pretty obvious that OOP has much more to offer.
The above is only (potentially) correct if you hadn't misunderstood in the first place. Using RDD or OOD with prodedural code doesn't mean one
must attempt to mimmic objects or otherwise.
McGruff wrote:
Personally I feel more and more strongly that the OOP debate is a complete waste of time. There is no debate: procedural simply doesn't cut it. OOP is a tried and tested paradigm and has been for some time. There is so much nonsense talked about the subject on the internet and I don't like to see learner programmers being misled.
Personally, I don't like to see the learners led astray with the mental ceiling of "This paradigm is the shining path".
What I said doesn't take away from the usefullness of OOP, but instead attempts to elevate the entire conversation. There was something that Harry Fuecks wrote in his blog stating that Procedural Code leads to slower apps. Not talking about development time either, but instead performance. Of course, this isn't what was really meant. It was more just to do some chain yanking (get a reaction). Reading between the lines of what was said, is the idea that those who've spent some serious time in OOP are more likely to come up with a more effecient algorithm for whatever problem is at hand.
To some degree, I agree with this. However, what this really points too isn't OOP, which is the act of using objects, but OOD, which is design at a higher level with a view of software constructs that is object centric, whether or not an
actual object is used.
Don't let yourself be so swept away with warm feeling and glowing rays that these nuances are lost on you.
As for procedural, there are large numbers of bodies that have been using what we call procedural or functional code for some time and enjoying great success. A long time ago the military took an object view (though they never used the term) to how much of it's code is organized and used. Individuals were responsible for writing a hunk of code with a specific interface that performed a specific action. That should sound familiar.
Simply put, good design (OOD/RDD) stands a level above OOP or procedural/functional and is the key deciding factor in how well a project turns out. All the rest of the flag waving, baby kissing, and sticker selling is just immature.
Sorry, but it's got to be said.
Posted: Mon Mar 07, 2005 5:01 pm
by smpdawg
I had actually made those same points a while ago in this thread and the consensus seems to be this. I believe what I believe. You believe what you believe. etc.
There seems to be little room for discussion when it comes to those of us that have been programming for some time and have made up our own minds. The truly sad part is that people that are learning right and wrong may be led astray by people that know better.
BTW - This is not a slam, it is an observation.
Posted: Mon Mar 07, 2005 5:23 pm
by McGruff
[quote=BDKR]It's got to be said.[/quote]
Sure - I wouldn't want to close down the debate.
I do think it's important to make the point that, almost without exception, the whole thing just sounds naive to more experienced programmers. In fact, you're the only one I know who doesn't seem to think so. Where people stand on the OOP "debate" is almost a litmus test of their programming knowledge.
I know you were talking about "OOD" to refer to object-oriented design in general. But surely you're not saying that working with functions in this way can approach anything like the power of full-blown OOP?
But now I'm being sucked in... I'm burnt out with the whole thing to be honest.
Posted: Mon Mar 07, 2005 6:12 pm
by timvw
Time has proven we don't need oop to implement good software.
Time has proven oop can be very useful to implement good software.
Usually discussions are about the 2 statements above. Imho it's obvious that using oop isn't the right solution per defintion, but if you have a firm understanding of oop it can be very useful to find a solution.
Time has proven that with a good design it doesn't matter how the code is implemented as long as the design requirements are met. So the essence is to get the interfaces (the way how modules/classes communicate and (not) share data with each other) right.
BTW: Imho, the example in Harry Fuecks blog was not a good example. The difference in performance is due to the algorithm used. Not because of the chosen paradigm.
Posted: Mon Mar 07, 2005 6:13 pm
by BDKR
McGruff wrote:
I do think it's important to make the point that, almost without exception, the whole thing just sounds naive to more experienced programmers. In fact, you're the only one I know who doesn't seem to think so. Where people stand on the OOP "debate" is almost a litmus test of their programming knowledge.
You know, this very well could be an impetus for taking the gloves all the way off, but I won't. But I will say that if you are going to come out with statements like those above that are completely unfounded, perhaps you should drink less coffee, more water, and take a vacation.
Peace and Love!

Posted: Mon Mar 07, 2005 6:15 pm
by BDKR
timvw wrote:
The difference in performance is due to the algorithm used. Not because of the chosen paradigm.
Err...., that's what I was trying to get across.

But oh well.

Posted: Mon Mar 07, 2005 6:23 pm
by timvw
i figured that out after reading it again... sorry, i'm still learning english :p (sometimes it's hard to discover nuances when i'm speed-reading)
Posted: Mon Mar 07, 2005 6:46 pm
by McGruff
timvw wrote:Time has proven that with a good design it doesn't matter how the code is implemented as long as the design requirements are met.
That's not actually true - the forum you are viewing is a perfect example. It's perfectly functional but it's a nightmare to maintain so much so that I'd rather write a whole new forum (in OOP, naturally). In the business world, maintenance is expensive hence modern extreme programming methodologies such as unit-testing, pair-programming etc.
Posted: Mon Mar 07, 2005 6:46 pm
by McGruff
BDKR wrote:You know, this very well could be an impetus for taking the gloves all the way off, but I won't.
Be my guest - I won't take it personally. If the amount of coffee I have or haven't drunk is your best argument I won't have too much trouble defending my point of view.
Incidentally, how do you pass vars around in your non-OOP "OOD"?
Posted: Mon Mar 07, 2005 6:50 pm
by smpdawg
Incidentally, how do you pass vars around in your non-OOP "OOD"?
Don't go there, we will spin off in an entirely different and ugly direction.

Posted: Mon Mar 07, 2005 8:01 pm
by timvw
McGruff wrote:timvw wrote:Time has proven that with a good design it doesn't matter how the code is implemented as long as the design requirements are met.
That's not actually true - the forum you are viewing is a perfect example. It's perfectly functional but it's a nightmare to maintain so much so that I'd rather write a whole new forum (in OOP, naturally). In the business world, maintenance is expensive hence modern extreme programming methodologies such as unit-testing, pair-programming etc.
I don't think phpBB was really designed, more that it evolved into something unmaintainable ... But i doubt it that with an oop implementation there wouldn't have been a maintenance problem.
Although eXtreme Programming isn't my thing, since the day i started programming i've been doing test-driven development thus unit-testing was a natural way to go
I've tried pair programming a couple of times but i just didn't feel comfortable with it. Although i like to brainstorm on the chalkboard with the others and filter out the required interfaces.