Static methods --- Poor OOP practices?

Lord_Yggdrasill

Well I've heard many times in both PHP and Java world that Static Methods are not good design. In PHP they can just be a regular function defined outside of the scope of class, and they are not really true OOP. What do you think? Is Static methods poor OOP practices? If so, what can we do to prevent using too many static methods in a class? Dependency injection?

Reference:
http://r.je/static-methods-bad-practice.html

bradgrafelman

Lord Yggdrasill;11013153 wrote:
Well I've heard many times in both PHP and Java world that Static Methods are not good design.

I've also heard many times that green isn't as good of a color as blue. That hasn't changed the fact that green is my favorite color, though.

Sarcastic banter aside, I really think there's enough justification for the use of static methods to prevent someone from categorically denouncing them. In fact, one justification for their use can actually be found in the blog entry you linked:

Tom Butler wrote:
db::query() is functionally identical to db_query(). A global function. Which is all static methods are, namespaced global functions.

Exactly - they're "namespaced." If you happened upon a bit of code that contained db_query(), you might not know whether this was some local function or not. However, if you saw "db::query()" instead, you'd assume that you can find everything you want to know about what that query() static method is returning by referencing the 'db' class.

Why pollute the global namespace with functions and variables that don't belong there but can more appropriately be grouped together as static members of a class?

Lord Yggdrasill;11013153 wrote:
Is Static methods poor OOP practices?

In my opinion, not always, no. For example, one ideal candidate for the use of static methods would be in a Factory pattern.

Can static methods be stripped from the OOP world and instead shoved back into the procedural world? Most likely, yes. But then again, you could get rid of OOP all together and revert to pure procedural, too. Just because it's possible doesn't mean not doing it is bad practice.

NogDog

I'd say I'm basically in agreement with Brad. While it may be valid to some degree to say that static methods are "bad OOP", the fact of the matter is that OOP is not the be-all, end-all of software programming. If some quick and easy procedural code can get a specific part of the job done more efficiently (i.e.: "on time and under budget"), and you can wrap up that procedural code as a set of static methods within a class in order to get that name-space effect, then I have absolutely no problem with it -- as long as it's done with eyes wide open and understanding that it is not truly object-oriented and you're okay with that.

Derokorian

I'd have to say the article in question is missing some major points. It uses examples of things that could be better off not being static (like $db::query) but there are still a number of situations where it's great. I don't want to namespace a file of functions, I can put it in a class because they are related. The next step is asking yourself, "Now that I have this class of related methods, do they rely on state of the application or class in order to function?" if the answer is no that's a perfect candidate for static usage.

Next up is static variables, the article says:

Static variables are global variables. They share all the problems that using $GLOBALS does.

This in my mind is a flat out lie. And can be proven with this line:

private static $_var;

Hey look! its not globally accessible!

In short just about every practice that someone deems unacceptable and completely against the idea of a pattern, has cases where its not just perfectly acceptable but quite possibly the best solution. Static in an object is the same. According to this guy, static is just bad but ask yourself this question - if its so bad why do the best languages support it?

laserlight

Lord Yggdrasill wrote:
Well I've heard many times in both PHP and Java world that Static Methods are not good design. In PHP they can just be a regular function defined outside of the scope of class, and they are not really true OOP. What do you think? Is Static methods poor OOP practices?

I subscribe to this notion, stated by Bjarne Stroustrup, the designer and original implementer of C++, in an interview on Designing Simple Interfaces:

Bjarne Stroustrup wrote:
Another example would be a Date class, where the operations that actually change the day, month, and year have to be members. But the function that finds the next weekday, or the next Sunday, can be put on top of it. I have seen Date classes with 60 or 70 operations, because they built everything in. Things like find_next_Sunday. Functions like that don't logically belong in the class. If you build them in, they can touch the data. That means if you want to change the data layout, you have to review 60 functions, and make changes in 60 places.

Instead, if you build a relatively simple interface to a Date class, you might have five or ten member functions that are there because they are logically necessary, or for performance reasons. It's hard for me to imagine a performance reason for a Date, but in general that's an important concern. Then you get these five or ten operations, and you can build the other 50 in a supporting library. That way of thinking is fairly well accepted these days. Even in Java, you have the containers and then the supporting library of static methods.

