A little while ago, I wrote an article discussing why interfaces rock and the way that interfaces work. However, a couple of comments made me realize that I didn’t discuss one of the key elements about interfaces: why you would use them.
One key rule about interfaces is that all methods must be defined as public. You cannot define protected or private methods, and you cannot define any members of any type. You may define constants, as these cannot be overridden by any class implementing the interface.
Wednesday, October 7th, 2009 @ 1:00 am |
Comment (6) |
Categories: PHP 5
Tags: OOP, PHP 5, interface
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:
Friday, September 25th, 2009 @ 1:00 am |
Comment (16) |
Categories: PHP 5
Tags: OOP, PHP 5, interface
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.
The topics discussed in this entry may be fairly advanced. Please feel free to ask questions, and discuss best practices.
If you’ve been following this series from the beginning, take a moment to look at the original code sample and compare it with where we are now. We’ve come a long way!
There is one last area that I want to address, and this has everything to do with object-oriented principles and code reusability. For those who are familiar with OO programming, they realize that the use of classes does not make something object oriented by nature. In this final part of the series, we’ll move one step closer to being object-oriented, by introducing the concepts of request and response objects.
At the moment, our object takes arguments like most functions do. This has some limitations. The first limitation is that the object must be aware: that is, it must have an understanding of the request it is being passed, and the response that it is getting from Twitter, as well as the response it will give back to our application. This means that in the event that something ever changes about the way that response is organized, we have to change this code, explicitly. I would like to avoid that.
(more…)
Monday, September 21st, 2009 @ 1:00 am |
Comment (6) |
Categories: Best Practices, System Architecture, PHP 5
Tags: refactoring, OOP, Peer Review, code review
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.
(more…)
Monday, August 31st, 2009 @ 6:30 am |
Comment (2) |
Categories: Best Practices, System Architecture, Debugging
Tags: OOP, PHP 5, Propel
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: Best Practices, System Architecture, PHP 5
Tags: design patterns, PHP, objects php 5, OOP, PHP 5, registry pattern
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: PHP 5, Best Practices, System Architecture
Tags: OOP, PHP 5, PHP, objects php 5
| « Older Entries | Newer Entries » |