Module inheritance structure
Posted: Thu Feb 08, 2007 9:10 pm
When a class becomes monolithic, it makes sense to split it up into modules, so that file sizes are cut down and things are more manageable.
What's been happening, however, is that the modules are starting to look like tiny versions of the main component their part of:
Emphasis on like. They are by no means identical. HTMLDefinition has methods and variables that HTMLModule doesn't, and vice versa. There are also some subtle inconsistencies between similarly named variables (see $content_sets). The mechanism, however, is simply merging the functionality of the module into the main definition, using array_merge, $a + $b, etc.
Nonetheless, I'm starting to smell code duplication. So I'm wondering:
What's been happening, however, is that the modules are starting to look like tiny versions of the main component their part of:
Code: Select all
class HTMLDefinition
{
var $info = array();
var $info_attr_transforms = array();
var $content_sets; // contains an object
function setup() {} // unique
}
class HTMLModule
{
var $info = array();
var $info_attr_transforms = array();
var $content_sets = array(); // NOT an object, but rather HTMLDefinition->content_sets->info
// note no setup() function implemented
var $variable_only_for_module;
}Nonetheless, I'm starting to smell code duplication. So I'm wondering:
- Is my interpretation of the "Parent" and "Module" idea the standard one? Or am I using bad terminology? (this method is nice because, although after you merge the modules together you really can't edit anything anymore, it's very fast)
- Does it make sense for Module to inherit from the greater functionality it's part of?