Why Interfaces Rock

When I first learned PHP 5’s object oriented syntax and rules, I didn’t see much of a point to the interface options. I felt that I could do more by defining abstract classes and at least filling in some of the methods with some details. Lots of people in the PHP world still aren’t 100% sure the reasons that interfaces exist, or the best way to use them. However, interfaces are very cool, and anyone who does OOP in PHP should know about them.

To start, what is an interface? An interface is a collection of completely abstract methods. Interfaces do not contain any of the innerworkings of the application; instead, they serve the sole purpose in setting a structure for the objects that implement them. All of their methods must be public. Here is a sample interface:

Continue reading

Peer Review: Improving The Business Logic

This entry is part of an ongoing series involving the review of a code sample and it’s refactoring. For the original code sample, see here.

So far, we’ve done quite a bit of work on our Twitter class, making it better. There’s still work to be done, though, especially improving the logic.

The Twitter class we have now has a number of logical flaws in it that we need to address. Additionally, there are some logical flaws that we started with that I want to highlight, even though we’ve already fixed them. Let’s get started with those.
Continue reading

Peer Review: Looking At Abstraction – Redux

This entry is part of an ongoing series involving the review of a code sample and it’s refactoring. For the original code sample, see here.

Editor’s Note: The response of the community to this series has been great, and I’ve been given a large number of suggestions. I’ve incorporated some of those suggestions into the code and into this article. Thanks to Jeff Carouth, Greg Beaver and Daniel O’Connor for their help and suggestions.

This entry will focus on our use of the database, and specifically on the already_tweeted() method. This method has a number of problems, and while we’re focusing on the implementation of the database, it’s important to note that we will also need to address some of the logic (which will be the next part of the series).

In our last entry, we focused on abstracting the HTTP request out to a seperate class. Lots of people wrote comments with suggestions of HTTP handlers, including pecl_http, the PEAR HTTP class, HTTP_Request2 and the PEAR Log class for logging. These are all great suggestions, and all will help abstract out the class without causing us to have to write our own implementation of common problems (the Not Invented Here (N-I-H) syndrome).

In focusing on the already_tweeted method, one thing becomes immediately apparent: it is private. This suggestion, provided by Greg Beaver relates to our first discussion of coding standards and we will change the class to a protected class for extendability later on.
Continue reading

Peer Review: Taking Code And Making It Better

On Wednesday, August 12th, we had a meeting of the DC PHP Developer’s Group. Keith Casey of Blue Parabola led a code review of a member-submitted sample. The review was informative, educational, and helpful. With the permission of that member, I’ve decided to write a series on the tools for reviewing code and re-factoring it.

The code sample (included below) isn’t perfect. It needs work, and we’ll be working on it over the next few articles. Along the way, we’ll talk about strategies for identifying weaknesses, candidates for refactoring, and methods for writing better code before you get to the review stage. We’ll also refactor this into something more usable, and end up with a finished product that’s better than when we started.

The knowledge gained is based off the DC PHP Developer’s Group, as well as many notes that I put together. The refactoring process requires a lot of thought, and so this series will contain six more entries, starting with the first one on Monday. But before we begin, here’s the code sample we’ll be working with:
Continue reading

Of Lies, Damned Lies, and Benchmarks

It’s no secret that we like statistics. Human beings like being able to compare two things, apples to apples. We like the ability to say “this thing is better because…” and being able to back it up with a seemingly solid fact, rather than just our opinion. We build charts to show how things stack up side-by-side, and we even build software to make those charts, which are then compared using the charts, and on we go.

But benchmarks, for all their decision-making aid, fail under the best of circumstances for one simple reason: they’re not real life.

Continue reading