Page 6 of 6
Posted: Fri Sep 16, 2005 12:49 pm
by infolock
this is exactly why this discussion should have stopped on page 2 (maybe page 1). This discussion has already been exhausted beyond imagination, and it's turning right back into what happend with the first one : people take comments personally, and then it just becomes a debate between 2 or 3 people with an input every now and then from a 3rd party..
Posted: Fri Sep 16, 2005 2:48 pm
by Buddha443556
Maugrim_The_Reaper wrote:Buddha443556 wrote:OOP was based on lessons learned from procedure and structural programming. OOP is the evolution of procedural and structural programming. Somewhere in OOP those ideas of past survive. It's not a question better or worse but a question of how much? How much force do you need to apply to the problem?
Evolution is a nice way of putting it. Evolution does not necessarily invalidate what came before - but is a response to environmental factors - or even competitive pressures. OOP has evolved, but its hardly a static process. I also agree that whether OOP or procedural is used depends largely on context, design goals, maintenance, complexity and other such sometimes nebulous concepts.
WOW! I actually made sense at 2AM.

Yes, even OOP is evolving and one day we'll have another topic to discuss. Won't that be a glorious day!
infolock wrote:this is exactly why this discussion should have stopped on page 2 (maybe page 1). This discussion has already been exhausted beyond imagination, and it's turning right back into what happend with the first one : people take comments personally, and then it just becomes a debate between 2 or 3 people with an input every now and then from a 3rd party..
We do seem to "exhausted" this topic every time it comes up. However, there's usually something to be learn in these topics. This time TDD has slipped in to the fray which is very interesting. Yeah, sometime we may take things a little personally. I've spent a great deal of time editing out such personal comments from my own posts. Although, admittedly I'm not perfected. Apologies all around for any of my lapses in judgment. I also think that phpdn has some of the most civil discussions IMHO on some very hot topics. For myself, I have the utmost respect for the brave soles who have dared to participate. I wish more would participate. We're all here to learn and help one another to better ourselves, aren't we? Well, I am.
Posted: Fri Sep 16, 2005 3:17 pm
by McGruff
It's a hot topic alright... Actually I think it's turned into quite a good discussion.
I do make blanket statements sometimes. I've been in the fray once too often. I also feel there's a lot of bad information about OOP around on the net and sometimes there's a need to push back against it. If I can pique anyone's interest into looking at OOP and testing that's great. Come and join the party

Posted: Fri Sep 16, 2005 3:27 pm
by Roja
infolock wrote:this is exactly why this discussion should have stopped on page 2 (maybe page 1). This discussion has already been exhausted beyond imagination, and it's turning right back into what happend with the first one : people take comments personally, and then it just becomes a debate between 2 or 3 people with an input every now and then from a 3rd party..
Thats weird.. Maybe I'm too close, but I had just the opposite feel: The first two pages were very unpleasant and pointed, with little real discussion and information.
But these last two pages, I've loaded new posts, and smiled - SMILED! Because the conversation is really discussing things that help programmers. We've covered the value of OOP, pointed out the differences in testing for procedural and OOP, explained the value of different development types.. I thought it had developed into a really useful thread.
The first few pages I wouldn't want people to read, for the most part. The last few pages? I'm pointing them out to people and suggesting them for discussions about OOP and procedural.
Maybe I can't see the forest for the trees, but honestly, it felt better, not worse, and certainly doesn't feel personal or repetitive and exhausted anymore. Am I standing around with my fly down?

