What about inheritance? Should we design for it and document it, or prohibit it? I'd vote for prohibiting it in this case: inheriting from classes that have non-trivial statecharts tends to be a bit of a nightmare.
However, in an actual implemented applet, the methods will do things and so it is possible that there could be a non-trivial state diagram. Moreover, it's possible that we might want to set up an agreement between objects of this class and their clients about what order methods will be called in - recall that this is the main purpose of a PSM.
The JDK documentation for Applet is in some sense backwards: you will see that it is written principally for people implementing subclasses of Applet (the majority), not for the tiny minority who are writing clients of these classes (developers of browsers and appletviewers). The clients are pretty much fixed, and the subclass developers have to fit in! One thing we are told: under destroy(), "The stop method will always be called before destroy." i.e. the browser will ensure this. It's implicit that init() is called before anything else, but as developers of an applet subclass, perhaps we ought not to assume any more than this. For example, perhaps we should write our start() and stop() methods in such a way that they can be called any time after init() has been called and before destroy(), even if they won't do anything much.
In this case, you'll get the start marker to go into one state (AwaitingInitialisation say) from which init() takes it to another (Ready perhaps), from which start() takes it to Running, with stop() taking it back to Ready. start() in the Running state would cause self-transition, as would stop() in the Ready state. destroy() from the Ready state should take us to a stop marker. We don't have to deal with destroy() from the Running state, if we believe the JDK documentation that browsers will always call stop() first: that is, the JDK documentation seems to expect that our protocol will require this. Since we're assuming init() will be called before anything else, we don't have to offer any other transitions from AwaitingInitialisation. Should we allow for init() being called from Ready or Running? It's probably good practice to do so, and both should probably lead to the Ready state, but it wouldn't be out of the question just to forbid this in the protocol, i.e., don't offer init() transitions from those states.
(I have not delved deeply into what the full documentation says or what applets do in practice - from memory, most applets are written simply and robustly enough to cope with "wrong" sequences of messages, and browsers will sometimes do strange things. It's quite likely that some students know more about this than I do.)
perdita@inf.ed.ac.uk
)
Informatics Forum, 10 Crichton Street, Edinburgh, EH8 9AB, Scotland, UK
Tel: +44 131 651 5661, Fax: +44 131 651 1426, E-mail: school-office@inf.ed.ac.uk Please contact our webadmin with any comments or corrections. Logging and Cookies Unless explicitly stated otherwise, all material is copyright © The University of Edinburgh |