OO PHP static keyword, should I use it?

I’m writing script for fb and I have 3 objects that I’ll be using through all classes. I’m wondering if there is any advantage in using the static keyword except I don’t have to create an instance every time I need to use a method/object? Which way should I go, with static or without it?

I know this is basic, but I’m new to OOP and I want to learn to use it in a proper manner.

Your question is a little vague so I’ll try my best.

There’s one good question to ask when you’re trying to choose between creating a static or an instance method.

Do you need to persistent state between method calls?

Static methods are no different than traditional procedural functions. You give it an input and it should consistently product an output based on the input that is completely side-effect free.

Basically, you could use a traditional function declaration in it’s place with no difference. The only benefit is that static methods are attached to a namespace where traditional functions are defined in the global namespace.

They don’t matter so much in PHP because the language mixes both procedural and OOP styles but in languages that are pure OOP (ex C#/Java) there is no way to define functions so static methods are used in their place.

Static methods are perfectly acceptable to use when you’re defining helper methods that act in a stateless manner. If you need data persistence between calls and/or find yourself relying on global variables, don’t; use objects/instances instead.

Update:

Tom B made a very good point about unit testing. That static methods (like procedural functions) are inherently decoupled from the classes that they’re attached to. So, if a static method fails, it may also cause any other instance method it’s called in to also fail. It’s a classic example of a side-effect.

That explains why I have encountered so many people parroting ‘static methods are bad, mmmkay’ in the TDD community. They have a completely valid point.

There are ways this could be improved. In the language, throwing an implicit exception when static methods fail. Technically, it wouldn’t be any messier than doing type conversions. Assume it’s going to break something if it fails. Of course, that assumes a higher degree of understanding to implement.

Either way, it comes down to the simple question.

Do you limit the language you use, or limit the ability to test your code’s consistency?

My personal bias is toward expressiveness, the TDD school of thought’s bias is toward consistency. YMMV.

I look forward to many years of religious wars over this topic.

In short: No. Static methods are generally considered bad practice. They introduce a lot of potential issues. They are a way of shoehorning procedural code into OOP.

They introduce hidden dependencies. Code which arbitrarily calls foo::bar() has a dependency on foo and cannot run without foo being defined. In this instance, the object using foo::bar() will construct correctly but won’t be usable if foo is not defined. It will only break at the point foo::bar() is called. If a $foo instance was passed into the object’s constructor then the object could never even construct without it’s dependencies. This creates far more robust code.
Statics are globals. Global state is very bad, anything can change the code and its state is unknown. You sacrifice the power and control achieved by OOP encapsulation by using static methods.
It’s impossible to substitute the functions for a different version. In the foo::bar() example, you sacrifice all the power polymorphism enables you in OOP by using static methods.
It makes unit testing impossible. For unit testing, you need to be able to substitute dependencies for mocks. Using static methods makes this far more difficult.
Are you sure you only want a single instance? Imagine if you had a class that created an FTP connection and allowed a simple API for creating files. Just calling FTP::upload($file); would be quite clean wouldn’t it? The problem is, once the requirements change to “can the file now be uploaded to the backup server as well.” then you have a problem: there’s no way to connect to two different servers at once.

Static methods should be avoided as a matter of course. From an OOP perspective, there is no reason they should ever be chosen over an object with a method.

I’m a bit confused by your question.
You have three objects: Instantiate them and pass them around by reference. You need three instances, use three instances, assuming that they are not modified do not need to be cloned etc. Alternatively check singleton pattern.

Static keyword: https://stackoverflow.com/questions/413898/what-does-the-static-keyword-do-in-java. It is exactly the same in PHP as in JAva snd elsewhere: you need it specific for the class, then it’s static. Why has to do with maintenance, performance and other factors.

New to OOP: takes time, do not worry.

Filed under: softwareengineering - @ 13:46

Thẻ: object-oriented, php, static-keyword, static-methods

Thiết kế website giá rẻ

Danh mục

OO PHP static keyword, should I use it?