Page 1 of 1

Module inheritance structure

Posted: Thu Feb 08, 2007 9:10 pm
by Ambush Commander
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:

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;
}
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:
  • 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?

Posted: Fri Feb 09, 2007 3:25 am
by Maugrim_The_Reaper
It looks like you've extracted specific tasks into separate classes. So although each has a distinct role they all also (given it was extracted) have some common thread. The question I'd ask is whether than common thread really rates as code duplication. Assuming you're examples are the norm (not more than a few lines of common code) then I'm not sure I'd call it code duplication per se. You can only refactor along those lines so much before you hit diminishing returns. If you can only extract a few variables I wouldn't bother...

Posted: Fri Feb 09, 2007 5:08 am
by Jenk
Without seeing more detail (which I'm not requesting, btw) I'd be tempted to make it an abstract HTML class, then extend for HTMLDefinition and HTMLModule:

Code: Select all

class HTMLAbstract
{
  var $info;
  var $info_attr_transforms;
  var $content_sets;
}

// definitions are completed in child class constructors.
Though whether it is worth abstracting for the sake of 3 properties is, I guess, what this thread is about.

Posted: Fri Feb 09, 2007 12:12 pm
by Christopher
I am really not clear how you are using "monolithic", "module" and "parent" in this case. And it is not clear whether inheritance or composition would be a better direction. Are $info and $info_attr_transforms simple properties of objects or are they common values that should be shared by many/all or many objects. And the overloading of $content_sets smells like a shortcut trick.

Posted: Fri Feb 09, 2007 12:49 pm
by daedalus__
I've done this before:

Code: Select all

class Template
{
     // buloolululuooloolooloooo making template for you to viewwwwww
}

class View extends Template
{
     // buloolululuooloolooloooo contains methods to make viewwwwwww
}

class Module extends View
{
     // buloolululuooloolooloooo specific to current action, oooooooohhh
}
You get the idea...

Posted: Fri Feb 09, 2007 3:49 pm
by Ollie Saunders
Daedalus, what?

AC, just so I can be clear, what exactly is the purpose of these classes? oh and what ever happened to CamelCaps?

Posted: Fri Feb 09, 2007 6:27 pm
by Ambush Commander
It looks like you've extracted specific tasks into separate classes. So although each has a distinct role they all also (given it was extracted) have some common thread. The question I'd ask is whether than common thread really rates as code duplication. Assuming you're examples are the norm (not more than a few lines of common code) then I'm not sure I'd call it code duplication per se. You can only refactor along those lines so much before you hit diminishing returns. If you can only extract a few variables I wouldn't bother...
Good point. Goes hand in hand with the statement: First time you need to do something, do it. Second time, do it, but take note. Third time, refactor! But three properties is indeed at the magic number, hmm.
Though whether it is worth abstracting for the sake of 3 properties is, I guess, what this thread is about.
I'll spare you the details, but there will be about seven duplicated properties once I finish adding some new functionality, any more than that is not likely but not totally out of the question.
I am really not clear how you are using "monolithic", "module" and "parent" in this case.
Monolithic - extremely large and difficult to modify. A 15kb file that contains only one method used for constructing a fairly complex object is monolithic.

Module - a representation of a certain set of functionality that can be easily plugged in or out of the full schema object. In this case, our modules correspond to the modules defined by XHTML modularization.

Parent - yeah, that was ambiguous, I'm referring to the overall object that is composed of the modules
And it is not clear whether inheritance or composition would be a better direction. Are $info and $info_attr_transforms simple properties of objects or are they common values that should be shared by many/all or many objects.
They are sort of shared. You see, the code that interfaces with the overall definition doesn't actually use the modules: for our purposes, the modules are smooshed into one big definition after preliminary setup is done. This is for performance reasons.
And the overloading of $content_sets smells like a shortcut trick.
It is. But it's essential for what I'm trying to do.
I've done this before
Ehhh???
AC, just so I can be clear, what exactly is the purpose of these classes?
HTMLDefinition is a general-purpose class that contains information about HTML. What type of information you say? Many things: allowed elements, allowed attributes of these elements, filters that need to be done on these elements, elements that are allowed inside those elements (content models), etc... HTMLDefinition is also responsible for merging in the HTMLModule's and converting their format into another one that is relatively fast to access.

HTMLModule is a sort of mini-HTMLDefinition that defines this information for a smaller scope: while HTMLDefinition would define element definitions for all alowed elements, a Hypertext HTMLModule would only do so for the <a> tag.
oh and what ever happened to CamelCaps?
:oops: I forgot. By the time I caught it, there was a lot of code interfacing with the variables, so I decided it would be better to be consistent.

Posted: Fri Feb 09, 2007 11:18 pm
by daedalus__
ole wrote:Daedalus, what?
Never mind me. :)