AbstractDevicePattern.ppt

Abstract Device Pattern The AIM : Share as many device servers and clients as possible The HOW : Each device class belongs to a device family. Each device family has a standard interface which all members MUST implement. Device class can extend the standard interface with private additions. The Patterns The Abstract Factory Pattern says : Provide an interface for creating families of related or dependent objects without specifying their concrete classes. (Vlissides et. Al) The Abstract Device Pattern says : Provide an interface for creating families of devices which represent related devices without specifying their concrete implementation e.g. Motor, PowerSupply, FunctionGenerator etc. (G?tz et. Al.) The UML Diagram The Abstract Class A standard TANGO device class, generated by pogo Defines only the interface Does NOT implement any code (except that generated by pogo) Command and Attribute methods (read_my_attr() and write_my_attr()) are defined as pure virtual methods The Concrete Class Derives from the Abstract class Implements the commands and attributes specified by the Abstract class Can extend the basic interface by adding its own commands and attributes Sets the default attribute properties e.g. min and max How to abstract a device include only the main features which best represent the members of the superclass do not get bogged down in detail, if you find the discussion is taking too long stop it if in doubt, throw it out the important thing is to arrive at a result a bad abstract device class will eventually be replaced by a better one Example - Signal Generator Example – Motor Example – Ccd Conclusion The Abstract Device Pattern encourages device class and client sharing POGO needs to be modified to support the Abstract Device Pattern All device class should adopt this method because every device class belongs to a family The method needs to be adapted for Java The goal is to arrive at a complete Abstract Control System i.e. an interface for e