In particular, note the idea that "if you want to change the data layout, you have to review 60 functions, and make changes in 60 places". This is (the lack of) encapsulation in action, i.e., by providing a smaller core interface of functions that have access to the implementation by virtue of being non-static methods of the class, you increase encapsulation. The non-member functions or static members of a different class (in which case this other class is effectively used as a namespace) do not have such privileged access, hence you can more easily change the implementation of the class in question.

That said, this advantage does not apply to static methods that are members of the class in question. In such a case, there is an acknowledgement that there is global state that is necessary, but instead of making the global state available as global variables, you try and restrict access by providing an interface of public static methods to access the global state that is stored as private static data members.

Derokorian wrote:
According to this guy, static is just bad but ask yourself this question - if its so bad why do the best languages support it?

This is a kind of fallacious argument from authority though. A language feature may exist in multiple languages despite being bad, because of things like programmer familiarity leading to demand for the (mis-)feature, or lack of foresight early on in the language design that now cannot be corrected due to large legacy code bases that would need to be changed, that sort of thing.

Bonesnap

NogDog;11013165 wrote:
...the fact of the matter is that OOP is not the be-all, end-all of software programming.

You'd be surprised how often I have to defend this. It seems more often than not I talk to someone about programming (in PHP) and they think that the OOP approach is the best way, regardless. They'll say something like, "I want to redo this with classes and objects" and I'll ask why, because the code seems simple enough and I don't see how it would benefit from using objects, and the response I get is usually along the lines of, "well then it'd be more professional".

And from there I start challenging them on why OOP is automatically equated with professionalism, especially when they don't know things like HTTP is a stateless protocol and what that means - and I come from a Java and .NET background!

bradgrafelman

Bonesnap;11013187 wrote:
the response I get is usually along the lines of, "well then it'd be more professional".

There was someone in a thread here at PHPBuilder in the not-so-distant past that had the same mindset. I can't remember if I was able to bite my tongue or just pointed and laughed, but you're definitely making me want to go looking for that thread now.

At the end of the day, the computer couldn't care whether you like OOP or procedural or what your interpretation of either is; when the CPU gets handed some assembly instructions, it executes them one by one (quick quiz: is ASM procedural, OOP, or does-not-apply? :p) and you consume the result.

Lord_Yggdrasill

laserlight;11013173 wrote:
This is a kind of fallacious argument from authority though. A language feature may exist in multiple languages despite being bad, because of things like programmer familiarity leading to demand for the (mis-)feature, or lack of foresight early on in the language design that now cannot be corrected due to large legacy code bases that would need to be changed, that sort of thing.

Well I was wondering about this... I personally dont think most programming language designers really knew if a feature is a 'feature' or 'misfeature' at the very beginning of the development stage. They add a feature to the language 'cause they believe it will help certain programmers, while in the end it may turn out to be a 'mis-feature' instead. A good example is PHP's register_global, which does make programming easier for beginners but apparently the script ends up with severe security issues. The problem is that by the time a feature is found out to be a bad practice, so many people may have been using it in their program and it will break lots of code by removing this 'mis-feature'. PHP's register_global was removed 'cause its bad effect was so devastating, while other mis-features may simply be bad but not fatal so the developers just leave them the way they are.

laserlight

bradgrafelman wrote:
There was someone in a thread here at PHPBuilder in the not-so-distant past that had the same mindset. I can't remember if I was able to bite my tongue or just pointed and laughed, but you're definitely making me want to go looking for that thread now.

Hahaha, yes, I remember that 🙂
I really did do a search, and uh, it seems our dear Lord Yggdrasill is the culprit. Oops...
Is the ability to use/design MVC framework signature for advanced programmers?
Can anyone recommend a session wrapper class?

bradgrafelman wrote:
At the end of the day, the computer couldn't care whether you like OOP or procedural or what your interpretation of either is; when the CPU gets handed some assembly instructions, it executes them one by one (quick quiz: is ASM procedural, OOP, or does-not-apply? ) and you consume the result.

True, but I don't really like this attitude towards code: it can be taken to mean that the readability of your code with respect to humans does not matter. I prefer the attitude expressed in the preface to the 1st edition of Structure and Interpretation of Computer Programs:

