If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

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.

class is bigger than function

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

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.

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.)

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.

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.

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.