teach in a computer science program, we may be going to far in the opposite direction by presenting ... object oriented approach is the best for all applications?
Are Educators Ready for Objects?
Position Paper for ECOOP'96 Educator's Symposium
Peter Grogono
Department of Computer Science Concordia University Montreal, Quebec There is little doubt that students are ready for objects: they know that industry needs object oriented expertise, and they want their education to provide that expertise. There is an unspoken assumption that teachers are ready to meet their students' needs. The position put forward in this paper is that this assumption may not be justi ed. There are two problems with the movement towards object oriented education, one minor and one major. The minor one is the educators themselves, who may have a thorough knowledge of algorithms, data structures, and \structured programming", but lack the practical experience that is needed for a deep appreciation of the object paradigm. This problem can be solved, provided that departments accept that teachers will need time to prepare themselves to teach the new courses e ectively. The major problem is the object paradigm itself. Introductory courses in most disciplines consist primarily of \classical" material | material that has been widely accepted within the discipline for a number of years. It has been said that Gauss could teach most of the material in a contemporary mathematics degree. While we would not expect Babbage to teach in a computer science program, we may be going to far in the opposite direction by presenting material that we do not yet fully understand ourselves to rst-year students. The object oriented community is busy congratulating itself, and rightly so. Large parts of the software industry have either moved to object technology or are planning to do so. Old programming languages have acquired object oriented features and most new programming languages are object oriented. The market is ooded with books that describe the paradigm with varying degrees of accuracy and profundity. It is tempting to assume that all is well and that objects are the future. And yet there are still problems to be solved, some of them fundamental. Debate on the role of inheritance started ten yeas ago and continues today [3, 4, 5]. But there are other problems that are certainly less discussed and may even be less understood. Here are some brief outlines.
Collections The \collection" has emerged as a useful abstraction in object oriented pro-
gramming. Collections must be traversed, but from the inside (by closures) or from the outside (by iterators)? There are arguments for and against both kinds of traversal but, as yet, there is no widely-used language that supports both. Consequently, comparison is dicult, especially for teachers of introductory courses, who must work with a single language. Data Structures Early contributions to object technology were often driven by experience with the previous generation of languages that was based on data abstraction. We were promised that familiar algorithms and data structures would be encapsulated in reusable class libraries. This has happened, but only to a limited extent. 1
Practitioners have found that objects are both more and less than implementations of abstract data types, and that object oriented software construction is more than just picking canned data structures out of a library. Frameworks Frameworks provide a form of abstraction that is unique to object technology and are one of its most signi cant contributions. But frameworks live \above' the application whereas other libraries live \below" it. The framework is problemoriented, but other class libraries are solution-oriented. How should we use them together for greatest e ect? Patterns Design patterns, originally an architectural concept, have come to be associated with object oriented design [2]. In principle, patterns are independent of programming languages. But, in practice, many patterns seem to be merely ways of overcoming de ciencies in particular languages [1]. Areas of Application object techniques are undoubtedly suitable for programming user interfaces and simulations. While both are important, there are many programs that neither require a user interface nor simulate anything. Are we con dent that the object oriented approach is the best for all applications? \Fat" Software Processors get faster and memories get larger at rates that are astonishing but, nonetheless, not fast enough to keep up with the ballooning resource requirements of software [6]. The object paradigm can take credit for many of these advances in software technology but it must also take some of the blame for bloated software. Issues such as these present problems for the conscientious teacher. Students in introductory courses are|or should be|critical of established methods and want to invent their own techniques and experiment with them. But they need a solid foundation upon which they can build their own knowledge structures. Are we con dent and unanimous about the basic principles of the object oriented paradigm? Although functional programming and logic programming have not impressed the industry as much as object oriented programming, these paradigms are grounded in familiar mathematical abstractions. The best functional and logical languages have a sublanguage with simple theoretical properties into which all programs can be translated. This is not yet the case for the object paradigm, although there have been a number of proposals for a \theory of objects" . An indication of our current uncertainty is that people, both inside and outside academia, are claiming that knowledge acquired in a computer science program is obsolete within ten years|or is it ve years? The accepted explanation is that computer science is \advancing rapidly", but a more accurate explanation might be that computer science is a eld that has lost sight of|or perhaps never found|its fundamentals. Will we continue to move from fad to fad, producing graduates who have to go back to school in ten years, or will we nd our roots, and impart knowledge that will be useful over the span of a career? Will we teach \object oriented programming" or underlying principles, such as abstraction, encapsulation, and polymorphism?
2
References [1] Gerald Baumgartner, Konstantin Laufer, and Vincent F. Russo. On the interaction of object-oriented design patterns and programming languages. Technical Report CSD{ TR{96{020, Department of Computer Science, Purdue University, February 1996. [2] Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides. Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley, 1995. [3] Ulrike Lechner, Christian Lengauer, Friederike Nickl, and Martin Wirsing. How to overcome the inheritance anomaly. In Tenth European Conference on Object-Oriented Programming, July 1996. [4] Markku Sakkinen. Disciplined inheritance. In Stephen Cook, editor, Proc. Third European Conference on Object Oriented Programming, pages 39{56. Cambridge University Press, July 1989. [5] Alan Snyder. Encapsulation and inheritance in object-oriented programming languages. In N. Meyrowitz, editor, Proc. ACM Conf. on Object-Oriented Programming Systems, Languages and Applications, pages 38{45, September 1986. [6] Niklaus Wirth. A plea for lean software. IEEE Computer, 28(2):64{68, February 1995.
3
