The Symbian OS (779886), страница 75
Текст из файла (страница 75)
Frameworks therefore can be found in all layers of the system, from top to bottom. Indeed, in some senses, the different ways thatframeworks are used in the different layers may be the dominant designcharacteristic of those layers.Model–View–ControllerModel–view–controller, or MVC, is a well-known design pattern whichapplies the idea of frameworks to the design of an application, ‘the earliestframework that was recognized to be a framework’, indeed, according toJohnson [Rising 1998, p. 376].The high-level design of an application in Symbian OS really residesin this pattern, which provides a general model for the classes that anapplication needs, what their basic collaborations are, and how they areachieved.The simple version of MVC, and the headline from the point of viewof Symbian OS, is the separation of the application model (the data andthe APIs which operate on it) from the application logic (the way theuser uses the application and its data), not just as a coding rule, but as awell-founded design principle.16As Johnson puts it, the difference between patterns and frameworks is the differencebetween reusing knowledge and reusing code.
Frameworks reuse code and, thus, enablemore immediate reuse than patterns [Rising 1998, p. 382]. Patterns are a degree ofabstraction further out from frameworks.17See Chapter 16 for some examples of the ‘thin framework’ problem.A THOROUGHLY OBJECT-ORIENTED OPERATING SYSTEM357Howard Price:Model–view–controller goes way back to SIBO. It probably was CharlesDavies and David Wood who introduced it. But, right from the beginning,that’s always been the design. Right from the beginning, there was a decisionthat you really should separate these three things.Active Objects and the Event ModelThe event model is an important part of the wider application framework,but it is itself a part of the system which makes rich use of object-orientedprinciples. Its key principle is to abstract the event loop using the activeobject pattern.
Again, the driving point here is to fix the design in theframework and so simplify the way that applications interact with itthrough the framework.Martin Tasker:Think of it this way. Firstly, the fundamental requirements of doing a GUI andthe fundamental requirements of event handling motivate object orientation,and polymorphism in particular. So you have an event and you have acontrol, you send that event to that control or you get that event from thatcontrol.
But then of course you need concrete types underneath that, you needconcrete actions for concrete controls and concrete events. The point is thatthe fundamentals of event-orientated programs in a GUI context take you in avery short sequence of steps to object orientation.At the heart of the message dispatch system, active objects are usedto encapsulate and serialize (i.e., make sequential) incoming events. InSymbian OS, this is probably the object-oriented pattern which goes backthe furthest.
The alternative, of course, is the conventional ‘big switch’statement style of classic Microsoft Windows.Active objects provide a simple, natural, serialized, alternative.Martin Tasker:Colly Myers was right, active objects are a dream. For people who know thatthey are dealing with event-handling programs, they’re an absolute dream. Inan event-handling system, active objects are a really natural way of handlingthings and they are so much easier for programmers to work with than prettymuch all of the alternatives actually, or any alternative that I had seen.The key advantage of active objects is that they provide a simplemodel for maintaining a single flow of execution through the main358THE USE OF OBJECT-ORIENTED DESIGN IN SYMBIAN OSprogram logic of an application, while still enabling a responsive, eventbased implementation.
They offer a simple alternative for what wouldotherwise typically require a complex, multithreaded approach.Martin Tasker:With multithreaded programs you have to do locks, so you always have to askyourself, ‘Am I handling these locks correctly?’ And what eventually happensin those systems is that you get some conservatism, so you eventually endup with two or three global system locks which only your kind of super-eliteprogrammers ever touch, and then you get a couple of local locks which aremore or less private business, and you don’t quite have to be a genius to dostuff with those locks on the basis that you only penalize your own code, soyou’re probably going to get it right eventually.
But it’s much more complexand it’s much less elegant.There are times, of course, when the active-object model is inferior toa more raw-thread-based model.Andrew Thoelke:Of course there are times when the active scheduler gets in the way, butfor many things active objects are a better model. It’s actually a bettermodel to have cooperative active objects running in a single thread thanto go multithreaded. But there are certain tasks for which multithreadedprogramming is definitely more useful.
Certainly when you want to be able todo finer time slicing or you don’t want to have to manually break up a taskinto discrete chunks. Sometimes it has been hard initially to integrate that sortof software with Symbian OS. In the early days, a client–server session wasinherently tied to a thread. The client was the thread and that was engrainedin the whole framework and model.
And there were even cases where thatwas designed into the server. The server required that the thread and clientwere synonymous. That has changed now, explicitly to enable multithreadedclients. So you have the choice.The Framework for FrameworksAn important change in Symbian OS v7.0 was the introduction of theECOM ‘framework for framework plug-ins’, the Plug-in Framework component.Andrew Thoelke:The plug-in pattern was pervasive in the OS.
Everything has plug-ins: the kerneldoes, the file server does, the window server does, and in all cases the actualA THOROUGHLY OBJECT-ORIENTED OPERATING SYSTEM359mechanism for tagging and identifying and locating a suitable plug-in thatmatched your interface protocol and statically matched your actual specificrequirements right now, was very ad hoc, except for the fact that you generallyused a UID to match the server protocol interface.
But the way you locatedthem, whether you searched for them, whether the loader searched for them,it was all very unpredictable.Worse still, new variations were continually being created, of varyingquality. Standardizing framework–plug-in design by introducing a framework for framework plug-ins not only brought more discipline to bear onthe way plug-ins were searched for, found and loaded, it allowed the bestdesign (the plug-in system created for the web and Internet browser) tobecome the template.The basic principle adopted is the abstract factory design pattern.Andrew Thoelke:Our design is a fairly obvious pattern as soon as you see it. You can see thatactually I can apply this anywhere somebody wants an abstract factory.
Youput that abstract factory something in a DLL, and then when you request thatDLL you have it conform to your interface. And the ECOM plug-in frameworkjust provides a standard way of doing all of that.As it happened, standardizing the plug-in mechanism fit in well withthe new requirements of the platform security architecture. (Uncheckedloading of externally written plug-ins into system frameworks, or applications for that matter, is a potential security risk.) And that in turn helped toenforce the standardization, because it could be pushed through as partof the effort to implement the system-wide, pervasive changes requiredby the security architecture.Andrew Thoelke:With platform security, it was highly desirable to get away from everybodysearching for their executable content, which is what’s really going on whenyou’re looking for plug-ins to load into your framework.
And because wealready had put ECOM there and it was an established part of the system,we could enforce it as the standard mechanism and police plug-in loading atthat single point. So we had a way to force the migration to ECOM through.After PlatSec, there is no way for your framework to find out what plug-ins areavailable by enumerating the actual executables in the system because it’s notpossible to do that any more. So you either use ECOM, because it’s got its ownregistration mechanism with resource files, which regulates add-in plug-ins,or you have your own registration mechanism where something which gets360THE USE OF OBJECT-ORIENTED DESIGN IN SYMBIAN OSinstalled not only installs the executable, it installs something else which tellsyou that there’s an executable plug-in that you can load, so you control whatplug-ins can be added.Streams, Stores and PersistenceSymbian OS, possibly surprisingly for an object-oriented system, supportsa conventional FAT file system.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
