Design pattern for scenario where we need to expand functionality in future.
I have a simple question related to Design Patterns. Suppose I have a class of TOY and object of this class moves based on instructions. Currently this class support only two types of instructions i.e. MoveForward and TurnLeft. In future there will be more type of instructions (like TurnRight, MoveBackwards etc). I need to implement this functionality using design pattern so that in future it would be easier to expand functionality. Which design pattern is suitable for this and why?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Do you see one of those that speaks to your question?
>> In future there will be more type of instructions (like TurnRight, MoveBackwards etc).
This is a fairly vague specification, exactly what constitutes an instruction? By instructions do you mean a method (a code construct) defined on the TOY class or object?
If you are considering a data-driven design where for example instructions are read from files then you can design the system like a virtual machine. The interpreter pattern would be a good choice, along with the command pattern.
However, it would be important to consider how TurnLeft works internally. Does it utilize micro-instructions internally? Does it use a language such that it is possible to write instructions in that language? An example would explain
TurnLeft.txt
setrotationaxis Z
rotate -90 // think of it as assembly
TurnRight() could then be implemented in terms of the micro language. I have deliberately used TurnLeft.txt as a filename to give a hint that the instructions are external and the TOY object is flexible because any new instruction can be defined in data with using only the micro-language.
You can find numerous examples on how to use Interpretter pattern and/or implement simple stack machines or virtual machines.
This is a fairly vague specification, exactly what constitutes an instruction? By instructions do you mean a method (a code construct) defined on the TOY class or object?
If you are considering a data-driven design where for example instructions are read from files then you can design the system like a virtual machine. The interpreter pattern would be a good choice, along with the command pattern.
However, it would be important to consider how TurnLeft works internally. Does it utilize micro-instructions internally? Does it use a language such that it is possible to write instructions in that language? An example would explain
TurnLeft.txt
setrotationaxis Z
rotate -90 // think of it as assembly
TurnRight() could then be implemented in terms of the micro language. I have deliberately used TurnLeft.txt as a filename to give a hint that the instructions are external and the TOY object is flexible because any new instruction can be defined in data with using only the micro-language.
You can find numerous examples on how to use Interpretter pattern and/or implement simple stack machines or virtual machines.
Visitor pattern:
Purpose: add new operations to stable class hierarchy without changing classes.
Purpose: add new operations to stable class hierarchy without changing classes.
Essential Software Design Patterns
http://wwwipd.ira.uka.de/~tichy/patterns/overview.html
Purpose: separate composition of a request from the time it is executed.
Flexibility: multiple commands; add functionality such as undo/redo, scheduling.
Implementation: encapsulate command with additional state (the object(s) on which to operate); add command processor.
Purpose: pass a request down a chain of objects until an object handles it.
Flexibility: a) decoupling: handler of request is not known a priori (determined dynamically); b) extensibility: add new handlers.
Implementation: common interface for handlers, delegation along chain.
Purpose: add new operations to stable class hierarchy without changing classes.
Flexibility: a) decouple operations that exist in variants for many classes from those classes; b)extensibility: add new operations.
Implementation: common accept interface in classes; methods for all classes in visitor.
Variations:
Default Visitor
Extrinsic Visitor
Acyclic Visitor