BRAD@UMDB.BITNET.UUCP (06/03/87)
In the discussion of implementing a class of objects as either a generic finite state machine package (with no generic formal parameters) or as an abstract data type package, I see the following tradeoffs. (sorry that I can't reproduce the code, but I'm sending from a brain-damaged IBM 4341...) Generic package encapsulating a finite state machine (FSM): This is very much in line with the Simula and Smalltalk approach for creating a class of objects. Each instance of the class (here, each instantiation of the generic) actually encapsulates both the state information i.e. the values on the stack and the stack attributes; and also encapsulates the operations on the object, i.e. push, pop, etc. This promotes abstraction, information hiding, modularity, uniformity, etc. But, there is one difference from the Simula/Smalltalk model in that the class (collection) is anonymous. Since the class has no name, we can create individual objects, but not use them to create larger structures. For example I can have many distinctly referenced stacks, but I cannot create an array of stacks or a list of stacks. Package exporting an abstact data type (ADT): This still has abstraction and information hiding (i.e. private types), but here the operations (e.g. push, pop) reside with the class (package) and not with the individual object (as in a truly object oriented language such as Smalltalk or even CLU or Simula). The state information resides separately in the Ada variable declared from Stack_Package.Stack. On the other hand, we now have a true Ada type that may be used to build larger abstractions (e.g. a stack of stacks or an array of stacks). Overall, I tend to use the latter approach since building abstractions on other abstractions in a fundamental design tool (especially in OOD). Further things to consider: try replacing the generic package approach with a task type. What are the tradeoffs? When is this useful? Also: what are the limitations when this design technique is combined with data abstraction in building sophisticated Ada generics? Brad Balfour EVB Software Engineering, Inc. brad%umdb.bitnet@umd2.umd.edu (I hope) Aside to Doug Bryan: Actually, the real answer to the above is for Ada to have a package type the way that it has a task type now. Let's lobby for it for Ada 9x.