Adaptive object-oriented programming using graph-based customization
Karl J. Lieberherr, Ignacio Silva-Lepe, Cun Xiao · Communications of the ACM · 1994
UsingGraph-Based Customization bject-oriented programs are easier to extend than programs that are not written in an object-oriented style, but object-oriented programs are still very rigid and difficult to adapt and maintain.A key feature of most popular approaches to objectoriented programming is that methods are attached to classes-C + +, Smalltalk, Eiffel, Beta-or to groups of classes-CLOS.This feature is both a blessing and curse.On the brighter side, attaching methods to classes is at the core of 1) objects being able to receive messages, 2) different classes ofobjects responding differently to a given messag-e, and 3) the ability to define standard protocols.On the darker side, by explicitly attaching every single method to a specific class, the details of the class structure are encoded into the program unnecessarily.This leads to programs that arc diflicult to evolve and maintain.In other words, today's object-oriented programs often contain more redundant application-specific information than is necessary, thus limiting their reusability.Does this mean we have to either take the curse in order to enjoy the blessing or give up the blessing altogether?Analyzing the problem we realize that not all is lost.What we need is to be able to specify only those elements that are essential to an object-oriented program and then specify them in away that allows them to adapt to new environments.What do we mean by specifying only those elements-classes and methodsthat are essential to an object-oriented program?In [16], Wilde and H&t point out: "There is a general impression that object-oriented programs may tend to be structured rather differently than conventional programs.For many tasks very brief methods may be written that simply 'pass through' a message to another method with very little processing."Such "traversal, pass through" methods we regard as nonessential.But more important, we intend to focus on classes and methods that are essential not only to a particular application but also potentially to a family of related applications.How can we identify such generic classes and methods?Consider the following "paradox of the inventor" posed by mathematician George Polya [12].He observed that it is often easier to solve a more general problem than the one at hand and then to use the solution of the general problem to solve the specific problem.The hard work consists of finding the appropriate generalization.Polya uses the following example to demonstrate the technique.