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.

Monday, August 31st, 2009 @ 6:30 am | Comment (2) | Categories: Best Practices, System Architecture, Debugging
Tags: , ,

Peer Review: Looking Into Abstraction

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.

There are a number of fundamental concepts in object-oriented design that we should take notice of. One of these concepts is abstraction. This is what we will focus on today and in the next entry.

This article will focus on the constructor method. There are a couple of problems, namely that the constructor itself does a lot of actual work. Also, we have the cURL setup done in the constructor. This object is a Twitter object, not a cURL object; this means that we should decouple the cURL functionality and abstract it into a separate object of its own. This not only will make our object more true to it’s functionality as a Twitter object, but will allow for greater reuse (since we’ll be able to use the cURL object for more).

There’s some debate about whether or not you ought to write things like wrappers for native PHP functionality. One thing that is missed in the “don’t write a wrapper for cURL!” argument is that a good wrapper for HTTP requests shouldn’t be limited to cURL. In fact, it should make use of fopen(), file_get_contents(), etc. in the case that cURL doesn’t exist. A good object would test for this, and change its behavior based on preset rules. (strategy pattern, anyone?)

Wednesday, August 26th, 2009 @ 1:00 am | Comment (11) | Categories: Best Practices, System Architecture
Tags: , ,

Peer Review: Managing Coding Standards

If you need a sample of the code, please visit here.

One of the first things I look for when I check out code is how is the code organized? Is it laid out well? Is it coded to a particular standard?

In our code sample, the first thing we should address is how does the code look. There are a number of suggestions I would make immediately. Let’s dive in.

There are no DocBlocks or clear coding standards.

No clear coding standard jumps out at you right away when you read this code. There’s a lack of consistency, but beyond that, code completion is hindered by a lack of standards. Also, there’s no DocBlocks, which would help improve the documentation of the code.

There are lots of coding standards out there: PEAR, WordPress, Drupal and Zend Framework all have a coding standard in place that you can adopt in your own code. I highly recommend it.

The first thing I might do is add some DocBlocks. It will help us understand the code better.

Monday, August 17th, 2009 @ 12:00 am | Comment (8) | Categories: System Architecture, PHP 5, Best Practices
Tags: , ,

To stat() Or Not To stat()?

The Alternative PHP Cache (APC) is a tool that offers a massive performance gain to almost any PHP application simply by turning it on. This extension to PHP provides both opcode caching and user caching, placing files and data into memory for fast retreival, and, if used correctly, eliminating some of the bottlenecks of the file server or database.

Turning APC on is a great way to get a performance boost, but there are ways to help improve APC’s performance.


Thursday, July 30th, 2009 @ 4:33 pm | Comment (3) | Categories: Best Practices, System Architecture
Tags: , ,

Making Life Better With The SPL Autoloader

How many of us have seen this example in code we’ve worked on?


Friday, July 24th, 2009 @ 3:00 am | Comment (13) | Categories: System Architecture, Best Practices, PHP 5
Tags: , ,

Use Registry To Remember Objects (So You Don’t Have To)

One of the biggest challenges in OOP programming with PHP is the ability to pass around objects and let other objects use them. This challenge can be solved with careful design, however. Here we will discuss the registry pattern, not a member of the GoF’s original patterns but still an important pattern nonetheless.

Tuesday, July 21st, 2009 @ 5:30 pm | Comment (31) | Categories: Best Practices, System Architecture, PHP 5
Tags: , , , , ,

« Older Entries Newer Entries »

Copyright © 2024 by Brandon Savage. All rights reserved.