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.
Monday, September 21st, 2009 @ 1:00 am |
Comment (6) |
Categories: Best Practices, System Architecture, PHP 5
Tags: refactoring, OOP, Peer Review, code review
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:
Saturday, August 15th, 2009 @ 7:00 am |
Comments (0) |
Categories: Best Practices, PHP 5
Tags: refactoring, PHP 5, Peer Review, code review