OOP

Beyond Abstract classes

Recently, Anthony Ferrara has been posting a periodic "Beyond" series about software design philosophy. Some in particular have hinted at concepts I've been pondering as well. With his blessing, therefore, consider this a continuation of that series.

PHP 5.4 is not exactly new, but it's finally starting to see actual usage by a decent number of people. Its most notable new feature is Traits, which in PHP are implemented as, essentially, compile-time copy-paste. Conceptually, though, they're a way to mix functionality into a class without using inheritance, and without requiring a separate distinct object for composition. (At least in PHP; the term "trait" appears in other languages for similar but subtly different tools.) That's not to say that they're a surrogate for composition; they most certainly are not. They serve a different purpose, that is, providing code for a class to reuse without using inheritance.

Recently, I was reading an article discussing the implementation of inheritance, such as it is, in Go, Rust, and other new-wave concurrent languages. (Thanks to twistor for helping me track down the link.) It made an interesting point that crystallized for me why it is I am so excited about traits. Specifically, it noted that there are not one but two kinds of code reuse: interface reuse and code reuse.

Dropping forward

A little over a month ago, a few Drupal developers announced something new: A fork of Drupal called Backdrop. There's been quite a bit of talk about it, of course. While I don't plan to be using it myself, Backdrop has raised a number of valid points and criticisms of Drupal that are worth discussing.

The danger of privates, and composition vs. inheritance

The private variables debate is going around the PHP world again. Brandon Savage posted a pair of articles pointing out the perils of private variables, boiling down mostly to them making extension infesible or impossible. Anthony Ferrara replied with his own article, arguing that the real problem is using inheritance in the first place rather than composition. I figured I'd weigh in on my own blog rather than in a comment. :-)

As an academic matter, I agree with Anthony. Composition and interfaces are more flexible than inheritance. I've been preaching the interface gospel within Drupal almost as long as I've been preaching Dependency Injection.

Backward compatible APIs

As we begin a new year, it seems appropriate that the discussion of backward compatibility has come up yet again in Drupal. It's a perennial question, and you can tell when a new Drupal core version is ready for prime time when people start complaining about lack of backward compatibility. It's like clockwork.

However, most of these discussions don't actually get at the root issue: Drupal is architecturally incapable of backward compatibility. Backward incompatibility is baked into the way Drupal is designed. That's not a deliberate decision, but rather an implication of other design decisions that have been made.

Drupal developers could not, even if they wanted to, decide to support backward compatibility or "cleanup only" type changes in Drupal 8. It is possible to do so in Drupal 9. If we want to do that, however, then we need to decide, now, in Drupal 8, to rearchitect in ways that support backward compatibility. Backward compatibility is a feature you have to design for.

What Symfonic Drupal means

Earlier today, Dries committed a patch that adds two Symfony2 Components to Drupal: ClassLoader and HttpFoundation.

On its face it's a fairly simple patch; the new code in it is maybe a dozen lines. But it's an important part of a larger shift within Drupal to better embrace the modern web, on the server as well as the client.

Objects, property visibility, and trade-offs

As if on cue, the public vs. private debate has sprung up again within Drupal. The timing is fitting given my last blog post on programming language paradigms. Of course, property visibility is not a new debate, and the PHP community debates this subject from time to time (sometimes humorously).

What I believe is usually missing from these discussions, and what I hope to offer here, is a broader picture view of the underlying assumptions that lead to different conclusions about when different visibility is appropriate (if ever).

In short: It's the difference between procedural-think and object-think.

Programming language trade-offs

This article is also available in Serbo-Croatian

There has been much discussion of late in Drupal about Object-Oriented Programming. That's not really surprising, given that Drupal 7 is the first version that has really tried to use objects in any meaningful way (vis, as something other than arrays that pass strangely). However, too much of the discussion has boiled down to "OMG objects are inflexible so they're evil!" vs. "OMG objects are cool, yay!" Both positions are harmfully naive.

It is important for us to take a step back and examine why one particular programming paradigm is useful, and to do that we must understand what we mean by "useful".

Programming paradigms, like software architecture, have trade-offs. In fact, many of the same methods for comparing architectural designs apply just as well to language design. To do that, though, we need to take a step back and look at more than just PHP-style objects.

Warning: Hard-core computer science action follows. If you're a coder, I recommend getting a cup of $beverage before continuing, as it could take a bit to digest although I've tried to simplify it as much as possible. There's fairly little Drupal-specific stuff here so hopefully it should be useful to any PHP developer.

DrupalCon SF: The big time

Well, it's been long enough after DrupalCon for me to survive another conference and a business trip, so I finally have time to reflect.

Oy!

(See below for slides from my sessions.)

How's your OOP?

Once again, I am slated to present general Object-Oriented techniques at DrupalCon. It's an important topic; sadly a large number of Drupalers don't really "get" OO programming, but Drupal 7 is starting to make heavy use of OO. There are also an enormous number of places in Drupal where a more Object-Oriented approach would make the code vastly cleaner, simpler, and faster, if only more people thought to approach it from that standpoint.

Of course, the question is how to target such a session. I don't want to talk over people's heads, but I also don't want to waste your time with "this is a mouse"-level material.

So, I put the question out to you, future DrupalCon SF attendees. What level of technical detail would be most useful to you?

Important DrupalCon session change!

Just to give everyone a heads up, I have made some changes to one of my sessions. Based on the feedback I received earlier, my session on Object-Oriented Drupal has been updated. It seems no one wanted to hear about the basics, as they already knew them. :-) I will instead be focusing on design patterns, OO design philosophy, and how it applies (or should apply) to Drupal. It's too late to get changes into the printed program, but I have updated the session page on the DC DC web site to reflect the new focus.

So if you were hoping for a session on basic PHP OOP syntax and concepts, um, sorry. If you're looking for an intermediate to advanced session on how to use OOP well, then this session is for you.

I'll see you in DC!

Syndicate content