Subject-Oriented Programming (A Critique of Pure Objects)

William H. Harrison, Harold Ossher. Subject-Oriented Programming (A Critique of Pure Objects). In OOPSLA. pages 411-428, 1993. [doi]

Review: Subject Oriented Programming (A Critique of Pure Objects)

Posted by Ricky T. Lindeman on 30/06/2010 16:21, last updated on 30/06/2010 16:27 (Public)

“Subject Oriented Programming (A Critique of Pure Objects)”

Title: Subject Oriented Programming (A Critique of Pure Objects)

Authors: Harrison, William and Ossher, Harold

Review and Summary

This paper discusses the goal of subject-oriented programming, subject termi- nology, subject interaction, the description of a model of subjects and imple- mentation considerations followed by a concrete example.

According to Harrison and Ossher object-orientated programming “is utterly inadequate to deal with the construction of large and growing suites of applica- tions manipulating objects”. Their reason is that the definition of an object gets cluttered with properties and behavior whenever a new feature is added to the application. In the end a class definition consists of various (often independent) groups of properties and behaviors needed for a single feature. Harrison and Ossher suggest a new paradigm called subject oriented programming extending the object orientated approach in which each logical group of properties and behaviors used by a feature is seen as a subjective view of the object. The authors define the term “subject” as follows: “We use the term subject to mean a collection of state and behavior specifications reflecting a particular gestalt, a perception of the world at large, such as is seen by a particular application or tool.” [1]

A subject is thus the generalized view of the world, also called the universe, according to a group of users. Subjects encapsulate intrinsic properties, intrinsic behavior and even the class hierarchy for a collection of objects according to their view of the world. But a subject can also be a combination of subjects which is called a composition. An application can thus be viewed as a combination of several compositions, which will also be made out of many subjects and compositions.

Harrison and Ossher note that the view of the universe of a single subject is the same as the classical object-orientated model, but when different sub- jects need to interact due to a subject composition the subject-oriented model comes into play. The subject-orientated model also allows tighter encapsulation than the classical object-orientated model, because only a subset of the objects instance variables are accessible to methods in a certain subject.

Because objects do not share their properties, behaviors and class hierar- chy between subjects, composition rules are needed to let the subject cooperate effectively. Multiple subjects can respond to the same operation call, the sub- jects need to agree on the semantics, corresponding methods can be determined using interface matching. A subject should be able to place an object that is created by another subject in its own class hierarchy using class matching. The authors note that both interface matching and class matching are important areas for future research, in their paper they only discus various approaches to class matching.

The model of subject-orientated programming the authors discuss is clearly for definitional and explanatory purposes and according to the authors should not suggest or constrain implementation architecture. The model explains some details about operation invocation, object creation and initialization, and state references. A formalized description of composition rules is missing, because it is out of scope according to the authors.

Furthermore Harrison and Ossher discuss several implementation considera- tions for efficient subject-orientated support. They discuss several strategies for optimal code execution with multiple subjects as well as strategies for efficient data sharing between subjects. In contrast with the subject orientated model discussed in the previous section in this section the authors discuss an imple- mentation approach for the subject compositor tool responsible for the actual composition based on the composition rules.

In the following section an example is presented to illustrate some key fea- tures of the subject-orientated approach. The example is a software development applications consisting of multiple tools. Harrison and Ossher introduce each tool as a subject that will be integrated with the application. This example clearly shows that a gradual integration implementation strategy will benefit from a subject-orientated approach, the subject describes the functionality of the tool that needs to be integrated and the composition rules specify how that integration should occur.

In the next section the authors discuss related work from three important topics in the subject-orientated approach: (1) Other approaches that also take into account that objects have different “views” depending on the context. (2) Routing messages from originators to participants within a suite of integrated tools. (3) Approaches that focus on composition technology using rules that specify interdependent behavior.

In their conclusion Harrison and Ossher state that they have discussed sev- eral important issues associated with software composition, which is true. They expected that subject compositors would be an important area of research, this is however partially true. SOP research has come to an halt, but a new related domain called aspect-oriented programming has arisen focusing on composition of software components to provide a clear separation of concerns.

Conclusion

In this paper Harrison and Ossher have explained the subject-orientated ap- proach, this approach extends the normal object-orientated approach and en- hances the architecture of the application by dividing the application in multiple subjects. Interaction between subjects is also possible by defining separate com- position rules. This approach leads to a tighter encapsulation of properties, as a subject only has access to the properties it defined. Although the subjects can be developed independently, they should operate using the same application semantics to allow subject composition.

At first the subject-orientated approach idea looks promising, providing a nice method for separating concerns. However further study of the available re- search in the subject-orientated programming domain reveals that the research has come to an halt and subject-orientated programming frameworks such as Hyper/J and CME are discontinued. However, aspect orientated programming, an approach that also addresses separation of concerns, is related to the subject- orientated approach. The difference between the two is that subject-orientated programming is based on operation-level joining using separate composition rules, while with aspect orientated programming the behavior is forced by the aspect [2]. Both approaches are organized under the term aspect-orientated soft- ware development together with other approaches that deal with composition technology.

References

[1] William Harrison and Harold Ossher. Subject-oriented programming: a critique of pure objects. SIGPLAN Not., 28(10):411–428, 1993.

[2] Harold Ossher and Peri L. Tarr. Operation-level composition: A case in (join) point. In ECOOP ’98: Workshop ion on Object-Oriented Technology, pages 406–409, London, UK, 1998. Springer-Verlag.