Developer.com content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
Academic Origins
Much of the enthusiasm for each new programming paradigm that emerges is driven by academics who relish the intellectual challenge but who don’t have to build working code to a fixed deadline. This is particularly true of Object Oriented Design (OOD). There is no pure-bred, definitive programming standard called Object Orientation—which makes for both flexibility and confusion in the development of software.
In this article, I’m not going to focus on the myriad object technology refinements which are foreseeable in the short-term. The real interest lies in the broad-brush futurology of OOD.
Some Limitations of Present-Day OOD
OOD is really an organizational philosophy rather than a fundamentally new way of solving computational problems. Its capacity to dominate the other approaches to programming is limited because:
- There are many applications to which its hierarchical model is only poorly suited.
- Objects aren’t designed to be reusable across different programming languages.
- It is comparatively hard to learn the important, powerful, and subtle techniques that OOD allows (usually because of the unfriendly details that “power users” demand be maintained).
- OOD tends to build relationships between elements of a model implicitly into the structure, making changes to these relationships difficult.
- Keeping methods and data separate can sometimes be a good idea, especially in a networked environment where data sharing is of paramount importance.
Despite these limitations, here are several areas in which the future development of OOD can be anticipated.
Design Patterns
Mature engineering disciplines rely on handbooks that describe successful solutions to known design problems. Design patterns and pattern languages are an analogous attempt to describe solutions to common software problems.
There is no fundamental relationship between objects and patterns. Objects just happened to be the current hot topic when patterns, as an idea, took off. Patterns help in the design of software at the architectural level.
(“Frameworks” can be viewed as concrete, code-based, realizations of patterns that allow direct reuse of design and code. One difference between patterns and frameworks is that patterns are described in language-independent manner, whereas frameworks are generally implemented in a particular language).
Developers will increasingly integrate related patterns to form pattern languages that will address particular disciplines ranging from organizational design, software reuse, real-time systems, electronic commerce, and human interface design.
Patterns will help control the complexity of both the specification and implementation phases of software development. This will inevitably provoke a new wave of software development methodologies. Several of the leading object-oriented software design notations/methods and development environments already have added support for the representation of design patterns. Some research projects are attempting to formally represent design patterns for the purposes of generating source code. Although the ability to codify patterns as generic software components is valuable, even more important is the developer’s knowledge of how and when to apply those patterns. Patterns are therefore unlikely ever to entirely replace software developers.
Web/Grid Services
The current “unit of reuse” in OOD is the Class. In the emerging field of Web/grid services, the reuse element will be a service—a contribution to an overall application. This will allow both for “automatic reuse” and “live updating” of the contributing software.
An example of an object-based Web service might be the automatic adaptation of large numbers of individual travel plans by a series of Web services that call one another recursively to complete or adjust itineraries in the face of flight cancellations and traffic jams. Web services rely on objects being maintained by a variety of separate development processes and may not therefore be so robust as to completely justify human reliance upon them (as in an air traffic control application).
Scripting Languages
Scripting languages—for example, Python, PHP, and Perl—are growing in popularity for more than sys-admin typescripting for the Web, and for fast prototyping. Many scripting languages provide a “watered-down” version of object orientation (for example, the classes and instances of these classes may violate many of the principles of “pure” OOD, as in type safety and the immutability of class definitions); in Python you can add arbitrary data fields to a class instance at runtime, even if they weren’t mentioned in the class definition). Who knows what this “sloppy” OOD will mean for the future of OO programming because it allows a measure of flexibility at the expense of all sorts of run-time problems.
Another form of “dilution” of rigorous OOD is the movement towards “multi-paradigm” design in which object and procedural work are combined in an attempt to create a “horses-for courses” optimization (such as occurs in the creation of object oriented databases). Remember, of course, that object methods are still written “procedurally.”
Scientific Computing
This field is becoming increasingly OO, both via the spread of OO languages and with the adoption of object concepts in recent versions of traditional languages—in particular, Fortran.
In particular, the object-oriented simulation paradigm made objects more lifelike by enabling them to “perceive” other objects in their environment and calculate the actions required to achieve some specified goal. Multiple instances of these object agents can interact to develop emergent simulations of, for example, insect colony behaviour, sandpile landslides, and economics. Methods that allow them to modify their behaviour to improve their performance make them effectively autonomous … they program themselves. This is a bottom-up form of artificial intelligence which has real, long-term implications for software developers.
Finally
In the future, Objects will be pervasive … but not dominant across all fields of development. There will be many different scales at which software design needs to be viewed: line of code->object->design pattern-> ??? Even with these many different levels of granularity in place, the ultimate limitation on developers will still be that of trying to communicate between individuals and between machines.
Patrick Andrews is managing director of break-step productions, a consultancy firm specializing in designing digital businesses. His areas of interest include interactive marketing, machine intelligence and software design. Contact him at pra@break-step.com.
