Design Patterns – How to Add Functionality to an Existing Object

adapterdesign-patternsobject-oriented

I have an interface that has a certain amount of well-defined functionality. Let's say:

interface BakeryInterface {
  public function createCookies();
  public function createIceCream();
}

This works well for most implementations of the interface, but in a few instances, I need to add some new functionality (like perhaps rolled into a new method, createBrownies()). The obvious/naive approach to doing this would be to extend the interface:

interface BrownieBakeryInterface extends BakeryInterface {
  public function createBrownies();
}

But has a pretty big downside in that I can't add the new functionality without modifying the existing API (like changing the class to use the new interface).

I was thinking about using an adapter to add the functionality after instantiation:

class BrownieAdapter {
  private brownieBakery;

  public function construct(BakeryInterface bakery) {
    this->brownieBakery = bakery;
  }

  public function createBrownies() {
    /* ... */
  }
}

Which would net me something like:

bakery = new Bakery();
bakery = new BrownieBakery(bakery);
bakery->createBrownies();

This seems like a good solution to the problem, but I'm wondering if I'm awakening the old gods by doing it. Is the adapter the way to go? Is there a better pattern to follow? Or should I really just be biting the bullet and just extending the original interface?

Best Answer

Any of the Handle Body patterns could fit the description, depending on your exact requirements, language, and needed level of abstraction.

The purist approach would be the Decorator pattern, which does exactly what you are looking for, dynamically add responsibilities to objects. If you are actually building bakeries, it's definitely overkill and you should just go with Adapter.

Subtyping

It is valid to use subtyping to add methods, provided you are keeping the SOLID principles in mind. Therefore, you might consider extending the concrete object to support methodB and then design the decorator around it.

AbstractObject object = new ExtendedConcreteObject();
object.methodA(); // does stuff
object = new ConcreteDecorator(object);
(ConcreteDecorator)object.methodB();
// methodB() belongs to ExtendedConcreteObject() but not to AbstractObject()

Adapter Pattern

Another way to view the problem: by adding a public method, you are changing the object's interface. This can be done by using the adapter pattern. To keep the concrete decorator simple, you might consider creating a decorator and then building an adapter for that decorator.

AbstractObject object = new ConcreteObject();
object.methodA(); // does stuff
object = new ConcreteDecorator(object);
object = new ConcreteAdapter(object);
(ConcreteAdapter)object.methodB();
// methodB() belongs to ConcreteAdapter() but not to AbstractObject() or ConcreteDecorator().

Java Design – How to Create a Menu for Easy Addition of New Options

Proposed design:

You could use the command pattern:

A command interface defines the methods related to a menu option (i.e. command). The most important method here is optionAction() (corresponds to the execute() method of the pattern).
Concrete commands are classes that implement this interface : optionAction() is overridden to define the actions that shall be executed for a specific command.
When concrete commands are instantiated by a client (your main() ?), a reference to a receiver object is stored. That object will be used to execute the action later.
A specific concrete command class implements a menu loop as action. But instead of hard-coding every different submenu in its own class, use a single SubmenuCommand class, the instances of which will refer to a menu object that has a list of options (commands).
The invoker will execute the created commands when needed. In your case, you could simplify the invoker: your main() would somehow invoke the command corresponding to the toplevel menu. And this one would invoke the chosen commands.

Variants of this design:

The menu objects could be constructed during initialization. Typically, you'd use the builder pattern to initialize each menu programatically. Then it could make sense to use optionTitle().

However, you could also load the menu from a configuration file. In this case, the optionTitle() would be useless: you'd read that title from the configuration file (with flexibility to customize the text, and even possibility to localize/translate the menus). In principle you'd do that in the the director of the builder, but if you want also to configure other commands, a factory method pattern could be considered as well.

If you opt for the dynamically load of menus, there are a couple of delicate points to handle:

first you need to link you text of menus with command classes. Either you use reflection to identify the right classes by name, or -- much simpler -- you use a map that links keywords corresponding to commands to class specific factories (the map would be static, and initialized before the config file is parsed).
dependencies between menus: the simplest way would be to organize your menus in bottom up order, so to be sure that a menu is always loaded/created before it is referred to in other menus. Similarly to command classes, you'd also have a map of menus (the map would be dynamic, and populated as new menus are loaded : the menu structure could hence be totally dynamic and reconfigurable).

Wrap up:

Here a simplified class model that shows the general structure. I leave however the client, the invoker, the director and the builder out of this figure, as it depends very much on the rest of your application:

Best Answer

Related Solutions

Object-oriented – Using the Decorator pattern to add public methods to an object

Subtyping

Adapter Pattern

Java Design – How to Create a Menu for Easy Addition of New Options

Related Topic