1

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.)

Improve this question
18
  • Correct me if I am wrong, but if you call IDocument.Save you could return an IDocument, right? This could simply be a decorator which decorates your original object. When calling IDocument.Method1 the decorator forwards the call to your original object.
    – Paul Kertscher
    Commented Jan 14, 2015 at 9:51
  • 2
    Please Note: If the object contains many virtual methods it may be doing too much and violates the 'Single responsibility principle'. You should have a look at the SOLID principles.
    – Paul Kertscher
    Commented Jan 14, 2015 at 9:53
  • Anyway, I did not relly get why you need the functionality you described, but I am very curious. Would you be so kind and eyplain the ratio behind your architecture?
    – Paul Kertscher
    Commented Jan 14, 2015 at 9:54
  • 1
    @IanGoldby In a statically typed language, there is no other choice than using reflection to automatically delegate the methods to the inner object without having to write each of the methods per hand. Your question is therefore not language agnostic, please remove this tag.
    – valenterry
    Commented Jan 14, 2015 at 12:07
  • 1
    @Hey yes, because with reflection you can exchange the classloader and therefore remove and reload a class (with different methods). This is of course very dirty, but possible.
    – valenterry
    Commented Jan 14, 2015 at 13:21

1 Answer 1

Reset to default
2

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.

Improve this answer
1
  • Thanks for mentioning the Bridge pattern. The State pattern is another similar solution. But to do it using only features available in any OO language and without forwarding methods, either a real out-of-the-box idea is needed, or it is simply not possible.
    – Ian Goldby
    Commented Jan 15, 2015 at 8:23

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.