The Symbian OS (779886), страница 23
Текст из файла (страница 23)
In context, the decision to ‘go object-oriented’ was a natural step.Object-oriented ideas had been increasingly adopted in Psion’s precedingoperating systems, from the first Organiser products to the 16-bit SIBOoperating system for the Psion Series 3. However, the decision to applyobject-oriented design to the whole system, and not just to the higheruser interface and application-level layers, was none the less radical forthat.
In particular, the decision to adopt C++ as the implementation language for the operating system was a bold one. The earlier systems (oncethey had evolved beyond assembler) had been written in a home-grownobject-flavored dialect of C.1 Adopting C++, which was still far from themainstream, was, with hindsight, far-sighted though not without risk.In 1994, when the project to create what eventually became SymbianOS started up, C++ was still a new and evolving language.
C++ compilerimplementations for the PC were still being pioneered by small companiessuch as Zortech and Watcom (the ‘industrial’ C++ market was still basedon Unix). Microsoft had only just entered the market.2 The languagestandard was still some years away. Standardized tools were even furtheraway.3The immediate consequences were twofold.
First, cross-platform development was difficult (compiling on Intel for eventual ARM targets) becausethe low-level language bindings were not consistent across hardware1See also Chapters 2 and 17.See for example the Wikipedia article http://en.wikipedia.org/wiki/Visual C Plus Plusfor a history of Microsoft’s C++ releases. VC1.5 was the big release.3Tools standardization (enabling compiler and linker interoperability across vendors,for example) depends on agreeing the low-level application binary interface (ABI).
Thestandardized ABI for ARM processors is only now emerging into the tools mainstream.288INTRODUCTION TO OBJECT ORIENTATIONarchitectures. Secondly, some language features were missing, immature,or just unsuitable for the project’s purposes. While C++ was explicitlyintended as a systems language, and to some extent also inherited C’slow-level–high-level mantle and its long history of optimized compilerinternals, some features of the language were far from optimal for small,low-memory footprint, low-power devices.4 By and large, the languagemade no claim to be particularly suitable for small systems of any kind.Its roots were in big, middleware systems running on big hardware (e.g.,millions of lines of code phone switches).There were some significant consequences for the evolution of Symbian OS; many of its hallmark idioms were invented because the C++language as it stood could not meet requirements (type-safe strings, structured exception handling, and so on) that Psion’s designers consideredessential for the class of device they were targeting.
Subsequently, asSymbian OS has itself begun the move into the mainstream, these legacies of early language immaturity and Psion’s early adoption of C++ havepresented obstacles to a new generation of developers who have grownup with a standard language. Inevitably, there is pressure on Symbian OSto do better at supporting the standard language.But it is fair to say that this problem is related to the success of SymbianOS. The pressure comes from its exposure to a much broader range ofdevelopers than in the past. It seems inconceivable, or at least unlikely,that Symbian OS would now be poised on the edge of mass-marketadoption had its architects not innovated far beyond the homegrowntools and language idioms of its predecessors.
The choice of C++ wasa prescient one, accurately predicting what turned out to be a languagejuggernaut, sweeping all before it (at least until the rise of Java). Therewere also benefits from adopting an object-oriented methodology acrossthe whole of the operating system.4.2 The Big AttractionOf all the perceived benefits of the object-oriented approach to softwarecreation, reuse is probably the most compelling. Software is expensive.Software is unreliable.
Software is complex. These are the three truismsof software development and reusability meets them all head on, or atany rate purports to.First of all, software is expensive because it is complex. Softwareprojects overrun because the problem at hand always turns out to bemore complex than was at first thought and things prove to be harderthan they looked in the plan. But if software projects can be started froma baseline of existing, already proven code or finished components, or at4For example, the overhead of vtables.THE BIG ATTRACTION89least proven design, the scope for misunderstood complexity might justbe reduced, and this seems to be what reuse promises. The more artifactsthere are to be reused, the less the complexity, and therefore the lowerthe cost.Secondly, software is expensive because it is unreliable.
It is unreliablebecause it contains defects and it contains defects because it is complex.Reuse seems to hold promise here too because reuse improves quality byreusing proven parts. It also improves quality by reducing the complexitywhich causes defects in the first place.Reuse does indeed look like the key to conquering software complexity,and this is very much how it has been sold. Object orientation claimsto deliver reuse and reuse is the big attraction. In the words of [Gabriel1996], reuse was ‘the hook that grabbed the mainstream world and pulledit toward object-oriented programming’. Since effort costs money, reusingeffort must save money.
And since effort is error-prone, reusing effort mustreduce errors.Of course, reuse is not the privileged domain of object orientation.The earliest innovations in what were not yet called operating systems5were as much about code reuse as about multiplexing processors andperipherals. The same is true of the early language standardization drives,from Fortran to COBOL to C and beyond.There are other aspects of reuse too. Reuse also occurs at project level,as every programmer quickly learns and as [Gabriel 1996] points out.Today’s new problem can be understood as a variation on last week’sproblem, and therefore last week’s solution can be adapted to becomethis week’s solution too.Languages, however, have the advantage of working at several levels,from the individual to the team, from program level to project level.But all languages are not equal.
The clever observation that heralds thediscovery of full blown object orientation is that reusing data structurescounts as much as reusing algorithms. Object orientation makes this alanguage feature and supports it with language constructs, not just codelibraries and link-time tools.Other benefits also arise from reuse. Object-oriented analysis is a goodway of modeling real-world problems.
For example, object-orientedlanguage pioneers have claimed ‘real world apprehension’ and ‘stabilityof design’ as two benefits which follow from the directness of thecorrespondence between an object model and a real-world problemdomain [Madsen et al. 1993, p. 2]. The object approach to modelingalso provides its own natural model for program organization (code isnaturally granular at the object level; code can be divided betweeninterface definitions and implementations, and so on). It probably turns5Possibly the earliest example was the Supervisor program of the Manchester UniversityAtlas computer in the late 1950s (see [Hansen 2001]).90INTRODUCTION TO OBJECT ORIENTATIONout, too, that this way of organizing a program makes it easier to extendthan more traditional organizations.We are now some years on from object orientation’s initial promise.6Object orientation is the industry’s dominant programming methodologyand software is still expensive, software projects are still delivering late(when they deliver at all: abortive projects remain at an astonishing 30%across the industry) and software is still unreliable (i.e., it cannot beguaranteed to perform its intended function without error).7It would hardly be fair to blame object orientation for this, althoughit is tempting to ask what became of the vision of reusable components,of a black-box component industry and a free market in ready-made,reusable software parts.8 Either the vision fizzled out or our gaze movedon.
If the market ever materialized, it failed to thrive.There are still no magical solutions [Gabriel 1996]. The truth isthat simple promises rarely deliver. Reality is always more complex andmore interesting than that. Object orientation, meanwhile, has enjoyed anastonishing rise and, perhaps for other reasons, remains in the ascendancy,even if the search for the ‘New New Thing’9 in reuse has moved on.Interestingly, following what seems to be an inevitable evolutionarytrajectory, the focus has shifted, or turned back, to the next level ofabstraction beyond languages and beyond the meta-languages of patterns,to projects, project organization and other ‘soft’ or ‘human’ aspects ofprogramming, with methodologies such as extreme programming andagile programming dominating the quest.4.3 The Origins of Object OrientationObject orientation is an approach to design and programming rather thana fixed methodology.10 This makes it a rather loose label.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