Abelson & Sussman wrote:
First, we want to establish the idea that a computer language is not just a way of getting a computer to perform operations but rather that it is a novel formal medium for expressing ideas about methodology. Thus, programs must be written for people to read, and only incidentally for machines to execute.

The problem that Bonesnap encountered has to do with a mindset that places blind faith in a single paradigm, leading to over-architecting of design.

Weedpacket

laserlight wrote:
I subscribe to this notion, stated by Bjarne Stroustrup,....

I've also heard this argument made [citation needed], to the point where the object itself provides only the bare minimum of access to its state, and everything else provided statically.

A Graph class, for example, might have a grand total of nine methods: add or remove a vertex or edge; iterate over vertices or edges; get the adjacent edges for a given vertex; determine if a vertex or edge is already in the graph. Everything about a graph and everything that can be done with a graph can be described in terms of those primitives (strictly speaking, the last pair aren't necessary, but are there for performance reasons). You don't need, for example, a method that implement's Prim's algorithm - that would be in the supporting library (well, algorithms would be better implemented as objects in their own right anyway, using judiciously-positioned callbacks perhaps).

But I feel a good example of a static class method that doesn't make much sense implemented any other way is any symmetric operator on pairs of instances of the class.

Foo::Equal($foo1, $foo2)

As an instance method ([font=monospace]$foo1->Equal($foo2)[/font]) it introduces an artificial asymmetry (because it could just as easily be written [font=monospace]$foo2->Equal($foo1)[/font]), and while I do prefer to avoid having things like nulls floating around, the static method can cope with them and foreign objects.

laserlight wrote:
bradgrafelman wrote:
At the end of the day, the computer couldn't care whether you like OOP or procedural or what your interpretation of either is; when the CPU gets handed some assembly instructions, it executes them one by one (quick quiz: is ASM procedural, OOP, or does-not-apply? ) and you consume the result.

True, but I don't really like this attitude towards code: it can be taken to mean that the readability of your code with respect to humans does not matter.

Assembly instructions?! Luxury. We had to carve our own NAND gates and connect them with plugboards and be grateful for them!

Lord Yggdrasill wrote:
A good example is PHP's....

You're thinking here that PHP was designed...

Lord_Yggdrasill

Weedpacket;11013203 wrote:
You're thinking here that PHP was designed...

umm I dont quite get it. If it was not designed then what? It was copied/pasted? XD

Weedpacket

Lord Yggdrasill;11013257 wrote:
umm I dont quite get it. If it was not designed then what? It was copied/pasted? XD

Just hacked together and then had more stuff thrown in on an ad hoc basis?

traq

"designed in place and after the fact" might also be an appropriate description.

Weedpacket

traq;11013303 wrote:
"designed in place and after the fact" might also be an appropriate description.

"....I meant to do that."

traq

"it's not a bug; it's a feature that no-one knew about"

dalecosp

traq;11013303 wrote:
"designed in place and after the fact" might also be an appropriate description.

I like that. My take: PHP was born in '95, and has been in the process of growing up.

Like most teen-agers, it's not always sure what it's about. I'm not sure that turning 20 in a few years will make it a full-fledged "adult", either, but one could hope, I guess 🙂

NogDog

Also, for better or worse, it was developed initially by one person in order to take care of common tasks in a specific problem domain -- it was not developed by a consortium of Comp Sci PhD's to be the be-all, end-all of programming languages. But you have to give it credit: I wonder how much CPU processing is used each day to process PHP scripts versus, say Ada programs (which not all that long ago was going to be the language to replace all others)? 😉

traq

considering its origins and original purpose/scope, PHP is an amazing success.

dalecosp

Success, yes; amazing, well, maybe.

Basically, assuming adequate distribution of your marketing message, all that remains in "sales" is to lower the barriers for the "purchaser". One of the chief barriers to any product is its price; another is ease-of-use.

PHP is easy to use, and free, so it's not hard to predict the result, given adequate broadcasting and lack of competition.

The closest competitor to PHP at the time was what? ColdFusion? The price barrier was too high when a free alternative existed.

[Edit]: of course, it's easy to predict the past, isn't it?[/edit] 😉

Weedpacket

dalecosp wrote:
The closest competitor to PHP at the time was what? ColdFusion?

Perl?