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.


3 Answers 3


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.


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.

  • To add a little bit more regarding TDD: it's not so much that the static method may fail, it's that the static method may contain a bug. If it's giving the wrong output for a given input then the code being tested may work perfectly but give inconsistent results. Debugging this becomes more difficult because you need to trace the execution to where the bug is occurring. In TDD this is avoided by testing pieces of code in complete isolation, if the test fails then the developer should know instantly which lines of code to debug without having to trace the execution.
    – Tom B
    Dec 13, 2012 at 10:09

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.

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

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

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

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

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

  • 1
    -1 For #1, static methods don't work via a constructor, unless it's a static constructor (ie compile-time) constructor. #2 static methods aren't globals, as they're attacked to a particular namespace (ie the class). #3 Polymorphism doesn't apply to static methods because they don't persist state between calls. #4 Not true, if anything static methods are easier to test because you don't need any initial object construction; just basic input/output matching. #5 You present a use case where using an instance would be better, I agree but that's why there are static and instance methods. Dec 11, 2012 at 21:28
  • 2
    Static methods ARE globals. They have a global state. Anything anywhere can make a call to x::y(), this is global. A call to a static method will invariably have global state. This problem is increased by an order of magnitude every time a static method has a dependency because those dependencies also need to be accessible statically putting any dependencies in global space.
    – Tom B
    Dec 11, 2012 at 23:27
  • 2
    You should avoid static calls because they create unknown dependencies. This was my #1 point and for a reason: There's no avoiding this, it results in code which isn't portable and is tied to a very specific implementation. See: misko.hevery.com/2008/12/15/… for more information. All my points are valid and you haven't rebutted them at all. Tell me, why should static methods be used? You haven't explained this whereas my reasons for avoiding them are well documented.
    – Tom B
    Dec 11, 2012 at 23:29
  • 2
    The only time static calls do not introduce problems is when they're declared private and well documented for very specific reasons such as file-locking and connection throttling which are limited by external forces, however the original question was regarding general use-cases .
    – Tom B
    Dec 11, 2012 at 23:34
  • 2
    Polymorphism not applying to static calls is precisely the problem. It locks client code into a VERY specific implementation this is inherently untestable because you're testing the static method at the same time as the client code.
    – Tom B
    Dec 11, 2012 at 23:40

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.