When should we use class and when we should not

Classes are useful and all, but when I'm writing a class I always think about it as an heavy rock on my script. I feel like classes should rarely be used. But at the same time we are all mindshelled with the OOP paradigm.

Should a script n开发者_如何学编程ever have free functions? Should I use thousand classes just to make the script more clean? And what about performances? Does class::method() require so much more time then a simple function()? What is the really meaning of OOP? I'm a bit confused.

Since I discovered OOP, I cannot see random functions. I'm obsessed. I cannot see functions that has no parent class. I rather create a class with just a method then see that function all alone. Is it right? Are there examples of pure OOP CMSes out there?

The most important thing for a programmer in PHP, in my opinion, other than his experience is his toolkit. That is, code that he/she has written inside and out, backwards and forwards since time immemorial.

To me, in this instance, the advantage of OOP in clear. Having a class that you know will always preform what you want through simple methods is much easier for both yourself and team members, then it is by just calling a multitude of static functions. While you could argue a library of satic function includes serves the same purpose, in my opinion classes are much easier to read and understand. For example, in my custom session class a programmer can look at my code and see,

$my_session = new session();
$my_session->start();

if ( ($session_errno = $my_session->error()) !== FALSE)
{
   //DO SOMETHING BECAUSE OF A SESSION ERROR
}

and easily understand that sessions in this application are handled via our custom session class, and should return some type of success/failure without having ever examined the library/class. Meanwhile, a call such as this,

session_start();

if (session_error())
{
   //DO SOMETHING BECAUSE OF A SESSION ERROR
}

does not make it clear that session_start() is not a default PHP session handler, but that it will call the functions defined in session_set_save_handler() which was included in some mega list of global includes that might not be easily to locate in a large application. It is also not as clear that session_error() is a function that returns an error set by the custom session handler, vs a function that may actively look for session issues on an already generated session and is completely independent of PHP's default session.

This is not a great example, but I think it is a good one. I did not go into detail on the goodness that is protecting data from the application at whole, inheritance, and everything else that makes OOP useful.

But quickly, imagine a class that accesses an application's MYSQL database. A lot of time is spent designing the class to use prepared statements, log errors and provide proper logic to the programmer as needed. A team can worry less about database access issues by simply calling the class's public 'data access' functions without much concern about fatal errors, bad logic or dangerous SQL (injections and such).

This can all be done with static functions like you suggest, BUT every function in that static library is exposed to the application as a whole, while only the public and 'SAFE' functions are exposed to the application that uses a database access object. The programmer can not accidentally call a dangerous function that if not properly initialized by other functions could cause major issues, nor could the programmer deliberately suppress errors or other data protected by the class like they could with a slew of static functions and global variables.

While a good application can be designed without any objects, a good programmer should enjoy the usability, extensibility, and protections that objects afford when appropriate.

I'll leave with my final metaphor. Objects are like specialized machines and tools inside a factory. While the factory itself has a number of these unique tools on its assembly line, everything from simple bending brakes to CNC machines and automated robots, they are only a small part of the team that exists to help the more numerous laborers and managers, our static functions, do the job of building a better car, truck, or bike.

Do use OOP:

• to have logical representations of both stateful and stateless "things" that may be manipulated, have attributes, or be used in a variety of ways
• because you see the benefit in data encapsulation
• because you get that a Tacoma is a Toyota is a PassengerVehicle is a Vehicle
• because you want to provide people who will develop with this class easy to use interfaces

Do not use OOP:

• just to group a seemingly related set of functions together
• just because someone here says you should
• if you think it will make your boss happy
• until you've at least looked over the Gang of Four's design patterns - the benefits become more clear

I think you have some bad vision of OOP programming because you don't do it never. Quake 3 is writed using pure C without any class and OOP, then this is a proof to you can do good things without using OOP.

But if you want you can use it. Inheritance in classes have a small functionality in practice business logic programming, much better in frameworks programming.

If you decide to programming with OOP then write small objects with small functions who doing small things, not big non readable classes with long don't intuitive functions, then you will stay clean in your code.

Have a look at this:

Classes are little more than a container for variables and functions affecting those variables, but they can be very useful for building small components - almost miniture programs. The difference is that you dont need to shell out to them and they can be plugged into most scripts with ease - Just a require or include statement at the top. A class describes an 'object'. An object is a collection of smaller objects, just like in a class.

Reference

If you think of your objects as heavy rocks, that could be a good thing. Since php isn't very oop by nature (except some default extensions), there's procedural functions enough, about 6000, isn't it?

I'd encourage you to continue with OOP. Hundreds of classes seems overdone though. For starters, put all you need in one object, and split to subclasses when appropriate.

There is no simple answer to this.

While in general you should stick to either a functional or OO approach, one of the nice things about PHP compared with, say Java, is that it does allow functions as first-class entities.

The most important thing to remember is that you write programs in a language and style which makes them readable by human beings! The fact that the computer can parse them is pretty much coincidental.

Certainly the overhead of calling a static method vs a function should not be a consideration - and you are definitely guilty of premature optimization. If you're concerned about this why don't you measure it for yourself? You'll find that while it is slower, the difference is very small - and should not override the primary objectives when writing code (i.e. it should work, it should be as clear as possible how it works, it shouldn't have any side-effects).