Saturday, September 01, 2012

A New Vision of Object-Oriented Programming (English)

Extract from the article (formatting is mine).
See also Mixin and treats.

...So the first new concept we introduce is roles. Whereas objects capture what objects are, roles capture collections of behaviors that are about what objects do...

There is more below.
Ниже есть продолжение.


The interactions that weave their way through the roles are also not new to programming: we call them algorithms.... What's interesting is that we consciously weave the algorithms through the roles. It is as if we had broken down the algorithm using good old procedural decomposition and broken the lines of decomposition along role boundaries. We do the same thing in old-fashioned object modeling, except that we break the lines of procedural decomposition (methods) along the lines of object boundaries.

Unfortunately, object boundaries already mean something else: they are loci of encapsulated domain knowledge, of the data. There is little that suggests that the stepwise refinement of an algorithm into cognitive chunks should match the demarcations set by the data model. Old-fashioned object orientation forced us to use the same mechanism for both demarcations, and this mechanism was called a class. One or the other of the demarcating mechanisms is likely to win out. If the algorithmic decomposition wins out, we end up with algorithmic fragments landing in one object but needing to talk to another, and coupling metrics suffer. If the data decomposition wins out, we end up slicing out just those parts of the algorithm that are pertinent to the topic of the object to which they are assigned, and we end up with very small incohesive methods. Old-fashioned object orientation explicitly encouraged the creation of such fine-grain methods, for example, a typical Smalltalk method is three statements long.

...It is almost a literal expansion from the Use Case. That makes it more understandable than if the logic is spread over many class boundaries that are arbitrary with respect to the natural organization of the logic—as found in the end user mental model...

...Both the roles and classes live in the end user's head. The two are fused at run time into a single object. Since objects come from classes in most programming languages, we have to make it appear as though the domain classes can support the business functions... At compile time programmers must face the end user's models both of Use Case scenarios and the entities they operate on. We want to help the programmer capture those models separately in two different programming constructs, honoring the dichotomy in the end user's head. We usually think of classes as the natural place to collect such behaviors or algorithms together. But we must also support the seeming paradox that each of these compile-time concepts co-exists with the other at run time in a single thing called the object.

...an object of a class supports not only the member functions of its class, but also can execute the member functions of the role it is playing at any given time as though they were its own. That is, we want to inject the roles' logic into the objects so that they are as much part of the object as the methods that the object receives from its class at instantiation time...we set things up so each object has all possible logic at compile time to support whatever role it might be asked to play. However, if we are smart enough to inject just enough logic into each object at run time, just as it is needed to support its appearance in a given role, we can do that, too.
http://www.artima.com/articles/dci_vision.html

No comments:

Post a Comment