I agree for that case. Consider instead, a more complicated operation that requires a setup and a tear down after.

 
setup();
operation();
teardown();
 

Now what happens if we need to be able to customize operation? That’s common enough, one way of doing this is to create a template method.

 
class MyExample {
    function operation() {}
    function setup() {}
    function teardown() {}
    function doit() {
        $this->setup();
        $this->operation();
        $this->teardown();
    }
}
 

Now, we can subclass MyExample and override operation() with custom logic. This is well and good, but what the customization we need is fairly small. Creating a new class carries a certain weight. Especially if you are religious about one class per file.

 
class MyExampleExtension extends MyExample {
    function operation() {
        // custom logic
    }
}
 

Plus, you now have to deal with some creational patterns to make sure your custom class is used in the right context.

 
$myObject = $registery->get('MyExample');
$myObject->doit();
 

So, instead of encapsulating the pattern, its also very common to just copy and paste:

 
setup();
custom_operation1();
teardown();
//...
setup();
custom_operation2();
teardown();
 

But that’s not good on the duplicate code front. So here is an alternate implementation, but using a closure anonymous function as a callback.

 
class MyExample2 {
    function setup() {}
    function teardown() {}
    function doit($operation) {
        $this->setup();
        $operation();
        $this->teardown();
    }
}
 

The advantage of MyExample2 is that extending is that the setup and teardown pattern is encapsulated in one spot. You konw that if setup is called, teardown will also be called. But, extending the operation is very light weight.

 
$myObject = new MyExample2();
$myObject->doIt(function () { /* custom logic 1 */ });
// ...
$myObject->doIt(function () { /* custom logic 2 */ });
 

There is another significant benefit to this and that is locality of reference. Here, the custom1 logic and the custom2 logic appears in context, not far away in some custom class or function declaration. So you get encapsulation and reuse for the common code parts, but without the sprawl and overhead of declaring structures that will only be used once in a context far away their declaration.

Closures and anonymous functions decrease the activation energy to write good code.

That’s not to say that closures and anonymous functions can’t be abused. If you keep seeing the same logic over and over in an anonymous block, you should probably give it a name in the form of a class, method or function.

However, OOP is not on the decline. Quite simply, it has become mature. The discussion may be on the decline because almost every language that anyone actually uses implements a core set of OOP features. OOP has won its arguments. Good luck taking a language mainstream without it.

Oh, yeah, there are some OOP features that are still controversial or unusual. There is the single versus multiple inheritance debate, or perhaps Ruby’s open classes. But, I think these things have a way of cross-pollinating across the popular languages when they make sense.

A good example of this cross-pollination is happening now with properties, accessor methods and the uniform access principle. Language support for declared accessor method is slowly creeping across all of the major languages. Not that Objective C is all that popular, but Objective C 2.0 adds support for ‘em. Even stodgy old Java is considering language level property support.

Sadly, PHP does not yet have language support for declared properties with accessor methods. What are __get and __set? They’re property missing handlers, not accessor methods. You can simulate accessor methods with them, but that is a poor solution for most applications. There is no way to support differing visibility, for example protected setters and public getters. Property not found handlers are prohibitively verbose to write, have a poor performance profile, have no capability for reflection, cause interoperability problems, and have inheritance edge case gotchas (not present in the java beans model, for example). My hope is to see good language support for properties in PHP 6.

Closures may not be object oriented, but they seem to be undergoing that same language cross-pollination. Thats seems to be a pretty good sign that they are useful. It doesn’t have to be closures OR objects, it can be closures AND objects. We can use each when they make sense.

Closures are another wish list item for PHP 6. PHP is almost wired for them with its callback psuedo type. Everywhere you can use a callback in PHP, you could use a closure. I’d like to see the callback Pinocchio become a real boy like integer or boolean. The cool thing is that with PHP’s weak typing the string and array forms of the callback pseudo-type can automatically be converted to a native closure type when needed.

As I said, the core OOP features that most programmers use are in all the mainstream languages. The interesting part is how they handle the OOP edge cases. This is the space where the framework developers live. As I wrote in culture of objects, PHP has some problems here. In some ways I think Ruby’s support for edge cases is exactly what allow a framework such as rails to be built in it, although, I’m not familiar enough with Ruby to say for certain.

I think addressing some of these issues in PHP 6 will make it a Ruby killer for web applications. It isn’t necessary to be perfect here, just to be good enough and allow the larger community, distribution, and stability to take over. Unfortunately, there is a long lead time here. If PHP 6 were to add support for declared accessor methods, closures, and late static binding — my top three framework enablers — it would still be at least 2-3 years before PHP 6 was sufficiently deployed and the frameworks could adapt to the new features.

In the meantime, while the PHP culture may have problems, the Ruby culture may not be without its own problems. The influx of lisp and smalltalk programmers, two languages that did not go “mainstream” may prevent Ruby from going mainstream. Take a look at The impending ruby fracture. Isn’t this one of the things that happened to SmallTalk and Lisp? I’m still not convinced that Ruby hasn’t inherited many of the same maintenance problems from its Perl heritage. Just like english, huh? Only time will reveal Ruby’s maintenance characteristics. I give it about 2 to 3 years for today’s Rails systems to hit full legacy mode. How long do you think it will take for top notch unicode support in Ruby?

Obviously PHP 6 is all about teh unicode. Including an opcode cache is going to be an important performance and adoption driver. However, I’d like to see more progress on framework enablers. I really want to see these in the next major PHP deployment cycle and not in the PHP 7 deployment cycle. Are there framework enablers other than closures, declared property accessors and late static binding that I have overlooked?

I have high hopes for PHP 6 as a mature and mainstream language.