The Strategy design pattern is aimed squarely at this problem. The same task is repeated over and over (generating some links) because something minor changes each time (the links themselves). Following the pattern, we can isolate the bits that change into individual strategies, leaving the bit of code which doesn't change alone to do what it does.
It might look something like this in your case:
// The strategy base class
// Methods common to all strategies go here
class NavigationStrategy
{
function getLinks()
{
return $this->links;
}
}
// Admin navigation strategy
// The variable part of the code is abstracted here
class AdminNavStrategy extends NavigationStrategy
{
var $links = array (
'Link 1' => 'link1.php',
'Link 2' => 'link2.php',
);
}
// Business navigation strategy
class BusinessNavStrategy extends NavigationStrategy
{
var $links = array (
'Link 3' => 'link3.php',
'Link 4' => 'link4.php',
);
}
// The client code which wants to know what links to display
class Navigation
{
// A strategy object
// We don't care what subtype it is, just that it extends the NavigationStrategy object
var $strategy;
function navigation( &$strategy )
{
$this->strategy =& $strategy;
}
// This method works for all strategy objects, regardless of subtype
function generateLinks()
{
foreach( $this->strategy->getLinks() as $name => $url )
{
$html .= "<li> .. etc .. </li>";
}
return $html;
}
}
// Using the classes
switch( $group )
{
case 1:
$strategy =& new AdminNavStrategy();
break;
case 2:
$strategy =& new BusinessNavStrategy();
break;
default:
InvalidGroupErrorOrSomesuch();
}
$nav =& new Navigation( $strategy );
$links = $nav->generateLinks();
Might seem a little daunting if your not used to dealing with objects and classes, but it's really not so bad. The useful thing here would be avoiding code duplication and allowing adding of new 'link groups' easily, for example if you want a super administrator navigation you'd just create a SuperAdminNavStrategy class and add the links, create a new clause in the switch and away you go.
