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.

• Exceptional PHP
• Coding for Success: Writing Software You’ll Be Able To Understand Next Month

Here are some of the books I mentioned…

• Refactoring: Improving the Design of Existing Code
• php|architect’s Guide to PHP Design Patterns
• PHP in Action: Objects, Design, Agility
• Design Patterns: Elements of Reusable Object-Oriented Software
• Implementation Patterns
• Fundamentals of Object-Oriented Design in UML

I’m already looking forward to next year.

There are probably more than a few naive programmers who would read results like this and start to avoid these constructs in their own code for performance reasons. These are the same kinds of people obsessing over a few single or double quotes, who eschew “slow” objects in favor of switch statements that are many times slower than the polymorphic method calls they are trying to avoid.

But, that’s not the end of the story. Larry ran his benchmarks using 2,000,000 iterations. The N really matters here. Sure, iterators are slower than arrays, but you aren’t going to be iterating over two million things. I tend to fetch my database records in lots of 25 or 50. You aren’t going to be making two million invocations of __call. But how many will you make? Under what value of N does the performance of these techniques cease to matter? Is it ten, one hundred, one thousand, or ten thousand? You may be surprised at how few calls your program actually does and how little impact it has on performance.

As Wez and Travis point out in their comments, profiling is the way to find out the potential impact and to discover your true N.

Paul M. Jones has a good example of what I’m talking about. There, call_user_func_array appears to be a bottleneck, but it turns out that its the function being called, htmlspecialchars, not the calling process that consumes the balance of the time. In that case, the function was “only” called 300 times. I find that order of magnitude to be fairly typical. Something to be aware of, perhaps, but not something to obsess over.

The scale that Cal is talking about is actually better known as modularity:


| Few large modules ---- Sanity? ---- Many Small Modules |


If you haven’t listened to Alan Kay talk about the benefits of many small modules, you should do so now. Alan Kay coined the term Object Oriented. Love OO or hate OO, if you have an opinion on it, you should know what he was thinking. Hint, it wasn’t C++.

On the other end of the scale, One Giant Function is generally known as Big ball of Mud(PDF) Here is Brian Foote’s presentation on the paper (read the paper first).

 
function set($name, $value);
function get($name);
 

Some times there are some ancillary methods to deal with unsetting, checking for existence, setting via an array, or dealing with references in PHP 4. They can really clutter up the definition of a class. That’s not good. All this code is fairly standard, too, but it gets duplicated on every class that does this. That’s not good, either.

Oh, I’ll solve this problem by making a base class, some may say. Wrong. This a very feeble reason to spend your one shot at inheritance. Trust me, I know, I’ve done it.

I think the idea is to make the class extensible. But PHP is really ok with just setting new properties on a class.

 
$obj->foo = 'bar';
 

Another variation of this pattern is to use setXXX($name, $value) or setYYY($name, $value) methods. This happens alot with “options” or “vars” or “properties.” It also happens on request wrapper classes. To me this looks like there is an object here just begging to get out for each XXX and YYY.

 
$obj->xxx->prop = 'foo';
$obj->yyy->prop = 'foo';
$obj->zzz->prop = 'foo';
 

Since I’ve started eliminating these in my own code in favor of direct properties, intermediate objects or __set and __get, I feel I’ve seen nothing but positive results. Try it. You may like it, too. Let your properties be properties.

UPDATE:
From reading the comments, I think there was some confusion about what I meant in this post. I am not talking about using naked properties instead of accessor methods. I’m not talking about accessor methods at all in this post. A specific accessor method, such as

$obj->getFoo()

$obj->get('foo');

Even on projects with extensive generated documentation, I find that kind of documentation to be of extremely low value. The problem with inline API documentation is that there is no sense of priority. Developers are encouraged to document every element that can possibly be documented. Then, when the documentation is generated, there is no way to distinguish the important from noise.

Another problem is restating the obvious. When a property or method really is well named, there may not be much more to say in the docblock. But, the mechanics of docblocks invites the programmer to say it anyway. So, you end up with comments like “$widget the widget.”

Duplication is also a significant problem. If you inherit from a base class or you implement an interface, there is a tendency to copy and paste the doc block from the parent to the children. This is an obvious maintenance problem. In fact, this is one of the major problems with comments. If comments restate what the code does, its a form of code duplication. When the code is changed, it requires changes in the comments. In this sense, comments make code harder to maintain.

