ACMComputing Surveys28A(4), December 1996, http://www.acm.org/surveys/1996/ObjectsAndBeyond/. Copyright © 1996 by the Association for Computing Machinery, Inc. See the permissions statement below. Broadening beyond objects to patterns and to other paradigms
Publication Information
Towards objectsEach era of computing asks how to broaden the tenets and strengths of the status quo into new domains and how to extend their benefits into the future. The object paradigm has now enjoyed a decade of such attention and consideration in a large programming subcommunity. I shy from saying "success," as our business is unskilled at measuring its success, a fault that I believe owes to the subjective and artful nature of the fundamental problems. And I shy from claiming more than a decade; though the roots of object orientation go back further, objects have received attention largely at the hands of C++, which popularized them into the predominate C culture. And I qualify the scope to one subcommunity, out of respect to that RGP and COBOL community out there.To ask where the object-oriented field is going, one must first define it. That's difficult for two reasons. The first is the obvious problem of scope: there are many definitions that divide objects from non-objects, and no programming language community has escaped the opportunity to lay legitimate claims to things object oriented. The second is a more subtle problem of scope: many things that are claimed to be object-oriented adhere to no widely accepted standards, conventions, or definitions of objects. Some of these communities are opportunistically riding the wave. Some just don't get it, and are enjoying little success. Others seem to be thriving, even though their techniques wouldn't cut muster at ECOOP or OOPSLA. Beyond objectsSo what is this "thing" called object-oriented programming, and where is it going? We should be less concerned with how the object paradigm itself will evolve (e.g, become refined) than in what new ideas it will generate. We need more than evolutionary change given the dire conditions of contemporary software development, and I'm less interested in how objects will gracefully fine-tune themselves into old age, than in what Phoenixes will arise from the ashes. Happily, there are strong positive signs of what this future might be. Patterns and multi-paradigm design are two noteworthy examples.PatternsPatterns have their roots in the object movement. It needn't have been so, as there is no fundamental relationship between objects and patterns. It's just that objects happened to be the predominate worldview when patterns took root. I believe patterns took root in the face of complexity. Objects may have aided the rise of patterns just because they're so antithetical to patterns, and underscore the need for something like patterns. Alexander himself underscored the danger of building from pre-manufactured parts. Patterns offer a broader view of software, helping us think about software at the system level, the architectural level. I think there's a strong future there. But it will be a folk development that will blossom of its own accord, and best be left to its own maturation without too much conscious direction or tampering.Commonality and Variability AnalysisPatterns have raised an interesting question about abstraction: if object-oriented abstraction alone doesn't give us the right structure--as patterns have illustrated--then what paradigms do generate the right structures? Must design be left to the unbridled creativity and inspiration captured by the best patterns? Much of what is going on in patterns can be regularized if one uses time-honored principles of design: the commonality and variability analysis, classic tools honed by Parnas and his followers. Such analyses lead to software families. A class hierarchy is a common example of a family, but so is a collection of overloaded functions, or the abstractions instantiated from parametric templates. Each of these builds on its own paradigm--its own rules, tools, and principles for formulating abstractions. What patterns capture informally, commonality analysis can regularize into a method.Therefore, I believe the future of the object paradigm will be a broadening of its peculiar commonalities (behavior and structure) and variabilities (algorithm and structure) into other categories related to other paradigms. That is, I believe we should strive toward multi-paradigm design. We must understand how paradigms work together and complement each other, rather than focus on which one is "best."" Peter Wegner has astutely noted that this thing we call the "object paradigm" is just a melange of its predecessor paradigms, and that any claims to "pureness" of object-ness are misplaced. The future of design will take us beyond selecting the appropriate paradigm for the right job (a level of maturity we have not yet fully attained) into an era when we learn how to tastefully combine paradigms. The fledgling object-oriented database discipline is one example of such mixing (though I believe it's too early to tell whether we've charted the right course or not). I believe that the emerging role-based methods fit this model as well. We can take some comfort that though this is a revolutionary world-view, it is substantiated by current practice. Much of the ballyhooed success of contemporary object methods in fact owes to effective multi-paradigm design; any astute methods consultant can note this instantly through the most casual project audit. This isn't to ignore what I believe will be major advances in parallelism and demand-driven dataflow computation, but I think the payoffs of a multi-paradigm view are more easily foreseen, managed, and leveraged than those for parallelism and functional programming. Last modified: Thu Oct 31 14:33:51 EST 1996 Jim Coplien<cope@research.bell-labs.com> |