Page 1 of 6
Classes or Functions, that is the question?
Posted: Sun Sep 11, 2005 1:33 pm
by ttt
I have read enough to know that classes are more powerful than functions alone, but it seems like functions alone are quicker and require less code to use. I am at the point where I now want to make my code modular in order to use the same functions in many projects. Everyone says that "classes are more modular", but I have to say, I really don't see an advantage to including a script with a classes instead of a script with a few functions on it.
So when/why is it best to write classes instead of functions for repeated use?
Posted: Sun Sep 11, 2005 1:57 pm
by feyd
this is a really good discussion of when and when not to use a class.
Re: Classes or Functions, that is the question?
Posted: Sun Sep 11, 2005 2:01 pm
by Roja
ttt wrote:So when/why is it best to write classes instead of functions for repeated use?
This question is a holy war topic, so be prepared for a wide variety of answers.
I'll give my stock answer: Classes are good when the process the code works on has a strong relationship to the data. If there isn't a strong relationship between the processing and the data, I would use a function.
Now, a fair number of people will simply say that if there isn't that relationship, you should redesign until there is. I completely disagree. There are more than a few places where you'll be doing a simple function (my classic example is validating an email address), and it just doesn't make sense (to me) to build a full class and object structure around that simple task.
Most of my hobby work is done on legacy code, so I am biased. I enjoy migrating legacy code to be more modern - while keeping it functional. As a result, I have a strong appreciation for the value of solid functions that aren't overly complex or abstract. On the flip side, most of the work I do in my day job on php is brand new, and is heavily OOP. So I can see the value of OOP and classes, its just not realistic in some situations.
Anyways, thats my simplified answer: Wherever there is a strong relationship between data and processing, I use classes. For everything else, I use functions.
Re: Classes or Functions, that is the question?
Posted: Sun Sep 11, 2005 2:19 pm
by feyd
Roja wrote:Anyways, thats my simplified answer: Wherever there is a strong relationship between data and processing, I use classes. For everything else, I use functions.
I'd like to add "...or where any of the four pillars of OOP can be used (abstraction, encapsulation, inheritance, and polymorphism)"
Thanks
Posted: Sun Sep 11, 2005 2:58 pm
by ttt
This is something that I've put off for a while, because I've never known how to use classes. I am frustrated with the lack of organization and 'spagetti' tendencies in my code as projects get bigger.
Thank you both for your replies. Roja, I appreciate your candid explanation. That is exactly what I was looking for. I will keep my simple e-mail verification -type functions alone, and for the more data oriented tasks like retrieving and organizing mySQL data, I'll put those functions in classes. feyd, I will also learn about the four pillars of OOP. Thanks again.
Posted: Sun Sep 11, 2005 3:07 pm
by McGruff
In the link Feyd gave above (second post) some of my irritation at the endless OOP v procedural debate was definitely showing through. I hate to see people being misled -
sometimes one side can be wrong.
It's not just OOP though: I think the combination of OOP and (unit etc) testing is particularly powerful. Of course you can test functions but I'm not sure what the procedural equivalent of
test driven design would be.
Php is the kind of language where people sometimes just want to get a job done. They might not have the aim of learning how to program as best they can. If you do, OOP and testing is the way to go.
Posted: Sun Sep 11, 2005 3:48 pm
by Roja
McGruff wrote:Php is the kind of language where people sometimes just want to get a job done. They might not have the aim of learning how to program as best they can. If you do, OOP and testing is the way to go.
Please do not yet again infer that anyone that disagrees with you is either wrong or incapable of learning how to program the best they can.
Thats the mistake you've made multiple times, and I will once again quote the rules of the forum to you: Respect the opinions of others.
Posted: Sun Sep 11, 2005 4:04 pm
by patrikG
Roja wrote:McGruff wrote:Php is the kind of language where people sometimes just want to get a job done. They might not have the aim of learning how to program as best they can. If you do, OOP and testing is the way to go.
Please do not yet again infer that anyone that disagrees with you is either wrong or incapable of learning how to program the best they can.
Thats the mistake you've made multiple times, and I will once again quote the rules of the forum to you: Respect the opinions of others.
We really do not want to boil this particular kettle yet again, or do we?
Posted: Sun Sep 11, 2005 4:06 pm
by McGruff
Roja: I have to respect the truth first. My belief is that there really is nothing to debate, but much to learn so that's the opinion which I express. The intelligent design article above shows a good example of an idea which simply does not stand up to scrutiny.
Posted: Sun Sep 11, 2005 4:22 pm
by Roja
patrikG wrote:We really do not want to boil this particular kettle yet again, or do we?
No, I really don't, but I will not be called uninformed, unintelligent, or wrong solely on the basis of disagreeing. That the mods continue to allow such comments flies in the face of the rules of these forums, and *only* occurs for McGruff.
That inequity is unacceptable to me, and yes, if it means reboiling that kettle, I'll take the fire yet again. I am only baffled that the mods won't.
McGruff wrote:My belief is that there really is nothing to debate, but much to learn so that's the opinion which I express
And in other threads, we've already posted dozens of notable computer scientists - including authors of PHP itself - who directly disagree with your opinion. Since there are dissenting points of view, your rigidity and unwillingness to consider those alternative viewpoints has little to do with truth.
If I stood alone in my view that OOP was not the only way, I would gladly bow out. Since I am not remotely alone in that viewpoint, I highly suggest allowing others to express their point of view without implying that they are less knowledgable than you purely because they disagree.
If for no other reason than the forum rules require it.
Posted: Sun Sep 11, 2005 5:06 pm
by McGruff
I can say, respectfully, that someone is wrong if I disagree with them.
My whole point is that this whole debate is like arguing the earth is flat. As long as I do have some responsibility for these forums, I intend to speak out for some basic intellectual standards. No one will be belittled or humiliated but you might, if willing, be educated. That's what we're here for.
However, this is veering off topic rather. You can start a new one if you like. You can even launch a poll to see what other members think. If it really was the case that I didn't have the confidence of our members I should not continue in my position.
Posted: Sun Sep 11, 2005 5:58 pm
by patrikG
Topic locked.
A final remark: I have not locked this to stifle discussion, but to avoid repeating what has happend on a number of occassions: personal attacks leading to a flamewar which alll sides involved regret.
Let me make a couple of things very clear:
1. everyone using this forum is bound by the forum rules. There are no special exceptions, not for mods, site admins nor anyone else. We have recently removed a moderator who violated the forum rules.
2. The forum rules came about because of one of these aforementioned flamewars.
3. If anyone has complaints about the demeanour of a member, moderator or site admin - do contact one of the moderators who is not involved.
4. I have so far seen no violation of the forum rules on this thread, but jugding from experience, this is fairly imminent were this discussion to continue.
If anyone wishes to pursue this further, please see point 3.
[edit] the thread had been locked temporarily to allow everyone enough time to get back to the original question asked.
Posted: Mon Sep 12, 2005 4:10 pm
by patrikG
this post was submitted by aborint
ttt wrote:I have read enough to know that classes are more powerful than functions alone, but it seems like functions alone are quicker and require less code to use. I am at the point where I now want to make my code modular in order to use the same functions in many projects. Everyone says that "classes are more modular", but I have to say, I really don't see an advantage to including a script with a classes instead of a script with a few functions on it.
So when/why is it best to write classes instead of functions for repeated use?
Well, now that you have heard the tenor of those with strong feelings about this subject as well as those weary of it, I would like to point out that there is really not a debate here. Structured Programming and OOP are ways to design software. There is a lot of overlap and there are some language contructs that these two movements brought to modern languages.
Let me make some probably unhelpful comments about the sentences you wrote:
ttt wrote:I have read enough to know that classes are more powerful than functions alone, but it seems like functions alone are quicker and require less code to use.
You have read that "classes are more powerful than functions alone" but you feel like "functions alone are quicker and require less code to use." So you have a struggle between the opinions of possibly smart and experienced people saying one thing and your own intuition/experience saying another. Your problem is that you can't really trust either. Writers are biased and you are not experienced enough to know how important "quicker and require less code to use" is as you software design abilities increase.
ttt wrote:I am at the point where I now want to make my code modular in order to use the same functions in many projects.
Ok, so you have a need. You might want to lookup "Modular Programming" (
http://en.wikipedia.org/wiki/Modularity_(programming)) because creating modules is an important concept in software design. It can be done in Structured Programming and is implicit in OOP classes. It is important to note that it can be done well or poorly in either approach.
ttt wrote:Everyone says that "classes are more modular", but I have to say, I really don't see an advantage to including a script with a classes instead of a script with a few functions on it.
Again you have this disconnnect between what others see from their vantage point versus what you see from yours. So my question you you is, are you saying "I really don't see an advantage but I think there is one and I want to see it too" OR "I really don't see an advantage and I don't really think there is one, so would someone confirm that what I am doing now is ok". The problem is that you got both answers.
I should note that if all you are looking for is to create "modules," then classes are little more than namespaces in PHP. Classes provide many advantages, but namespacing is not really one of them.
ttt wrote:So when/why is it best to write classes instead of functions for repeated use?
I think what you are really asking here is "when/why is it best to build classes instead of modules of functions for repeated use?" The answer unfortunately is neither. If you are designing using Structured Programming then modules of functions is how you do it; if you are designing using OOP then classes is how you do it.
Which leads to the real question here: should I do my software design using Structured Programming or OOP principles?
And this gets back to your problem: you know how to design using Structured Programming but not with OOP. Yet when you read you notice that there is a lot about OOP design, but very little anymore about Structured Programming. (A quick search at Amazon shows that there hasn't been much written on Structured Programming in the last five years).
So let's leap over the McGruff vs Roja squabble (heck I've even argued with McGruff on this point!

) and throw the questions back to you:
- What kind of design principles do you think you are going to need?
- Are you happy with your current design principles?
- Are they solving your problems well?
- Or are you looking for new ideas to use to design your software?
Posted: Mon Sep 12, 2005 4:21 pm
by infolock
Though I'm one who likes to disagree, I would have to agree this topic has already been exhausted to its max. What it comes down to is preference of usage. If you prefer to use functions and include files, then go ahead. If you prefer OOP, do that instead. Either way, php is not exactly an OOP language, although it supports *some* OOP styles, and on the flip side, the functionality you get with the new OOP styles php 5 has introduced may make you want to use classes instead when scripting with php.
Basically, it's your choice. So choose already!

Posted: Mon Sep 12, 2005 5:05 pm
by nielsene
I don't believe its an either/or situation. A programmer needed to be skilled on both, unless you never plan to collaborate or change jobs. There are enough applications out there that people are likely to work on in some point in the their coding career, that they'll need to be able to work effectively on applications which are procedural, or OOP, or some other permutation of those concepts.
I'll agree that OOP is the current industry best practice and its what you need to learn, if you don't already know it. However, that's not to say you need to re-code all your existing applications and I would strongly advise against suggesting that third-party open source projects change from procedural to OOP (or vice versa) unless you have a LOT of experience as a developer on that project. Furthermore if you're learning OOP, its generally MUCH easier to start on a small, but "rich" application from scratch than to try to adopt an existing application while you are learning.
There is a lot of old C code (and Fortran, COBOL, etc) and its procedural. If you ever want to "hack" around in the Linux kernal or in the innards of say PostGreSQL, you'll need to be comfortable with huge procedural applications.
Its also important to remember that Computer Science/Engineering is still a young field and best practices evolve. There's a ton of "new" techniques/methodolgies hitting that are starting to hit the mainstream. TDD is starting a boom; then theirs Aspect Oriented Programming, Responsibility Driven Design, etc. Most of these either work best with, or modify slightly, the standard OOP paradigm. However, sometimes ramifications appear later that cause a change in perspective -- for instance OOP started out very inheritence happy, but has shifted to a compositional approach, etc.
Understand the current best practices, follow the emerging trends, and make your own decisions -- but make them from a position of knowledge and experience (and the experience is the tough part -- it can take upto a year of solid working in a given method to really start to grok it)