Lately, I’ve been trying to curb the attractive nuisance aspect of docblock comments by replacing docblocks with comments like

 
// Definition in parent
 

 
// docblock intentionally omitted.
 

Well, if docblocks are so bad, what is the alternative? Well, I’ve tried a few, including using a wiki for API documentation. Here is the problem. If duplication between the comment and the code is created by inline documentation, that maintenance problem becomes significantly worse with distance. If the documentation is external to the code, that distance really harms the ability to keep the documentation in sync with the code. So, docblocks are bad, but everything else is worse.

Docblocks were popularized by Sun and Java (or maybe Donald Knuth). But when sun was documenting their Java APIs with docblocks, they had a professional documentation team to do the work. When teams that don’t have a dedicated documenter role use these tools, I think they fall short.

So what is the solution? I’d like to see better techniques and conventions for solving the problems of docblocks: avoiding duplication, avoiding restating the obvious, and avoiding the tendency to docblock everything thats docblockable. Maybe there are more successful documenters out there who are handling these API documentation anti-patterns better than I am. I’d sure like to hear how.

Technical Background

A team needs members with a technical background. These guys are the ones that ensure everything works. They can write the hard bits of code, keep everything performing and make sure the code is maintainable. Without these guys, you will have problems. On the other hand, sometimes those with a technical background view problems solving as a puzzle, where the solution is the end in itself.
In my experience, team members with a less technical background are more empathic toward the user community. They view problem solving as a means to a goal. A customer focus is what makes a project successful. Software can be successful despite technical problems, but it cannot be successful if doesn’t meet the customer’s needs. Having some non-technical people helps prevent your resident technocrats from building a system that will service 10,000 concurrent users, but doesn’t meet the needs of the 329 users you have today.
Perhaps at the extreme end of this spectrum is the extreme programming practice of including a customer on the development team.

Experience

In expert versus novice programmers, I make the distinction between skill level and experience. Age, skill and experience often correlate, but not always. Your young apprentice programmers are important to have on a team. They can react faster. Sometimes not knowing better is a bonus. They’ll do things more senior team members don’t want to do. They do things they’re not supposed to do, sometimes for the benefit of the team.
I think people underestimate how long it takes to actually become an expert, as I mention in my previous post. But, then they also underestimate how similar all software projects are. They also overestimate the impact of their toolset. Generally the technologies in the laundry lists that form most job listings are not the critical success factors for that project.
People want a programmer with who can hit the ground running, who is familiar with all of the teams tools, languages and libraries. But, this is a monoculture as well. Sometimes you need people who aren’t from your toolset culture to point out where you have swallowed the hook too deeply or to introduce new tools and techniques from their alternate background. Sometimes their learning process can teach you something.
While some experience is valued in programmers, age sometimes isn’t. However, you need the older, more stable people as well. They keep the young ones from repeating the mistakes of the past. They keep the project on an even keel. It helps to have an older perspective on the team. I think they help keep attention focused on what matters. The tension between the older and younger team members helps keep the team on track.

Traditional Diversity Factors

I have no opinion on the impact of race. I have an opinion about women on software teams. I wish there were more of them. I have worked on software development teams with diverse nationalities. I regard that experience as positive. Different cultures have different tolerances for risk, different respect for authority or tradition. I think cultural diversity on a team is a good thing.

Managing Diversity

Over the years, there have been many methods proposed of matching people with the jobs they are best at. The solution that works best is to ask them. People gravitate toward the tasks that require their special skill sets. Good team management means hiring diversely and allowing that migration. On a well managed, diverse team, people will self select the jobs they are best at. As a result, the diverse team is more resilient and I believe potentially more successful.

BBCODE was designed for this purpose. There is no actual standard, but the core syntax seems fairly uniform. It’s good for those used to forums, where it seems to norm.

HTML markup is nice because it is a standard, even if varying subsets are supported. Learning a little HTML isn’t going to hurt anyone, at least for the next 20 years or so. The problem is that HTML was never intended to be hand edited. The syntax is not the most inviting, and different HTML-like markup languages handle whitespace differently than the HTML standard.

Wiki markup syntaxes were designed to be human friendly. The main problem I have with wiki syntax is that there is no standard. It seems like every wiki has a different way to formulate a link, for example. I guess there is some progress with Wiki Creole, but I still have a bad taste in my mouth.

