Classes Vs Functions

[johnsmith153]

I understand classes (or how to write them anyway), functions and a very good level of PHP. However, I often see people confused over when to use functions over classes. For me, use a function unless there is a good reason to use a class. Many (semi-programmers or below) seem to use only functions (because they don't understand classes) or mainly classes (because they think they have to).

 

I have produced a quick-reference guide (for myself) to help me decide whether I should use a function or a class.

 

The question is: am I right? is this the right way to approach classes?

 

Use a class when...

(1) You need to remember something in a function (for example how many times you've executed that function in that script or feel variables in the function would be better 'memorised' for other executions of that function during that script).

(2) To group data together, e.g. if you return user data from a database and then update it various times in the script. (If you find you're using lots of arrays to store data that is updated during the script execution then a class may be better).

(3) To group together an entire part of the system (user login, database access etc.)

(4) Use a static class on occasions when you have a few functions that can be grouped together and will only be used a few times on your site (rather than putting them all in a file of all functions that is included on every page).

(5) If someone wants to group together pieces of code and distribute as a read-made solution (like on phpclasses.org) - maybe even if it's just a group of functions (e.g. a complete date/time manipulation class would probably just be a few functions together).

 

If the requirement doesn't fit with the 5 points above then use a function.

 

I always use an MVC design so code would not be unnecessarily duplicated regardless of if I used functions or classes.

[Yucky]

You're correct in some respects. A class is an OO paradigm that allows you to organise your code by grouping related functions.

 

You seem a bit confused as to what a class is for though. It's not a case of classes vs functions as one is not a substitute for the other. They both serve entirely different purposes.

 

If you're going to use OO then follow it through and stick with it. Don't switch between procedural and OO coding styles in one program.

[johnsmith153]

"If you're going to use OO then follow it through and stick with it. Don't switch between procedural and OO coding styles in one program."

 

I do want to use OO and I do want to follow it thorugh completely. I am concerned that I may use classes too much though.

 

I don't think you are saying put everything in a class (and use methods) (and forget sole functions), are you?

 

If I needed to create a very basic piece of code to say return a currency amount from a number, surely that would be in its own function - never a class?? (unless it was linked to a bigger section of code where to group it all together may be of benefit).

 

Am I wrong?

 

I would appreciate others' input also, I am looking to have some sort of checklist of a few points I can refer to so I can ensure when coding I am using a function when I should and classes when I should. Can someone confirm or adjust my 5 points?

 

My concern is people tell me to load and execute a class can take PHP longer (only if the class is for basic processing of course as if the class did a load of things then of course it would be worth it).

 

Thanks again.

[KevinM1]

I do want to use OO and I do want to follow it thorugh completely. I am concerned that I may use classes too much though.

 

Then you don't really understand OOP.  The currency of OOP is objects, which are instances of a class.  You're supposed to have a lot of objects.

 

I don't think you are saying put everything in a class (and use methods) (and forget sole functions), are you?

 

If I needed to create a very basic piece of code to say return a currency amount from a number, surely that would be in its own function - never a class?? (unless it was linked to a bigger section of code where to group it all together may be of benefit).

 

Well, like you say, your hypothetical currency code will be part of a larger section....

 

Using classes to simply group together similar methods is NOT OOP.  All you're doing is creating custom data types and using them procedurally.  It's not much different than having library files filled with functions.  The bulk of OOP is objects communicating with each other, containing references to one another, and using each other to do work.

 

Am I wrong?

 

Yes.  You should look at design patterns to get a good idea of how OOP differs from procedural programming.  Wrapping things in a class and calling it a day isn't legit.

 

My concern is people tell me to load and execute a class can take PHP longer (only if the class is for basic processing of course as if the class did a load of things then of course it would be worth it).

 

Don't worry about optimization at the beginning.  Create your system first, test it, then trim where necessary.

[johnsmith153]

Thanks for the response.

 

Well, like you say, your hypothetical currency code will be part of a larger section"

 

Imagine if the currency code was used quite a few times. Putting it in say 4 classes would be duplicating. If I put it in one standalone function then these classes can use it as they need (can't they?)

 

Surely there must be a need for a standalone function on some occasions - even in full OOP designs?

[KevinM1]

Thanks for the response.

 

Well, like you say, your hypothetical currency code will be part of a larger section"

 

Imagine if the currency code was used quite a few times. Putting it in say 4 classes would be duplicating. If I put it in one standalone function then these classes can use it as they need (can't they?)

 

Surely there must be a need for a standalone function on some occasions - even in full OOP designs?

 

Why would you need to put currency code in 4 classes to begin with?  Properly designed code (forget about OOP for a moment) follows the DRY principle - Don't Repeat Yourself.

[Yucky]

To paraphrase the above, a large part of writing OO programs is about developing code that allows for easy reuse. This means writing code that's as generic as possible so it can be easily ported and used again. Additionally, although you should keep performance in mind to an extent, unless it's a performance critical application, write the code first to the best of your ability and then look to optimise it further. Don't optimise it prematurely.

 

Imagine if the currency code was used quite a few times. Putting it in say 4 classes would be duplicating. If I put it in one standalone function then these classes can use it as they need (can't they?)

 

If you're considering pasting the same function into multiple classes then you've gone wrong somewhere down the line. I'd suggest reading up on OO and getting to grips with the principles and then moving to classes and objects.

 

Surely there must be a need for a standalone function on some occasions - even in full OOP designs?

 

If I have a small function that doesn't fit in any class and doesn't merit its own, I'll usually put it in a general purpose utilities/misc class.

[KevinM1]

If I have a small function that doesn't fit in any class and doesn't merit its own, I'll usually put it in a general purpose utilities/misc class.

 

Even better if the methods are static, as you probably wouldn't have to worry about maintaining state in most cases.

[Yucky]

If I have a small function that doesn't fit in any class and doesn't merit its own, I'll usually put it in a general purpose utilities/misc class.

 

Even better if the methods are static, as you probably wouldn't have to worry about maintaining state in most cases.

 

Indeed, I make them static.

[phpSensei]

You're correct in some respects. A class is an OO paradigm that allows you to organise your code by grouping related functions.

 

You seem a bit confused as to what a class is for though. It's not a case of classes vs functions as one is not a substitute for the other. They both serve entirely different purposes.

 

If you're going to use OO then follow it through and stick with it. Don't switch between procedural and OO coding styles in one program.

 

I think you have it wrong also. using OO in php doesn't mean writing a class for everything you do, it would be more of a time consuming process then just plain old simply functions.

[Yucky]

You're correct in some respects. A class is an OO paradigm that allows you to organise your code by grouping related functions.

 

You seem a bit confused as to what a class is for though. It's not a case of classes vs functions as one is not a substitute for the other. They both serve entirely different purposes.

 

If you're going to use OO then follow it through and stick with it. Don't switch between procedural and OO coding styles in one program.

 

I think you have it wrong also. using OO in php doesn't mean writing a class for everything you do, it would be more of a time consuming process then just plain old simply functions.

 

I don't believe mixing programming paradigms in such a fashion is good style. If you're going to use OOP, stick to it throughout. I didn't advocate writing a class for every function that didn't fall nicely into an existing class. Having a utilities/misc class with static functions seems like an acceptable solution.

 

I'm more than open to arguments in favour of switching between procedural and OO though.

[phpSensei]

You're correct in some respects. A class is an OO paradigm that allows you to organise your code by grouping related functions.

 

You seem a bit confused as to what a class is for though. It's not a case of classes vs functions as one is not a substitute for the other. They both serve entirely different purposes.

 

If you're going to use OO then follow it through and stick with it. Don't switch between procedural and OO coding styles in one program.

 

I think you have it wrong also. using OO in php doesn't mean writing a class for everything you do, it would be more of a time consuming process then just plain old simply functions.

 

I don't believe mixing programming paradigms in such a fashion is good style. If you're going to use OOP, stick to it throughout. I didn't advocate writing a class for every function that didn't fall nicely into an existing class. Having a utilities/misc class with static functions seems like an acceptable solution.

 

I'm more than open to arguments in favour of switching between procedural and OO though.

 

 

I can see why it wouldn't be something fasionable mixing with frameworks/mvc/design patterns, but I think if you are just doing classes not following any of the paradigms, there is no problem adding procedural coding.