You’ve got until August 30th, 2008 to migrate your code to the latest Youtube API. After that date, your current code base might not work.
I used 3 important coding concepts while working on migrating my Youtube Facebook App to the newest Youtube API:
The strategy pattern allows you to define common behaviors that will be shared among your set of classes. In this case, I’ve got a class for the old Youtube API, and a class for the new Youtube API. Although the URLs used for accessing the two APIs are different, I’ll define a method common to each class for accessing URLs. In this case it’s the setURL method.
In PHP I do this like so:
interface apiCalls
{
public function setUrl();
}
The factory pattern allows me to create an instance of an object for using the old API or the new API on the fly. Factory methods just return the new instance of an object.
$dynamic_fave = FaveFactory::Create(“cyphgenic”, ‘yes’, 2, ‘on’, ‘2.0’);
$dynamic_fave->setUrl();
print $dynamic_fave->url . “\n”;
$dynamic_fave = FaveFactory::Create(“cyphgenic”, ‘yes’, 2, ‘on’, ‘1.0’);
$dynamic_fave->setUrl();
print $dynamic_fave->url . “\n”;
If you take a look at the code I’ve got and compare the old version with the new one, you can also see that I’ve cleaned up the nested if-else statements with arrays.
BAD NESTED IF-ELSE:
if ($showUploaded == 'on') {
$method = "youtube.videos.list_by_user";
} else {
$method = "youtube.users.list_favorite_videos";
}
YAY! NO IF-ELSE:
$h_method['on'] = "youtube.videos.list_by_user";
$h_method['off'] = "youtube.videos.list_by_user";
$method = $h_method[$this->showUploaded];
Below are the links to the bits of the code that I had to migrate. I just use one particular method, setUrl() as an example.
You might be wondering why two classes for the old and new API. If any new features need to be coded, or bugs need to be fixed in either API, I can do so within a particular class, and not add more obfuscation to the code. The two classes don’t violate the DRY principle because each models a particular thing.
