Guest190829
01-02-2008, 10:00 PM
Skill Level: Intermediate-Advanced knowledge in programming; basic understanding of OO structure and concepts in PHP.
** This article may not be reproduced without the owner's (Danny.VBT) permission.
Introduction
Hypothetically, let's imagine that vBulletin just released version 4.0. They announce that the entire back-end architecture has changed and now you must update your quite large and complex modification to support their new code changes because your users (clients) are demanding functionality for vB 4.0
This definitely means hours of inspecting and altering thousands of lines of code, right?
Not if you use implement the Facade pattern!
The Facade Pattern? What?s that?
The Facade Pattern is a design pattern that introduces a whole lot of benefits when dealing with third party code that you have no control over. In short, it acts as a tier between your modification and vBulletin.
Now, you may be asking: But my modification is designed specifically for vBuleltin, why would I want to separate them?
Reasons for Utilizing the Facade Pattern
Encapsulation - encapsulating essentially hides an implementation of a certain method from client code.Take the following example: I want to determine if a user has permission to do a certain action. Normally, you would simply have:
if(!($permissions['myhackpermissions'] & $vbulletin->bf_ugp['myhackpermissions']['candosomething']))
{
print_no_permission();
}
If wrapped in a facade class, you would have something like:
if(!$this->bridge->permission(?candosomething?))
{
// User doesn't have permission
}See how simple that looks? The actual implementation of the permission checking would be in the facade class, but it is only the interface that matters. Now instead of sprinkling vBulletin version specific code throughout your system, you are only providing an interface to that specific implementation.
So what happens when vBulletin releases a new major version and the implementation changes? That brings us to our next reason.
Inheritance - Inheritance provides a way to avoid code duplication and get the most of encapsulation.Let us go back to the previous permission example. Here is the implementation of the permission method:
class facade
{
function facade()
{
// Some required initialization for vBulletin backend and global variables.
}
function permission($option)
{
// Ternary for readability purposes only...
return ($permissions[PRODUCT_ID . ?permissions?] & $vbulletin->bf_ugp[PRODUCT_ID . ?permissions?][$option]) ? true : false;
}
} This class is a simple facade with a permission method to encapsulate the data. Now pretend vBulletin 4.0 is released and the entire permission handling is now altered. Instead of having to go through all the hassle of finding and editing the version specific code throughout your modification, you can simple utilize inheritance to update the methods that need to be altered.
class facade_40 extends facade
{
function permission($option)
{
// 4.0 specific permission handling
}
}Then at the start of the client code you can determine which class to create:
if ( //vBulletin version == 4.0 )
{
$this->bridge = new facade_40()
}
else {
$this->bridge = new facade();
}
// Code code code.....
if($this->bridge->permission('candosomething'))
{
//More code
}
The example above would normally be a little more dynamic. Listed in the suggested readings below, PHP 5 Objects, Design and Practice list some patterns that help with object generation.
The point of the example is that the code above does not care if $this->bridge is facade or facade_40...the code will continue to function as long as the interface remains. This is an integral concept of OO programming called Polymorphism.
When an upgrade of vBulletin requires that you alter your code, you no longer have to update every single file with the new implementation: Just extend your facade class and add support for proper object generation based on vBulletin version; ultimately saving time from tedious code alterations when you could be adding new, exciting features to your modification.
Implementing a Facade
Utilizing the facade pattern is not always the best choice. If you are only create a small modification with only a few files or whatnot, it may not be worth the time to design your application around a facade. However, if your modification has more than a handful of files with thousands if not hundred of thousands lines of code, the facade pattern may be a huge time saver for you in the future.
Global Variables - Due to the architecture of vBulletin, with a facade type implementation, you may have to globalize some of the default variables that run across vBulletin such as $vbulletin, $phrase, $style, $permissions ...etc...etc...This type of initialization of global variables will most likely be done within the constructor or initialization function.
As with any global variables, you must take good note not to override any essential data.
Object Oriented Approach - The Facade pattern requires the use of classes and objects to gain the benefits of encapsulation, inheritance, and composition.Implementing a facade would require more than one class, so it important that you fully understand OO before implementing any type of design pattern. Do not just use OO because it seems popular to do.
Conclusion
I left this article abstract for a reason. I don?t want to provide code to mimic or to copy and paste, but to allow those who unsure or unfamiliar with object oriented programming to see the benefits of OO even with just vBulletin modifications. Take the time to research and understand Object Orientation and it will be extremely beneficial to you in the future.
Suggested Readings:
PHP 5 Objects, Designs, and Practice by Matt Zandstra; Apress Publishing.
The Object Oriented Thought Process by Matt Weisfeld; Sams Publishing.
The Pragmatic Programmer by Andrew Hunt and David Thomas.
By: Danny Cassidy
** This article may not be reproduced without the owner's (Danny.VBT) permission.
Introduction
Hypothetically, let's imagine that vBulletin just released version 4.0. They announce that the entire back-end architecture has changed and now you must update your quite large and complex modification to support their new code changes because your users (clients) are demanding functionality for vB 4.0
This definitely means hours of inspecting and altering thousands of lines of code, right?
Not if you use implement the Facade pattern!
The Facade Pattern? What?s that?
The Facade Pattern is a design pattern that introduces a whole lot of benefits when dealing with third party code that you have no control over. In short, it acts as a tier between your modification and vBulletin.
Now, you may be asking: But my modification is designed specifically for vBuleltin, why would I want to separate them?
Reasons for Utilizing the Facade Pattern
Encapsulation - encapsulating essentially hides an implementation of a certain method from client code.Take the following example: I want to determine if a user has permission to do a certain action. Normally, you would simply have:
if(!($permissions['myhackpermissions'] & $vbulletin->bf_ugp['myhackpermissions']['candosomething']))
{
print_no_permission();
}
If wrapped in a facade class, you would have something like:
if(!$this->bridge->permission(?candosomething?))
{
// User doesn't have permission
}See how simple that looks? The actual implementation of the permission checking would be in the facade class, but it is only the interface that matters. Now instead of sprinkling vBulletin version specific code throughout your system, you are only providing an interface to that specific implementation.
So what happens when vBulletin releases a new major version and the implementation changes? That brings us to our next reason.
Inheritance - Inheritance provides a way to avoid code duplication and get the most of encapsulation.Let us go back to the previous permission example. Here is the implementation of the permission method:
class facade
{
function facade()
{
// Some required initialization for vBulletin backend and global variables.
}
function permission($option)
{
// Ternary for readability purposes only...
return ($permissions[PRODUCT_ID . ?permissions?] & $vbulletin->bf_ugp[PRODUCT_ID . ?permissions?][$option]) ? true : false;
}
} This class is a simple facade with a permission method to encapsulate the data. Now pretend vBulletin 4.0 is released and the entire permission handling is now altered. Instead of having to go through all the hassle of finding and editing the version specific code throughout your modification, you can simple utilize inheritance to update the methods that need to be altered.
class facade_40 extends facade
{
function permission($option)
{
// 4.0 specific permission handling
}
}Then at the start of the client code you can determine which class to create:
if ( //vBulletin version == 4.0 )
{
$this->bridge = new facade_40()
}
else {
$this->bridge = new facade();
}
// Code code code.....
if($this->bridge->permission('candosomething'))
{
//More code
}
The example above would normally be a little more dynamic. Listed in the suggested readings below, PHP 5 Objects, Design and Practice list some patterns that help with object generation.
The point of the example is that the code above does not care if $this->bridge is facade or facade_40...the code will continue to function as long as the interface remains. This is an integral concept of OO programming called Polymorphism.
When an upgrade of vBulletin requires that you alter your code, you no longer have to update every single file with the new implementation: Just extend your facade class and add support for proper object generation based on vBulletin version; ultimately saving time from tedious code alterations when you could be adding new, exciting features to your modification.
Implementing a Facade
Utilizing the facade pattern is not always the best choice. If you are only create a small modification with only a few files or whatnot, it may not be worth the time to design your application around a facade. However, if your modification has more than a handful of files with thousands if not hundred of thousands lines of code, the facade pattern may be a huge time saver for you in the future.
Global Variables - Due to the architecture of vBulletin, with a facade type implementation, you may have to globalize some of the default variables that run across vBulletin such as $vbulletin, $phrase, $style, $permissions ...etc...etc...This type of initialization of global variables will most likely be done within the constructor or initialization function.
As with any global variables, you must take good note not to override any essential data.
Object Oriented Approach - The Facade pattern requires the use of classes and objects to gain the benefits of encapsulation, inheritance, and composition.Implementing a facade would require more than one class, so it important that you fully understand OO before implementing any type of design pattern. Do not just use OO because it seems popular to do.
Conclusion
I left this article abstract for a reason. I don?t want to provide code to mimic or to copy and paste, but to allow those who unsure or unfamiliar with object oriented programming to see the benefits of OO even with just vBulletin modifications. Take the time to research and understand Object Orientation and it will be extremely beneficial to you in the future.
Suggested Readings:
PHP 5 Objects, Designs, and Practice by Matt Zandstra; Apress Publishing.
The Object Oriented Thought Process by Matt Weisfeld; Sams Publishing.
The Pragmatic Programmer by Andrew Hunt and David Thomas.
By: Danny Cassidy