Posted: Sun Sep 18, 2005 5:00 pm
by McGruff
An overview of
extreme programming. Testing is a central part of the method.
You'll notice that XP-ers talk about maintenance a lot and
performance is hardly mentioned - in marked contrast to many of these functions v classes debates. Flexible, easy to maintain code is the goal. If something really needs optimised it should be, but mere code smithing doesn't have a lot to offer, as seen in
this article.
Posted: Mon Sep 19, 2005 9:55 am
by Buddha443556
McGruff wrote:An overview of
extreme programming. Testing is a central part of the method.
You'll notice that XP-ers talk about maintenance a lot and
performance is hardly mentioned - in marked contrast to many of these functions v classes debates. Flexible, easy to maintain code is the goal. If something really needs optimised it should be, but mere code smithing doesn't have a lot to offer, as seen in
this article.
Looking at the profile for phpLens, I was amazed to see a major application with only three include()s:
Code: Select all
7.569807 7.569807 1 {include}
5.137787 5.137787 1 *showphplens
3.917065 3.917065 1 *phplens2->render
1.948146 1.948146 1 {include_once}
1.881239 1.881239 1 *phplens2->lensinit
1.469868 0.489956 3 *adodb_mysql->cacheexecute
1.394545 1.394545 1 {require_once}
1.189218 1.189218 1 *phplens2->renderview
1.171484 0.292871 4 *adodb_mysql->execute
1.158856 0.289714 4 *adodb_mysql->_execute
1.157150 0.289287 4 *adodb_mysql->_query
1.157052 0.289263 4 mysql_query
1.065000 1.065000 1 *phplenssession->setlens
1.019415 1.019415 1 *phplenssession->get
0.709840 0.709840 1 *phplens2->_joinfields
31.946472 27.483153 <<< TOTALS
7.569807 7.569807 1 {include}
1.948146 1.948146 1 {include_once}
1.394545 1.394545 1 {require_once}
10.912498 10.912498 <<< TOTALS
34% 39% <<< TOTAL % OF INCLUDE OPERATIONS
Typical FOSS has 4 times the number of includes.
However, after downloading the demo I'm somewhat skeptical. Just looking at the list of files and libraries used that three includes is anywhere near typical. I some times wonder if the emphasis on "Enterprise Programming" isn't leaving a large segment of the PHP user base out in the cold. Namely those that are on shared servers. As you say McGruff, the emphasis isn't on performance but maintenance.
Not really sure any of that has anything to do with the topic however maybe it highlights a consequence of the push towards the enterprise.
Posted: Mon Sep 19, 2005 10:40 am
by Jenk
I haven't voted because in my opinion, there is no discussion for Procedural vs OO.
It's all dependant on your requirements.
In some cases a class is much better suited than a series of functions. (It's also worth noting, that to an OOP newcomer the differences between the two are not apparent at all, a class is essentially a container of stored procedures and properties is what they see.)
If you need just a simple page that displays tablular data, for example a calendar with no interaction, then a procedural method will be more efficient.
However, for a shopping cart, that is active until a session ends, then a class will be better.
Classes are there to replicate a real life objects behaviour. As such, you have a class and you generate an object from this class. You then manipulate the object. Think of a shopping cart/trolley when you go to the store. You take a cart/trolley, you add items, you might remove items, when you have finished shopping you tally up and pay.
If you compile that in procedural, you will have some very long scripts indeed, where as with a class object, you can just call upon that specific objects stored procedures and properties.
Now back to the calendar, there quite literally is no reason to create a class for it. All you are doing is displaying data. There is no manipulation, there is no interaction, you are simply viewing it. If you were to make it fully interactive (add appointments etc.) then you may make a class for it, but even still a class for this purpose will seem to some (including me) over the top to generate an object, when all it really will be is a few lines.
The other problem we have with OOP vs Procedural debate is the background people have learnt from. Those who started with, or progressed onto Java will be OOP mad, as that is all Java does.
Others, like the god forbidden COBOL, will be procedural mad.
Posted: Fri Sep 23, 2005 11:41 am
by alvinphp
Classes or Functions, that is the question?
Classes hands down. Assuming you are using classes correctly (very big assumption) it is less code, easier to manage, easier to understand, easier to update, and so on. The only time I do not use classes is when I am making something real small (like 1 page) and for those I sometimes do not even have (or need) a function.
I always cringe when someone says they throw everything into one class or they have a 'master' class and a whole bunch of child classes. a class is your blueprint to create your object. if your object is a car you should not have a method in it to turn the lights on in your house.
Posted: Fri Sep 23, 2005 11:54 am
by feyd
alvinphp wrote:if your object is a car you should not have a method in it to turn the lights on in your house.
unless your car has HomeLink®

Posted: Fri Sep 23, 2005 12:56 pm
by McGruff
Jenk wrote:If you need just a simple page that displays tablular data, for example a calendar with no interaction, then a procedural method will be more efficient.
I'd probably employ a couple of dozen classes to do this, maybe more. A Finder, a Database object and an Iterator to pull the data. Framework code such as an application controller, various request handlers, input validation code (a whole sub system in its own right) etc, etc. Even in a simple script like this, with (I assume) little domain logic, you might see design patterns such as ChainOfResponsibility, TableDataGateway, ActiveRecord, TemplateView, and so on.
Although OOP is sometimes criticised as making things unecessarily complex, what it's really doing is taming the complexity which already exists but which might not have been understood. It makes things simpler.
It will be easier to test. Encapsulation means I can mock or stub out whole areas of the script in order to concentrate on the bits of interest (I'd probably have designed the whole thing using test driven design in the first place). Testing is going to be very important (it always is): the initial need might be to display a simple calendar but you can bet that, either on this job or the next, you're going to have to deal with more complex requirements. Perhaps dates outside the unix epoch. Different systems such as Julian calendars, Gregorian calendars, Islamic calendars. You might be asked to display happy birthday messages to visitors - recurring events. Recurring events could be daily, weekly, monthly, etc. They might have their own complex rules making the calculation of Easter day look trivial. Who knows what strange, ritual events you might have to deal with on
http://www.wicca.com (I made that up but I just checked and it really exists.. Apologies to the Celtic Connection whom I'm sure hardly ever make the milk turn sour).
As a good little extreme programmer of course I'd just ignore all that until I really have to deal with it. When you do you might start by refactoring the code to open up some new seams to mine. The tests will keep everything working then it's off to add the new features. With OOP (and polymorphism) maybe I could just drop in a Julian calendar object, directly replacing a Gregorian one. That's the kind of benefit which OOP brings. Of course you can create a functional app in procedural code but it's a pale, two-dimensional shadow in comparison to OOP.
Posted: Fri Sep 23, 2005 1:20 pm
by alvinphp
Although OOP is sometimes criticised as making things unecessarily complex, what it's really doing is taming the complexity which already exists but which might not have been understood. It makes things simpler.
Could not have said it better myself.