Changing an object’s (apparent) class at runtime

design-patternslanguage-agnostic

I'm looking for a design pattern to solve the following problem:

An object (let's say representing a document) can change its type dynamically during its lifetime (e.g. when it is saved with a different file extension).

The object contains many virtual methods so that depending on the object type it can behave in different ways (e.g. different syntax highlighting).

The application contains many references to the object, which should not become invalid when the object's type changes. So it won't do to destroy the object and create a new one of the new type.

An 'obvious' solution is to use composition, so that the object seen by the application (the outer object) never changes, but it forwards all calls to a contained object that can be destroyed and recreated whenever the type changes.

But this requires a method in the outer object for each virtual method in the contained object to forward the call.

Is there a design pattern that avoids this need for forwarding methods?

(Ideally I'd like a pattern that doesn't require the language to support interfaces.)

Update

Thanks to comments below, I've identified that the State design pattern implements what I want, except that it requires explicitly forwarding every method from the wrapper class to the wrapee class.

So another (perhaps clearer?) way of stating my original question is this: Is there an alternative design pattern that implements the functionality of the State design pattern in (virtually) any object oriented language without needing explicitly to forward every method?

('No' is a perfectly valid answer by the way as long as you can justify it.)

Best Answer

The solution you describe in your question is usually called the "bridge pattern". Depending on the language in use, there may be a way of implementing it without manually managing all the delegating methods. For example, in Ruby one can simply define the "method_missing" method to perform a dynamic lookup on the target object and dispatch to a method with the same name as the called method. In Java you may be able to use a bytecode generation library to achieve a similar effect, e.g Javassist.

Related Solutions

C# Design Patterns – Using Abstract Base Class with Interfaces as Behaviors

[1] Add virtual "getters" & "setters" to your properties, I had to hack another control library, because I need this feature:

abstract class Control
{
    // internal fields for properties
    protected int _Width;
    protected int _Height;
    protected int _BackColor;
    protected int _X;
    protected int _Y;
    protected bool Visible;

    protected int BorderWidth;
    protected int BorderColor;


    // getters & setters virtual !!!

    public virtual int getWidth(...) { ... }
    public virtual void setWidth(...) { ... }

    public virtual int getHeight(...) { ... }
    public virtual void setHeight(...) { ... }

    public virtual int getBackColor(...) { ... }
    public virtual void setBackColor(...) { ... }

    public virtual int getX(...) { ... }
    public virtual void setX(...) { ... }

    public virtual int getY(...) { ... }
    public virtual void setY(...) { ... }

    public virtual int getBorderWidth(...) { ... }
    public virtual void setBorderWidth(...) { ... }

    public virtual int getBorderColor(...) { ... }
    public virtual void setBorderColor(...) { ... }

    public virtual bool getVisible(...) { ... }
    public virtual void setVisible(...) { ... }

    // properties WITH virtual getters & setters

    public int Width { get getWidth(); set setWidth(value); }

    public int Height { get getHeight(); set setHeight(value); }

    public int BackColor { get getBackColor(); set setBackColor(value); }

    public int X { get getX(); set setX(value); }

    public int Y { get getY(); set setY(value); }

    public int BorderWidth { get getBorderWidth(); set setBorderWidth(value); }

    public int BorderColor { get getBorderColor(); set setBorderColor(value); }

    public bool Visible { get getVisible(); set setVisible(value); }

    // other methods

    public Rectangle ClipRectange { get; protected set; }   
    abstract public void Draw();
} // class Control

/* concrete */ class MyControl: Control
{
    public override bool getVisible(...) { ... }
    public override void setVisible(...) { ... }
} // class MyControl: Control

I know this suggestion is more "verbose" or complex, but, its very useful in real world.

[2] Add an "IsEnabled" property, do not confuse with "IsReadOnly":

abstract class Control
{
    // internal fields for properties
    protected bool _IsEnabled;

    public virtual bool getIsEnabled(...) { ... }
    public virtual void setIsEnabled(...) { ... }

    public bool IsEnabled{ get getIsEnabled(); set setIsEnabled(value); }
} // class Control

Means you may have to show your control, but don't show any information.

[3] Add a "IsReadOnly" property, do not confuse with "IsEnabled":

abstract class Control
{
    // internal fields for properties
    protected bool _IsReadOnly;

    public virtual bool getIsReadOnly(...) { ... }
    public virtual void setIsReadOnly(...) { ... }

    public bool IsReadOnly{ get getIsReadOnly(); set setIsReadOnly(value); }
} // class Control

That means the control can display information, but cannot be changed by the user.

Architecture – Coupling business logic with class definitions

First, what you are describing sounds quite a lot like functional approach to things. Separating data and functions operating on those data is modus operandi of all functional language. Try looking at Haskell for inspiration.

Second thing that I see is that you seem to lack concept of abstraction. If you have identified multiple classes, which have same or similar behavior, it should be your top priority to refactor this behavior into a reusable form in either inheritance or composition. This is actually the hardest part of software and OO design.

And why is separation of data and behavior frowned upon in OO design? First, encapsulation. Making sure there is only limited scope, which can access and change a state, simplifies reasoning about code, because you don't have to worry about variables changing without your knowledge. By having outside functions access this data, it means encapsulation is broken. Second are virtual methods. Virtual methods are ways to achieve late binding in OO languages. You cannot have virtual methods if they are not parts of the class.

And last thing, every time I see someone talking about OO design, I cannot help myself and link to this excersise.

And some final words: Just because some approach might seem simple and straightforward on simple and straightforward example doesn't mean it will work on complex and huge example. Try applying your approach to project which has thousands of classes with millions of functions and extremely complex business logic. You will soon realize it is far from simple.

Best Answer

Related Solutions

C# Design Patterns – Using Abstract Base Class with Interfaces as Behaviors

Architecture – Coupling business logic with class definitions

Related Topic