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.
(more…)
Tuesday, September 8th, 2009 @ 1:00 am |
Comment (10) |
Categories: Best Practices, System Architecture, Debugging
Tags: design, objects php 5, PHP 5, 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.
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?)
(more…)
Wednesday, August 26th, 2009 @ 1:00 am |
Comment (11) |
Categories: Best Practices, System Architecture
Tags: refactoring, PHP, objects php 5
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.
(more…)
Tuesday, July 21st, 2009 @ 5:30 pm |
Comment (31) |
Categories: System Architecture, PHP 5, Best Practices
Tags: objects php 5, OOP, PHP 5, registry pattern, design patterns, PHP
One of the best features of PHP’s object model (and really all object models) is the concept of inheritance – that is, derived classes inherit the members and methods of their parents. This is a fantastic way to further encapsulate and abstract your code because it means you can define some base functionality and then later on extend that class to add new functionality and even override existing functionality to make the class specific.
But this concept is a double-edged sword in PHP (and all other languages). Here’s where multiple inheritances can kill you.
(more…)
Friday, July 17th, 2009 @ 8:00 am |
Comment (20) |
Categories: Best Practices, System Architecture, PHP 5
Tags: PHP, objects php 5, OOP, PHP 5
Last December, I wrote about the use of PHP superglobals inside of classes (link here). I asserted at the time that superglobals inside of a class violated some basic rules on what a class was supposed to do. Today, I am revisiting that discussion.
(more…)
Monday, July 13th, 2009 @ 6:00 pm |
Comment (11) |
Categories: PHP 5, Best Practices, System Architecture
Tags: OOP, PHP, superglobals, classes, objects php 5
Have you ever written code like this?
(more…)
Monday, December 15th, 2008 @ 1:41 pm |
Comment (1) |
Categories: Best Practices, Usability, Web Architecture
Tags: superglobals, classes, objects php 5