The Symbian OS (779886), страница 74
Текст из файла (страница 74)
The second way is to lookfor efficiency in the large scale as well, which is when you realize that twoprograms, or more than two, are actually trying to do essentially the same job,so instead of them having independent copies of code which is largely thesame, you have one copy of the code, together with small bits in each of theapplications where they provide their relevant specializations.Object orientation provides a principled approach to code reuse.
Incontrast, nothing is easier or more tempting or more fatal, than reusingcode by literally copying and pasting code sections within programs and13At the time of writing, there is a good history at http://en.wikipedia.org/wiki/X windows.A THOROUGHLY OBJECT-ORIENTED OPERATING SYSTEM353between programs; object orientation is the ultimate principled antidoteto ‘copy and tweak’.David Wood:What we were fighting against was something that’s sometimes called ‘copyand tweak’, when you’re writing some code and you notice that somethingyou’ve already written doesn’t quite do the job but it nearly does, so youjust copy it wholesale and then tweak it, so you end up with two not quiteidentical copies of the code and before you know it you end up with dozens ofcopies of essentially the same code, but it’s not quite the same.
And that’s badfor all kinds of reasons. It’s bad because it’s inefficient. It’s bad because it’svery hard to maintain, if you discover that there’s a problem with your originalalgorithm you may manage to fix it in one place and then the same bugremains very probably in all the dozen separate copies that you made in themeanwhile. Some people nowadays say, ‘Well, the hardware has advanced somuch, the same efficiency considerations don’t apply.’ And there’s certainlyan element of truth in that. We needn’t work quite so hard to save everysingle byte. But avoiding duplication is still an important principle, because ifyou duplicate unnecessarily then you end up with maintenance problems andcomprehensibility problems.14.3 A Thoroughly Object-oriented Operating SystemThe rest of this chapter looks in more detail at how object orientationis used in practice in Symbian OS, identifying some of the most characteristic examples of object-oriented style and techniques.
Symbian OScontains some important object-oriented patterns. What follows is not anexhaustive list, but it captures the larger scale object-oriented patterns inthe system.• Frameworks and plug-ins are a good example of the power of polymorphism and are ubiquitous in Symbian OS. As a pattern, frameworksoperate at the level of the static architecture of the system (whatparts are in the system, in other words) although they also have aninteresting run-time, dynamic aspect.• Active objects are thoroughly object-oriented and are probably bestthought of as a design and programming idiom for avoiding the complexity of multithreadedness, while enabling asynchronous activitiesto be spun out of a single thread and spun back in.• Descriptors are good examples of object-oriented encapsulation, bestthought of as an idiom for achieving type-safe and memory-safe stringhandling.354THE USE OF OBJECT-ORIENTED DESIGN IN SYMBIAN OS• Cleanup is another example of good object-oriented design appliedto solve the error recovery and propagation problem and is probablybest thought of as a programming idiom (although it also touches thebuilt-in typing model).• Streams and Stores (the persistence model, in other words) is pureobject-oriented design, that underlies a programming idiom for externalizing and internalizing data through an abstract, non-file-basedabstraction.• The User Library is a good example of simple encapsulation-styleobject-oriented design used to package some system services.On the other hand, there are also some designs in the system whichare more conventional, non-object-oriented patterns.• The client–server model is not an object-oriented model (unlikeframeworks, for example), even if it is given an object-oriented flavorby modeling the client–server relations with objects.• The file system, beneath the client–server and framework architecture and the object-oriented interfaces provided by the stream–storepersistence model, is in fact a conventional, non-object-oriented,files-on-disk system.
(Compare for example with the thoroughlyobject-oriented ‘object soup’ storage model made famous by Apple’sNewton and the similar database approach later adopted by Palm.)• Critical aspects of the kernel design, for example the scheduler, areconventional in design, with hand-optimized assembler implementations for speed.It is worth making the observation that the device for which theoperating system was originally designed, the Psion Series 5, was quitea conventional device in terms of its technologies.
So while the useof the technologies was innovative, the technologies themselves wereconventional: a small, ROM-based device with screen and keyboardusing conventional, removable (Compact Flash) data cards for externalstorage. To take the file system as an example, the choice of a FATfiling system was conventional but eminently reasonable. And in fact,if users wanted to use their removable cards to swap data with otherdevices, then FAT was the necessary choice, for removable media atleast. Deciding for a conventional file system simply reflected the realitiesof data exchange for a handheld device in a world dominated by PCconsumer computing.This argument in favor of a conventional file system beneath theobject-oriented wrapping is one that Geert Bollen, for example, hasheard before.A THOROUGHLY OBJECT-ORIENTED OPERATING SYSTEM355Geert Bollen:That’s very much the argument you would have expected to hear from CollyMyers.
But, it doesn’t follow from the argument that the internal storagerepresentation should be FAT, though that’s quite a valid design choice.The point is really that, while the system indeed is thoroughly objectoriented, adoption of object orientation was motivated by pragmatismand, in some cases, that same pragmatism led to more conventional,non-object-oriented design choices in the system.FrameworksA framework is a component that defines an abstract interface which itdoes not implement, but for which instead it provides a runtime loadingand management mechanism for locating and loading external plug-incomponents that provide concrete implementations for its interface.Framework–plug-in is a classic pattern therefore for separating interfaces from implementation, which is one of the driving design principlesof object orientation (inherited, as it were, from the notion of the abstractdata type, an important influence in the emergence of object-orientedlanguages).
The framework–plug-in pattern is therefore classically goodobject orientation. It is also a natural pattern for enabling extensibility.But frameworks are more than that. As [Beck 1999, p. 258] puts it,‘Design is hard’! A framework is, in effect, reusable design because itexpresses a part of a system as a set of abstract, cooperating classes,scopes the behavior of those classes by defining their interfaces, andimplements the interface between the framework and the underlyingsystem; in other words, it wires the design into the system.
At thatpoint, the design work is complete. What remains is implementation,and implementation (the actual instantiation and also, if you like, theinterpretation of the behavior scoped by the interfaces) is left to othersincluding third parties.14 Frameworks are an important design choice,because a framework design strongly determines how we should expectto work with some part of the system. In the object-oriented literature, frameworks go back to ideas of Deutsch and Johnson in the late1980s.15Of course, patterns are also ‘designs for designs’ and, arguably, so tooare class libraries, but frameworks go further than patterns, because they14Or as Martin Budden put it to me, ‘Frameworks are for people who just can’t makeup their darned minds!’15My references here are taken from [Beck 1999, p.
257].356THE USE OF OBJECT-ORIENTED DESIGN IN SYMBIAN OSare actually coded ([Rising 1998, p. 375]), and they go further than classlibraries, because they are already pre-wired into the system.16There is an objection: frameworks are complex and hard to writeand need ‘refining by fire’ (see [Rising 1998, p. 184]). In many casesthere is an additional, important dimension. Where frameworks exposeinterfaces on two sides, an ‘up-side’ application-level interface and a‘down-side’ hardware-level interface (which is a common pattern inSymbian OS – the frameworks in the communications and multimediaareas are good examples), the question of the ‘thickness’ of the API, (howmuch code there is between the up-side and down-side interfaces) canbecome critical for retaining control of the design.
The thinner the API,the more exposed it is to the opposing and even hostile forces of itsup-side and down-side clients and the easier it is for them to subvert theoriginal design intention.17Frameworks can also be complex to use. Because they constrain theuser, they must be understood well to be used well. Frameworks are apervasive design choice in Symbian OS, because they are a particularlyeffective mechanism for enabling customization and extension at a deeplevel; the operating system implements an overall design in some particular area but licensees are still able to contribute highly customizedbehavior.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
