Subject-oriented programming is an approach in programming which seek to make it easier to make extentions and customizations (even unplanned) in existing object oriented programs.
A subject is a view, or a way of seeing a specific domain. We only consider what interface is relevant to our domain, which greatly reduces the complexity. Its usually not just one class, but its rather a collection of classes (or even just some parts of classes - e.g. a few methods) used for this specific domain or area in the application. A subject can be a whole application or a part of an application within a specific domain.
The subjects can be glued together to form new subjects, reusing the functionality from the individual subjects, much in the same way as we know it in component-based programming. Composition rules define how subjects can be composed, and naturally not all subjects "fit together" and therefore maybe "gluing" subjects are needed to bridge between different interfaces in the subjects.
On a larger scale, Subject-oriented programming-in-the-large, is concerned with how to divide object-oriented systems into subjects, and defining how the subjects individually can be composed (using composition rules). This eases the solving of problems that might arise when maintaining and extending large object-oriented systems.
The original source code is not needed when composing subjects, making it easier to extend existing applications with new unplanned functionality, even for teams not prior connected to the project.
William Harrison and
Harold Ossher, Subject-Oriented Programming (A Critique of Pure Objects),
Proceedings of the conference on object-oriented programming: Systems,
languages, and
applications, pp. 411-428, Washington, D.C., ACM. (1993)
IBM Research, Subject-oriented programming, website: http://www.research.ibm.com/sop/ (2006)
David L. McReynolds et. al.,Distributed Characteristics of Subject Oriented Programming: An Evaluation with the Process and Object Paradigms, 99 ACM Southeast Regional Conference (1999)