In contemporary object-oriented programming languages, classes are the fundamental building block for objects. This “class-oriented” approach has long been promoted as object-orientation, but is highlighted by DCI as a too limited view on objects. Objects span over more than a single class, which has been acknowledged in mainstream languages by the rise of features like extension methods, traits and mixins.
A class serves well as a static data structure, a collection of defining properties and relations defined by system architects and domain experts. When a class is instantiated as an object however, that object will interact with other objects in ways that does not directly associate to its basic definitions. A pen does not know how to write, writing requires interaction between for example a pen, a human and a paper. From a system perspective, neither of these objects are valid places for this interaction between objects called “writing”, instead an encompassing system will define how writing should occur, and will access the concerned object properties when needed during the process.
You may argue that the human may be a good place for this functionality. Writing however is a more generic process, or as DCI calls it, “Context”, than one that handles only the specific objects pen, human and paper. That's where Roles comes in. Writing can be done on basically any material, so in a “Writing” Context it makes sense that the object “Paper” should be referred to, or play the Role “Material” in the writing context. The same goes for the other objects:
Inside the Context, the objects will have their interacting functionality (moving the instrument using the writer, testing material limitations, etc) defined with RoleMethods. These RoleMethods needs to be attached directly on the role-playing object to ensure proper identity reference (and cognition), but they cannot be defined on the class since we don't care what object is playing the Role anymore, we only refer to it inside the Writing Context as “the Material”. This shows that objects span over more than just a class, since object functionality come and go during execution. Classes are too static for this dynamic behavior.
Note that the system-specific naming and terms above should be created in accordance with system architects and domain experts, to follow domain terminology and a given mental model as closely as possible.
See the Glossary for additional terminology details.