|
From: Andreas L. <no...@sb...> - 2001-10-22 03:29:17
|
Thinking about it for some time, I found another solution to eliminate the bridge pattern: The sole reason using the bridge pattern is that one has to be able to redefine the callback features. You cannot inherit directly from the parser, because you have to be able to switch the implementation. Now currently the parser also includes the callbacks. But we could seperate them into another class. ---- (pseudo code, not tested, assertions left out) -- inherit from this class to react on events deferred class XI_EVENT_CALLBACKS feature on_start_tag (...) is deferred end on_end_tag (...) is deferred end end -- every parser back end inherits from this class deferred class XI_EVENT_PARSER inherit XI_PARSER feature set_callback (cb: XI_EVENT_CALLBACKS) is -- `cb' features will be called whenever a -- xml atom has been found. do callback := cb end -- feature parse_from_string etc. inherited from XI_PARSER feature callback: XI_EVENT_CALLBACKS end -- a fictious parser implmentation class XP_EVENT_PARSER inherit XI_EVENT_PARSER feature parse_from_string (str: STRING) is do ... callback.on_start_tag (...) ... end end ---- I intentionally did not allow for more than one callback per parser. A seperate class XI_EVENT_CALLBACKS could do the job. Now, with this design, a user inherits from XI_CALLBACKS creates an object of the resulting class and gives it a given parser implementation (that can be retrieved from a factory). > So in the end, it seems this design allows: > > - easy composition of layers of event processing > - clean client interface (no inheritance from parser) > - bridge vs. factory does not matter for the parser > > At the cost of: > > - more dynamic typing of event types > - somewhat different coding style This is the resume of the design proposal of this mail: + easy composition of layers (you can still connect serveral XI_EVENT_CALLBACK objects) + clean interface + bridge vs. factory does not matter for the parser + typing is as static as it is with the brige pattern + the coding style would stay the same (if you mean the callback interface with that point) - multiple callback features, so no chance to inherit from KI_OUTPUT_STREAM Andreas |