delegation vs. inheritance
in [OOP]
|
From: ulf on 27 Aug 2006 18:49 H. S. Lahman wrote: > > ... > > > > Are you suggesting I have no well-formed OO application if it includes > > a method whose result depends on the result of another method [which, > > as we agree, may depend on the object's state variables' current > > values]??? > > Absolutely. IC. Then I guess most applications that call themselves OO do not qualify as "well-formed" in your sense. Redefining what it means to be good OO in such a restrictive way does not sound very useful to me. Do you know any existing OO application that is "well-formed" through and through in your sense? > ... Eliminating that sort of hierarchical > specification dependency is one of the primary goals of the OO paradigm. Maybe it is a goal, maybe it just a means for the goal of reuseability. Anyway. Generally, a goal is like an ideal. It may be that you cannot meet it, it may be that you have to compromize it because you have also other, competing goals. Good design is about the best compromize, an application should be able to qualify as "well-formed" even if in one case (one method) it does not meet one of the goals. > ... > > The OO solution in both cases is to break up ClassA::methodA into > logically indivisible responsibilities and employ peer-to-peer > collaboration: > > ClassA::methodA(x) > temp = x+5 > myClassB.doIt(temp) > > ClassA::methodB(x) > Attr1 = x + 2 > > ClassB::doIt(x) > // do something with x to produce newX > myClassA::methodB(newX) > > Now one can specify and unit each method independently purely in terms > of its attribute value transformations. Yes, this is a good solution. > > <explanation of state machines used in OOM> > Thanks. > >><aside> > >>Note that in UML one defines messages at a different level of > >>abstraction, in an Interaction Diagram, than one defines objects and > >>their responsibilities. > > > > > > - If, as you said, (behavioral) responsibility = How and method = What, > > where does the concept of message fit between the How and the What? > > - This leaves for defining a responsibility (the What): OCL, state > > machines, activity diagrams? > > - I would say an Interaction Diagram defines what an object does when > > it receives (actually, when it processes) a message, namely what > > messages it then sends. It does not define the message. > > No, it has nothing to do with what the object does. An Interaction > Diagram defines the collaborations between objects. Those > collaborations are expressed as messages passed between them. The > sequencing of those messages essentially defines the overall flow of > control of the application solution. I should not have said an Interaction Diagram *defines* what *an* object does... Better: an Interaction Diagram shows several objects and what they do wrt. message-sending when they a receive message within a certain situation. Well this is still not unattackably right, but good enuff, I hope. My question remains: If you talk of messages/Interaction as being at a different level of abstraction, and responsibility is the What-level and method the How-level, where is then the messages/Interaction-level? > >>Theoretically one could design every object, > >>every behavior responsibility, every statechart, and every method in a > >>well-formed OO application before defining a single message. > >>One could then make a pass where one examined each method's precondition > >>for execution in turn. One could then match that precondition to the > >>postconditions for executing each of the other methods until there was > >>an exact match. When there was an exact match, one would send the > >>message to the method with the precondition from the method having the > >>matching postcondition. ... > > > > This is confusing. A diagram might help (if you think it is worth it) > > <explanation> 1. Reading this again: If you can define methods before messages, does this mean the level of abstraction of message exchange is below the level of methods (How), which is below responsibilities (What)? 2. I understand now. You describe how the matching of preconditions to postcondition is used to determine when messages have to be sent from whom to whom. This sounds more like the execution model of a rule-based system to me. In case the notion of precondition applicable here also allows preconditions like "received message 'Withdraw' " then we are in OO's model of computation again. [But what would the matching postcondition be for such a precondition: "post message 'Withdraw' "? In that case, the insertion of a message exchange would not be surprising any more.] Ulf Schünemann
From: ulf on 27 Aug 2006 19:45 H. S. Lahman wrote: > > ... A class system is definitely not a system of > types. As I pointed out already, the only place types appear at all in > OOA/D is in attribute ADTs. If OOA/D has two modeling concepts, one called "Class" and another called "Type", then this is no proof that "Type" captures the most general notion of type and that consequently classes are not types. You need a different argument. I liked your attempt to list properties where types and classes differ. However, we seem to disagree whether in those properties you named, types and classes really differ. > > > ... > > But types are about classification! - Classification of "values" in > > some sense. > > Sure. But it is a classification based on access, not identity and set > membership. I think I understand now what a classification based on identity is. The reason why classes in OO make a classifcation based (among others) on identity is because they are classifying objects, where identity is crucial. But then if I have a *type* of objects then I am also making a classification based (among others) on identity? > > ... > > Those are technically Operations. As I explained in the other message, > they map to responsibilities. Actually UML provides a separate model > element, Interface, from the Class to describe how the class members are > accessed. It is that model element that maps to a type at the 3GL > level, not the Class in the Class Model. IOW, types are about what > messages the object in hand can process while classes are about which > objects one can talk to. Yes, the types in OOPLs are about messages an object can process. But similar to what I said about "Type" in OOA/D, what a OOPL calls "type" does not define what the general notion of type is. Hence if UML map its classes to sth else than an OOPL "type", this is no proof that a class is not a type. > > ... > > Classes are pure sets. The crucial perspective, though, is that one has > an identifiable entity in hand and wants to determine who can talk to > it. Thus in OOA/D identity is crucial because it determines who > participates in collaborations. Relationships, in turn, provide the > constraints on who may participate. Those constraints are based on set > membership through classes because classes provide the infrastructure > for object relationships. So the class system provides a convenient way > to organize sets of identifiable entities so that access over > relationship paths is constrained. (One then uses relationship > instantiation to ensure that This entity can only talk to That subset of > entities in another class.) > > ... I think I see where you are heading. Can I summarize this as: Classes classify objects according to the relationships/relations/associations in which they may participate? Whereas, you think, types = interfaces classify objects according to the messages they accept. Can I then summarize your view as: A class system is a classification based on objects' context and thus primarily interesting to objects' clients: It defines to which objects a client can possibly navigate/send messages. A type system is a classification based on each individual object and thus primarily interesting to objects' implementations: It defines what messages an object must implement. > The important thing to note here is that to specify these activities in > the client's method I don't even have to know what class the receiving > object belongs to, much less what responsibility will be invoked or how > it will be accessed. ... > IOW, to collaborate at the OOA/D level I only need to identify the > receiver of my message. When you talk of classification based on access, I can image some things, and when you talk of interfaces they seem match to what you say, but here they don't: What does (the how of) accessing responsibility mean (if it is not about clients sending messages along some path to an identified receiver [because this is about class systems and class systems are supposedly not about access]). Ulf Schünemann
From: H. S. Lahman on 28 Aug 2006 12:03 Responding to Ulf... >>>Are you suggesting I have no well-formed OO application if it includes >>>a method whose result depends on the result of another method [which, >>>as we agree, may depend on the object's state variables' current >>>values]??? >> >>Absolutely. > > > IC. Then I guess most applications that call themselves OO do not > qualify as "well-formed" in your sense. Redefining what it means to be > good OO in such a restrictive way does not sound very useful to me. Do > you know any existing OO application that is "well-formed" through and > through in your sense? > > >>... Eliminating that sort of hierarchical >>specification dependency is one of the primary goals of the OO paradigm. > > > Maybe it is a goal, maybe it just a means for the goal of reuseability. > Anyway. Generally, a goal is like an ideal. It may be that you cannot > meet it, it may be that you have to compromize it because you have also > other, competing goals. Good design is about the best compromize, an > application should be able to qualify as "well-formed" even if in one > case (one method) it does not meet one of the goals. The OO paradigm is /designed/ to eliminate the hierarchical specification dependencies that plagued maintainability in traditional SA/D/P. If an OO application does not do that, then it is poorly formed by definition. > > >>... >> >>The OO solution in both cases is to break up ClassA::methodA into >>logically indivisible responsibilities and employ peer-to-peer >>collaboration: >> >>ClassA::methodA(x) >> temp = x+5 >> myClassB.doIt(temp) >> >>ClassA::methodB(x) >> Attr1 = x + 2 >> >>ClassB::doIt(x) >> // do something with x to produce newX >> myClassA::methodB(newX) >> >>Now one can specify and unit each method independently purely in terms >>of its attribute value transformations. > > > Yes, this is a good solution. Yes, it is a good solution from a maintainability viewpoint because it completely eliminates the hierarchical dependence on what other methods do from the original examples. That allows each method to be exhaustively unit tested in complete isolation. >>>><aside> >>>>Note that in UML one defines messages at a different level of >>>>abstraction, in an Interaction Diagram, than one defines objects and >>>>their responsibilities. >>> >>> >>>- If, as you said, (behavioral) responsibility = How and method = What, >>>where does the concept of message fit between the How and the What? >>>- This leaves for defining a responsibility (the What): OCL, state >>>machines, activity diagrams? >>>- I would say an Interaction Diagram defines what an object does when >>>it receives (actually, when it processes) a message, namely what >>>messages it then sends. It does not define the message. >> >>No, it has nothing to do with what the object does. An Interaction >>Diagram defines the collaborations between objects. Those >>collaborations are expressed as messages passed between them. The >>sequencing of those messages essentially defines the overall flow of >>control of the application solution. > > > I should not have said an Interaction Diagram *defines* what *an* > object does... > Better: an Interaction Diagram shows several objects and what they do > wrt. message-sending when they a receive message within a certain > situation. Well this is still not unattackably right, but good enuff, I > hope. More important, it allows the developer to think of solution flow of control at a different level of abstraction than individual object structure. The developer only needs to know What the responsibilities are to connect the flow of control dots. > > My question remains: If you talk of messages/Interaction as being at a > different level of abstraction, and responsibility is the What-level > and method the How-level, where is then the messages/Interaction-level? Solution flow of control just connects the dots among those isolated, encapsulated, self-contained, intrinsic responsibilities. IOW, thinking about collaborations is the context of interaction but defining objects is the context of abstracting problem space entities. That is directly tied to enabling DbC for defining flow of control... >>>>Theoretically one could design every object, >>>>every behavior responsibility, every statechart, and every method in a >>>>well-formed OO application before defining a single message. >>>>One could then make a pass where one examined each method's precondition >>>>for execution in turn. One could then match that precondition to the >>>>postconditions for executing each of the other methods until there was >>>>an exact match. When there was an exact match, one would send the >>>>message to the method with the precondition from the method having the >>>>matching postcondition. ... >>> >>>This is confusing. A diagram might help (if you think it is worth it) >> >><explanation> > > > 1. Reading this again: If you can define methods before messages, does > this mean the level of abstraction of message exchange is below the > level of methods (How), which is below responsibilities (What)? No, it is well above it. That's because one is methodologically constrained to make methods self-contained with no dependencies on other methods. In addition, one is constrained to hide their implementation from whoever the client might be. Once one has done that, one can think of collaborations and the overall flow of control at a much higher level of abstraction. It is just a matter of connecting the What dots. at the object level. > > 2. I understand now. You describe how the matching of preconditions to > postcondition is used to determine when messages have to be sent from > whom to whom. This sounds more like the execution model of a rule-based > system to me. However one wants to think of it, it provides a rigorous mechanism for defining overall solution flow of control. [Originally it grew out of R-T/E at about the time R-T/E developers realized that state machines were a much more rigorous way to define complex behavior. They needed to define protocols for interacting state machines.] The OO paradigm enables such rigor by the methodological constraints on construction even if one doesn't employ state machines. > > In case the notion of precondition applicable her
From: H. S. Lahman on 28 Aug 2006 12:58 Responding to Ulf... >>... A class system is definitely not a system of >>types. As I pointed out already, the only place types appear at all in >>OOA/D is in attribute ADTs. > > > If OOA/D has two modeling concepts, one called "Class" and another > called "Type", then this is no proof that "Type" captures the most > general notion of type and that consequently classes are not types. You > need a different argument. I liked your attempt to list properties > where types and classes differ. However, we seem to disagree whether in > those properties you named, types and classes really differ. Again, the only notion of 'type' in OOA/D is the highly restricted usage for abstracting complex knowledge responsibilities to scalar values. That is the ONLY place where any notion of 'type' is applied in OOA/D. I have a couple of OOA/D books on my bookshelf that don't even have a reference 'type' in the index and, AFAICR, don't mention types anywhere. >>>>... >>> >>>But types are about classification! - Classification of "values" in >>>some sense. >> >>Sure. But it is a classification based on access, not identity and set >>membership. > > > I think I understand now what a classification based on identity is. > The reason why classes in OO make a classifcation based (among others) > on identity is because they are classifying objects, where identity is > crucial. But then if I have a *type* of objects then I am also making a > classification based (among others) on identity? More precisely, classes abstract and classify problem space entities into sets. It is the problem space entities that have intrinsic identity, even at the level of individual screws in a warehouse stock bin. The class systems defines sets so one can distinguish membership for screws vs. nuts or pan head screws vs. hex head screws. Everything in OOA/D is based on that sort of set membership for problem space entities. > > > >>>... >> >>Those are technically Operations. As I explained in the other message, >>they map to responsibilities. Actually UML provides a separate model >>element, Interface, from the Class to describe how the class members are >>accessed. It is that model element that maps to a type at the 3GL >>level, not the Class in the Class Model. IOW, types are about what >>messages the object in hand can process while classes are about which >>objects one can talk to. > > > Yes, the types in OOPLs are about messages an object can process. > But similar to what I said about "Type" in OOA/D, what a OOPL calls > "type" does not define what the general notion of type is. Hence if UML > map its classes to sth else than an OOPL "type", this is no proof that > a class is not a type. Not quite. An Interface just maps messages to operations. But messages and operations are quite different things in OOA/D. The 3GL type systems only come into play after the separation of message and method has been eliminated by making the message the method signature. Note that at the 3GL type system level it is not possible to define two interfaces with different message names that map to the same object method. The object must provide an explicit method implementation for each interface's message name. To accommodate the mapping of multiple messages to the same operation from OOA/D, one has to resort to indirection (e.g., each message's method implementation makes a call to the same private method) or some other mechanism. (Some OOPL's, like Smalltalk, provide syntactic aliasing but it is usually defined globally for the namespace rather than on an object-by-object basis.) >>>... >> >>Classes are pure sets. The crucial perspective, though, is that one has >>an identifiable entity in hand and wants to determine who can talk to >>it. Thus in OOA/D identity is crucial because it determines who >>participates in collaborations. Relationships, in turn, provide the >>constraints on who may participate. Those constraints are based on set >>membership through classes because classes provide the infrastructure >>for object relationships. So the class system provides a convenient way >>to organize sets of identifiable entities so that access over >>relationship paths is constrained. (One then uses relationship >>instantiation to ensure that This entity can only talk to That subset of >>entities in another class.) >> >>... > > > I think I see where you are heading. Can I summarize this as: > Classes classify objects according to the > relationships/relations/associations in which they may participate? > Whereas, you think, types = interfaces classify objects according to > the messages they accept. Not quite. Classes /support/ using relationships to constrain collaborations because they are based on set membership of individual entities. But relationships are defined separately from classes. Relationships, though, are crucial for things like constraining access to state variables. (One can argue simplistically that OO relationships exist to manage global data by constraining access to it.) IOW, the big issue for OO relationships and, indirectly, class systems is Who has access to a given object and one assumes whoever it is can talk to the given object once they know who it is. [Note that in OOA/D one sends messages that are announcements of what the sender has done. That doesn't depend in any way on who the receiver is. IOW, the sender sends the same message no matter who it ends up being addressed to.] OTOH, type systems are indifferent about who the clients are. They are focused on how any given client can talk to the object in hand. IOW, the big issue for 3GL type systems is How one talks to the given object and it is assumed that the client obtained the right object to talk to by other means. > > Can I then summarize your view as: > A class system is a classification based on objects' context and thus > primarily interesting to objects' clients: It defines to which objects > a client can possibly navigate/send messages. I have to disagree with the context part. Classes abstract sets that already exist in the problem space. IOW, classes are intrinsic classifications of the problem space that do not depend on the specific solution's collaborations. [Not quite true due to tailoring of abstractions, but that gets into
From: adaworks on 29 Aug 2006 12:51
"Dmitry A. Kazakov" <mailbox(a)dmitry-kazakov.de> wrote in message news:15amzqxbo4zfl$.1oatjpdpgvu6d$.dlg(a)40tude.net... > > Yes. One can inherit from a type and get a completely new, unrelated type. > In Ada there is a type cloning for that: > > type My_Int is new Integer; > > as opposed to > > subtype My_Int is Integer; > Dmitry, I understand your fundamental point, with regard to inheritance, but the phrase, "completely new, unrelated type" is a little too strong for the example shown. My_Int, in your example is related to Integer and can be given an Integer view of a My_Int instance with special syntax. You are corrrect that direct substituability is not supported in this case. However, view conversion is supported. Some clarification is appropriate. For example, in your derived type, above, we could code, X : My_Int; Y : Integer; X := My_Int(Y); -- a view conversion On the other hand, if you had written, type My_Int is range Integer'First..Integer'Last; or type My_int is range -2**15 .. 2**15 - 1; -- sixteen bit integer; or type My_Int is range -2**31 .. 2**31 - 1; -- thirty-two bit integer; then, My_Int would have the values and structure of an Integer, but would be unrelated to any other type. A typical view conversion would be impossible. The approach to view conversion, in this case, between Integer and My_Int would be through unchecked_conversion. For those unfamiliar with Ada, the language allows a designer to define numeric types to a fine level of granularity. As a final example, a designer might define a 64 bit integer as, type Int_64 is range -2**63 .. 2**63 - 1; -- a signed integer for Int_64'Size use 64; -- force to 64 bit representation; Of course, many more variations are possible so the designer can map the numeric representations closely to the problem space. Richard Riehle |