Question

I have a base object (form_field_base) that is extended/inherited by other objects in the form of:

class form_field_base {
    // Lots of code
}
class form_field_text extends form_field_base {
    // Lots of code
}
class form_field_email extends form_field_text {
    // Extending the text object to update validation, and set input type="email"
}
class form_field_file extends form_field_base {
    // Lots of code, for example uploading files
}

The “form_field_base” provides helper methods that all of the form field types use, for example a html() function calls the specific object (form_field_email::html_input) to get the field, then put that in a string with the standard tag, etc.

All of these objects are used by many projects.

However, this latest project I’m working on requires the “form_field_base” object to be customised to allow the setting of some help text, a feature that no other project requires, and if future projects do, it will probably be done differently.

So how should this have be organised?

Ideally I won’t have a complete copy of “form_field_base”, as that would cause code duplication.

And it does seem like quite a bit of overhead to have dummy intermediate objects:

class form_field_base_common {
    // Lots of code
}
class form_field_base extends form_field_base_common {
    // By default is empty
}

class form_field_text_common extends form_field_base {
    // Lots of code
}
class form_field_text extends form_field_text_common {
    // ...
}

class form_field_email_common extends form_field_text {
    // Extending the text object to update validation, and set input type="email"
}
class form_field_email extends form_field_email_common {
    // ...
}

class form_field_file_common extends form_field_base {
    // Lots of code, for example uploading files
}
class form_field_file extends form_field_file_common {
    // ...
}

Taking that each one has it’s own file, which is auto-loaded (either a from a project specific location, if it exists, or from a common folder that all projects can access)… that is already 8 files that need to be found, opened, parsed, etc, just for supporting a form.

Surly there has to be a better way?

Answer 1

You have your inheritance chain and you want to modify the base implementation on a per project base while still keeping the common code and types (and not being forced to severely modify the existing projects).

The way to go is to decouple the common functionality from project specific customizations. Use the decorator pattern which even enables you to share customizations between projects.

You situation is for all existing projects:

A <- B <- C

A->a()
B->a(), B->b()
C->a(), C->b(), C->c()

Your new project (lets say project 1) shall have:

A1 <- B <- C

A1->a(), A1->a1(),
B->a(), B->a1(), B->b()
C->a(), C->a1(), C->b(), C->c()

The decorator pattern requires you to create a decorator for each object you want to extend (A1, B1, C1). You want the custom methods of A1 also available in your decorating B1 and C1, so you need to chain them the same way as the original classes.

A1 decorates A
B1 decorates B
C1 decorates C

A1 <- B1 <- C1

A1->a1()
B1->a1()
C1->a1()

You still want the functionality of A, B, C also in your decorating classes, so you need to create a link between each decorator and its decorating source class and delegate the appropriate methods:

A1 hosts a reference of A
B1 hosts a reference of B
C1 hosts a reference of C

A1->a() ----> $this->myA->a();
B1->a() ----> $this->myB->a();
B1->b() ----> $this->myB->b();

All custom project 1 methods are executed directly:

A1->a1() ----> $this->a1();

In your new project 1 you use then:

A1 instead of A
B1 instead of B
C1 instead of C

Your A1, B1 and C1 may be allowed to create their instances of A, B, C right in their constructor although you could pass the instances to enable multiple decorations. In that case you will need proper interfaces, lets say IA, IB, IC. Then your A1 could have the method setA(IA theA) where theA might be an exact A or even an A1 or A2 or A3 … But this is more advanced and you will find more information by googling the decorator pattern and you perhaps need a little bit of experience with interfaces and polymorphy.

---

Altogether:

1. Leave your inheritance chain as it is

2. Create a decorator chain for each custom project

3. Link the decorators to their original class and delegate the common functionality.

4. Use the decorators instead of the original classes in your custom project. They are now identical to their originals plus have the additional methods you want to add.