Module inheritance structure

Not for 'how-to' coding questions but PHP theory instead, this forum is here for those of us who wish to learn about design aspects of programming with PHP.

Moderator: General Moderators

Post Reply
User avatar
Ambush Commander
DevNet Master
Posts: 3698
Joined: Mon Oct 25, 2004 9:29 pm
Location: New Jersey, US

Module inheritance structure

Post 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?
User avatar
Maugrim_The_Reaper
DevNet Master
Posts: 2704
Joined: Tue Nov 02, 2004 5:43 am
Location: Ireland

Post 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...
User avatar
Jenk
DevNet Master
Posts: 3587
Joined: Mon Sep 19, 2005 6:24 am
Location: London

Post 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.
User avatar
Christopher
Site Administrator
Posts: 13596
Joined: Wed Aug 25, 2004 7:54 pm
Location: New York, NY, US

Post 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.
(#10850)
User avatar
daedalus__
DevNet Resident
Posts: 1925
Joined: Thu Feb 09, 2006 4:52 pm

Post 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...
User avatar
Ollie Saunders
DevNet Master
Posts: 3179
Joined: Tue May 24, 2005 6:01 pm
Location: UK

Post 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?
User avatar
Ambush Commander
DevNet Master
Posts: 3698
Joined: Mon Oct 25, 2004 9:29 pm
Location: New Jersey, US

Post 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.
User avatar
daedalus__
DevNet Resident
Posts: 1925
Joined: Thu Feb 09, 2006 4:52 pm

Post by daedalus__ »

ole wrote:Daedalus, what?
Never mind me. :)
Post Reply