Twin pattern
In software engineering, the Twin pattern is a software design pattern that allows developers to model multiple inheritance in programming languages that do not support multiple inheritance. This pattern avoids many of the problems with multiple inheritance.[1]
Definition
Instead of having a single class which is derived from two super-classes, have two separate sub-classes each derived from one of the two super-classes. These two sub-classes are closely coupled, so, both can be viewed as a Twin object having two ends.[1]
Applicability
The twin pattern can be used:
- to model multiple inheritance in a language in which multiple inheritance is not supported
- to avoid some problems of multiple inheritance.[1]
Structure
There will be two or more parent classes which are used to be inherited. There will be sub-classes each of which is derived from one of the super-classes. The sub-classes are mutually linked via fields, and each sub-class may override the methods inherited from the super-class. New methods and fields are usually declared in one sub-class. [1]
The following diagram shows the typical structure of multiple inheritance:
![Typical multiple inheritance](http://upload.wikimedia.org/wikipedia/commons/c/ce/T%C3%B6bbsz%C3%B6r%C3%B6s_%C3%B6r%C3%B6kl%C3%A9s_%28iker_minta_n%C3%A9lk%C3%BCl%29.png)
[1]
The following diagram shows the Twin pattern structure after replacing the previous multiple inheritance structure:
![Twin pattern](http://upload.wikimedia.org/wikipedia/commons/2/28/Iker_minta.png)
[1]
Collaborations
Each child class is responsible for the protocol inherited from its parent. It handles the messages from this protocol and forwards other messages to its partner class. [1]
Clients of the twin pattern reference one of the twin objects directly and the other via its twin field.[1]
Clients that rely on the protocols of parent classes communicate with objects of the respective child class.[1]
Sample code
The following code is a sketched implementation of a computer game board with moving balls.
Class for the game board:
public class Gameboard extends Canvas { public int width, height; public GameItem firstItem; … }
[1]
Code sketch for GameItem class:
public abstract class GameItem { Gameboard board; int posX, posY; GameItem next; public abstract void draw(); public abstract void click (MouseEvent e); public abstract boolean intersects (GameItem other); public abstract void collideWith (GameItem other); public void check() { GameItem x; for (x = board.firstItem; x != null; x = x.next) if (intersects(x)) collideWith(x); } public static BallItem newBall(int posX, int posY, int radius) { //method of GameBoard BallItem ballItem = new BallItem(posX, posY, radius); BallThread ballThread = new BallThread(); ballItem.twin = ballThread; ballThread.twin = ballItem; return ballItem; } }
[1]
Code sketch for the BallItem class:
public class BallItem extends GameItem { BallThread twin; int radius; int dx, dy; boolean suspended; public void draw() { board.getGraphics().drawOval(posX - radius, posY - radius, 2 * radius, 2 * radius); } public void move() { posX += dx; posY += dy; } public void click() { if (suspended) twin.resume(); else twin.suspend(); suspended = ! suspended; } public boolean intersects (GameItem other) { if (other instanceof Wall) return posX - radius <= other.posX && other.posX <= posX + radius || posY - radius <= other.posY && other.posY <= posY + radius; else return false; } public void collideWith (GameItem other) { Wall wall = (Wall) other; if (wall.isVertical) dx = - dx; else dy = - dy; } }
[1]
Code sketch for BallThread class:
public class BallThread extends Thread { BallItem twin; public void run() { while (true) { twin.draw(); /*erase*/ twin.move(); twin.draw(); } } }
[1]
Implementation of the Twin pattern
The following issues should be considered:
- Data abstraction - partner classes of the twin class have to be tightly coupled, as probably they have to access each other private fields and methods. In Java, this can be achieved by placing the partner classes into a common package and providing package visibility for the required fields and methods. In Modula-3 and in Oberon, partner classes can be placed in a common module.
- Efficiency - Since the Twin pattern uses composition which requires message forwarding, the Twin pattern may be less efficient than inheritance. However, since multiple inheritance is slightly less efficient than single inheritance anyway, the overhead will not be a major problem.[1][2]
- Cyclic reference - The Twin pattern relies on each twin referencing the other twin, which causes a cyclic reference scenario. Some languages may require such cyclic references to be handled specially to avoid a memory leak. For example, one reference may need to be made 'weak' to allow the cycle to break.
See also
- Adapter Pattern, specially Two-Way-Adapter
References
- ^ a b c d e f g h i j k l m n Mössenböck, H., Twin - A Design Pattern for Modelling Multiple Inheritance, University of Linz, Institute for System Software
- ^ Stroustrup, B. (May 1989), Multiple Inheritance for C++, Helsinki: Proceeding EUUG Spring Conference
- v
- t
- e
patterns
Creational |
|
---|---|
Structural |
|
Behavioral |
patterns
patterns
patterns
- Christopher Alexander
- Erich Gamma
- Ralph Johnson
- John Vlissides
- Grady Booch
- Kent Beck
- Ward Cunningham
- Martin Fowler
- Robert Martin
- Jim Coplien
- Douglas Schmidt
- Linda Rising