Sometimes a more standard, procedural approach with functions is better. However, there are cases where an OOP approach would be better since it make possible to solve the problem with less code and efforts.
A good way to learn it, is to first understand the php class syntax basics and after put your hand in an available php OO project and figure out the logic behind.
In this case we have apples, oranges and bananas - and that really is what we want - PHP Fruit Salad, so we can get the job done as efficiently as possible!
hello,
you're wondering which one is better
it's complicated because you can't tell which one is better but you can clearly see class is bigger than function.
function is a part of class
class can contain function but function can't hold a class.
so in my opinion class would be better for more functions codes
thank you
There is no "better", they both serve different purposes.
This is the best answer I've seen in this thread. You can't just decide between using classes or doing things procedurally. Once you examine you code and you find that you are able to group similar functions together, then do so by using classes. There are some circumstances where separate functions just don't group together logically into a class, although there are lots of circumstances where they do.
The most important thing to learn is not how to build classes or code procedurally, it's to recognize what code that can AND should be grouped into a class.
I've switched careers...
I'm NO LONGER a scientist,
but now a web developer...
awesome.
This is the best answer I've seen in this thread. You can't just decide between using classes or doing things procedurally. Once you examine you code and you find that you are able to group similar functions together, then do so by using classes. There are some circumstances where separate functions just don't group together logically into a class, although there are lots of circumstances where they do.
The most important thing to learn is not how to build classes or code procedurally, it's to recognize what code that can AND should be grouped into a class.
While I suspect it's not exactly what you mean, upon reading that, one might assume you are describing a bottom-up approach: determining what functions are needed, and then delegating those functions to classes as a sort of afterthought.
For truly effective object-oriented implementation, you want to start from the top: determining what objects are needed to model the functional requirements, and then deciding what properties and methods are needed for the classes that define those objects. (In reality, you can't help but think of some of the functions/methods you'll need, and that will help you determine what objects will be needed; but you still want to emphasize a top-down view, at least during the design phase, IMO.)
"Please give us a simple answer, so that we don't have to think, because if we think, we might find answers that don't fit the way we want the world to be."
~ Terry Pratchett in Nation
In OOA&D(Object Oriented Analysis and Design) class I was taught to use the crud matrix (http://www.databaseanswers.org/data_...rud_matrix.htm) to help identify re-usable code and classify it. If it could be conceptually classified then it usually made sense to classify it in code.
In my mission to learn OOD I have gone over board trying to put everything in classes so it might be time to go back to using a crud matrix.
In OOA&D(Object Oriented Analysis and Design) class I was taught to use the crud matrix (http://www.databaseanswers.org/data_...rud_matrix.htm) to help identify re-usable code and classify it. If it could be conceptually classified then it usually made sense to classify it in code.
In my mission to learn OOD I have gone over board trying to put everything in classes so it might be time to go back to using a crud matrix.
You could pretend you are using an OO-only language (e.g. Java) where everything has to go into a class (although people often "cheat" and create classes that are merely containers for procedural code). Of course, with PHP, you always have to have at least a few lines of code that are not part of a class in order to load and instantiate the "main" class.
"Please give us a simple answer, so that we don't have to think, because if we think, we might find answers that don't fit the way we want the world to be."
~ Terry Pratchett in Nation
While I suspect it's not exactly what you mean, upon reading that, one might assume you are describing a bottom-up approach: determining what functions are needed, and then delegating those functions to classes as a sort of afterthought.
For truly effective object-oriented implementation, you want to start from the top: determining what objects are needed to model the functional requirements, and then deciding what properties and methods are needed for the classes that define those objects. (In reality, you can't help but think of some of the functions/methods you'll need, and that will help you determine what objects will be needed; but you still want to emphasize a top-down view, at least during the design phase, IMO.)
Thanks for pointing that out....can't help but to love learning new things like this.
I've switched careers...
I'm NO LONGER a scientist,
but now a web developer...
awesome.
In general I agree that neither is necessarily "better", but I strongly recommend that you lean OOAD/OOP in order to improve your overall programming skills and toolkit.
"Please give us a simple answer, so that we don't have to think, because if we think, we might find answers that don't fit the way we want the world to be."
~ Terry Pratchett in Nation
I'd have to say conceptually classes are better in all situations because they categorize and delegate functionality. But then again in some cases it might be a lot easier and faster to write a couple of simple functions rather than have a separate class. In cases like that it's not like you don't have to write the function inside the class so it actually ends up saving you some coding to just put the functions in the script where they are needed. Still, grouping everything into classes makes the logic much more logical to me.
As far as the link you posted not having much useful, I think it has plenty of useful things if your an expert programmer but not for me. php.net is more documentation than learning material. Once I get into more intermediate and advanced topics nothing there makes any sense to me no matter how many times I read up on the concepts. The site is seriously lacking in good instruction.
actually i don't see any reason to use classes. you can do ABSOLUTELY the same with plain functions. if you want it to be more organized, you can group them into separate files and then include() them depending on the situation... please correct me if i'm wrong... i've googled a lot but i haven't found anything useful about that...
actually i don't see any reason to use classes. you can do ABSOLUTELY the same with plain functions.
Also, you can do absolutely the same with C as you can with PHP, so there's no reason to use PHP, right? But we do use PHP, and we do use classes, because both come with benefits.
OOP emphasizes modularity, where you pass around not just raw data, but also the code that operates on that data, so that the data itself can stay encapsulated and hidden from the larger scope of the application. OOP makes it easier to reuse code with features such as inheritance. Inheritance lets us delegate some work to the compiler that we would otherwise have to do manually in a procedural language. OOP also gives us more tools for "designing-by-contract," such as interfaces.
Reply With Quote
Originally Posted by Mindzai
Bookmarks