The other problem I have with wiki markup is that I find it to be non-deterministic. When I edit any given wiki and try to use more than basic formatting, I never know what I am going to get. Most of the markup processing engines for these wikis are impenetrable morasses of regular expressions. It can be hard to gauge interactions. Are you really sure they are secure?

Speaking of impenetrable morasses of regular expressions, have you ever looked at WordPress’s input path? I’m sure every one with a WordPress blog who likes to blog about PHP code knows that it is a code eater. I’ve been particularly disappointed with WordPress in this area. Most the “code formatting” plugins still have problems protecting code from WordPress’ heavy hand.

But the WordPress preg_replace gauntlet doesn’t just mangle code. I have a post which has been sitting in draft mode for several weeks because I can’t figure out how to give it the proper markup. WordPress is somehow taking my perfectly balanced input markup and producing “unbalanced” output markup. I haven’t yet tracked down the problem to either submit a fix or to do a good bug report. Frankly, I’m not looking forward to trudging through all those regular expressions.

In Chris’ post, he takes the regular expression approach. Folks in the comments have pointed out a few problems with his approach, including the problem of interleaved tags. If you can’t tell by now, I am not a fan of the regular expression gauntlet approach to markup languages. I prefer a defined syntax and a traditional computer science style parser (which may use regular expressions).

The other must-have is a preview option. With so much variation in markup languages, not having a preview leaves the user to play Russian roulette with their submitted content. I’ve talked about that before in the usability of input filtering. This is another area where WordPress leaves the user high and dry.

The complex input path in WordPress combined with its reliance on global variables seems to leave it unable to do an in-page preview. The admin area preview is an IFRAME so that it launches a separate request. The various live preview plugins are JavaScript based and don’t work when it is disabled. They also don’t pass the input through the same input path that WordPress uses, so they are not a true preview.

I don’t mean for this to be a WordPress rant, on the whole, I like WordPress. Rather, I just wanted to point out how hard it can be to do good input filtering, that is safe, reliable, deterministic, and usable.

I have a great fondness and respect for the old Object Pascal based Delphi. Delphi’s VCL has been influential, inspiring the GUI components in Java. And, of course Ander Heijlsberg went on to put a huge stamp on C# and .NET that would be familiar to any Delphi programmers.

I’ve always admired this approach of extending the language syntax to make common things easy and for the integration between the language and the tools. In Delphi, this was evidenced by the excellent properties support. Six years later, this is the feature I miss the most in PHP. This language extension approach has seen its culmination in C# and LINQ. It almost pains me to say it, but the cutting edge of commercial language design is at Microsoft now.

On the other hand, I’ve never had that much respect for Borland as a company. We were big enough to have Borland representative’s come to our office and try sell us their products. They were terrible at the mechanics of selling into big companies. I was in their beta programs. I went to their conferences. I’ve never had any sense that they know what they are doing business wise. Inprise? What were they thinking? Now here they are, just having gotten their asses kicked by eclipse in the Java IDE space and what are they working on? They release an IDE for PHP, just as Zend is embracing Eclipse in the PHP space. Brilliant!

I don’t quite know what Delphi means now. To me, its always been and IDE plus Object Pascal. What is it now? I also don’t quite know what Borland has become. Is it CodeGear now? I guess that the Delphi for PHP IDE comes from Quadram and their now discontinued QStudio product. And the VCL is their WCL (no linkage found). Anytime I’ve been touched by the corporate entity that was Borland, confusion ensued. I’m confused now.

It appears that the PHP version of the VCL will be released on open source. There is nothing at the sourceforge project, yet, but I’ll be interested to see what it looks like, if only for old times sake.

The Delphi tool approach was to serialize an object based representation of an application, then offer tools to create that serialized representation, and to load that representation at run time. In Delphi, that serialization was done into the form files (.DFM). I’ll be interested to see how Delphi for PHP does it. Perhaps, this is an area where the Eclipse PHP Development Tool can learn. I know that I definitely had Delphi in mind when I was writing my column on Object Serialization for this month’s php | Architect.

Meanwhile, if you want to see the Delphi influence in PHP with code that you can download today, take a look at the Prado framework, which I imagine to be like the VCL for PHP, but without the supporting IDE.

This is a space I’ll definitely be watching.

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.