Skip to main content

Static methods: are they still bad considering PHP 5.3 late static binding?


If you search on the reasons why static methods are bad the first thing you find it is because you can't override it when you are unit testing.



So is this still true considering in PHP 5.3 you can do whatever you want with the introduction of static:: ?



Add:



http://sebastian-bergmann.de/archives/883-Stubbing-and-Mocking-Static-Methods.html



Note he explains even how to use singleton without any testing problem:



Source: Tips4allCCNA FINAL EXAM

Comments

  1. If you have a static member function, it could usually be a free function. The usual reaction is then that the coder has opted for a static member function only because of the myth that "everything must be in an object".

    That's why people discourage them.

    And, because it's not a very convincing argument, those people pointed to unit testing instead. Not sure what they'll do now.

    ReplyDelete
  2. Static methods aren't bad in themselves. Sometimes certain operations don't make sense to require a particular object to do. For example, a function like square root would make more sense being static.

    Math::sqrRoot(5);


    rather than having to instantiate a Math 'object' and then call the function.

    $math = new Math();
    $result = $math->sqrRoot(5);

    ReplyDelete
  3. More difficult to test is a reason but not the only one. Static methods provide global access, and global access is bad.

    Of course, you'll find that there's another global access to objects and that's creating one with 'new'. Objects have to be created somewhere so we can't eliminate that (though minimizing it is a good idea). Static methods as global access to a class is bad, unless it is there to replace 'new' through higher level programming:

    $user = new User();
    $user->setPointsTo(100);

    // vs

    $user = User::with100StartingPoints();


    In this case I created code that is more readable while not misusing global access (the 'new' needed to be called anyway).

    Edit: Let me give you an example in the way static methods 'can' be the death of testability (note how in the example above you don't even need to mock the static method but can easily test the new and static method produces the same result). Let's use your logger example:

    class Logger {
    public static function log($text) { // etc }
    }

    class AccessControl {
    public function isAllowed(User $user, $action) {
    // do stuff, determine if $allowed
    if (!$allowed) {
    Logger::log('user X was not allowed to do Y');
    }
    // do stuff
    }
    }


    There is no way we can test this method cleanly because of the global call to Logger::log. It will depend on the correct working of the Logger class.

    ReplyDelete

Post a Comment

Popular posts from this blog

[韓日関係] 首相含む大幅な内閣改造の可能性…早ければ来月10日ごろ=韓国

div not scrolling properly with slimScroll plugin

I am using the slimScroll plugin for jQuery by Piotr Rochala Which is a great plugin for nice scrollbars on most browsers but I am stuck because I am using it for a chat box and whenever the user appends new text to the boxit does scroll using the .scrollTop() method however the plugin's scrollbar doesnt scroll with it and when the user wants to look though the chat history it will start scrolling from near the top. I have made a quick demo of my situation http://jsfiddle.net/DY9CT/2/ Does anyone know how to solve this problem?

Why does this javascript based printing cause Safari to refresh the page?

The page I am working on has a javascript function executed to print parts of the page. For some reason, printing in Safari, causes the window to somehow update. I say somehow, because it does not really refresh as in reload the page, but rather it starts the "rendering" of the page from start, i.e. scroll to top, flash animations start from 0, and so forth. The effect is reproduced by this fiddle: http://jsfiddle.net/fYmnB/ Clicking the print button and finishing or cancelling a print in Safari causes the screen to "go white" for a sec, which in my real website manifests itself as something "like" a reload. While running print button with, let's say, Firefox, just opens and closes the print dialogue without affecting the fiddle page in any way. Is there something with my way of calling the browsers print method that causes this, or how can it be explained - and preferably, avoided? P.S.: On my real site the same occurs with Chrome. In the ex