Classes or Functions, that is the question?
Moderator: General Moderators
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..
- Buddha443556
- Forum Regular
- Posts: 873
- Joined: Fri Mar 19, 2004 1:51 pm
WOW! I actually made sense at 2AM.Maugrim_The_Reaper wrote: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.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?
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.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..
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
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
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.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..
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?
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.
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.
- Buddha443556
- Forum Regular
- Posts: 873
- Joined: Fri Mar 19, 2004 1:51 pm
Looking at the profile for phpLens, I was amazed to see a major application with only three include()s: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.
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.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.
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.
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.
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.Classes or Functions, that is the question?
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.
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.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.
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.