delegation vs. inheritance
in [OOP]
|
From: Thomas Kowalski on 8 Aug 2006 07:07 Dear Rick, since this discussion seems to move from the original subject, I created a new post "Where to make tradeoffs in OOA/D" > This might be the real problem. Are you absolutely sure nobody in the > world has thought about this kind of things before ? Of course there are similar algorithms tackling that domain and I use as much of the vocabulary as I think is appliable. But since there are new aspects I sometimes try to emphasis this by "inventing" new names. > A good domain model even triggers new or sharpened > requirements, but domain "fluency" is much more needed when we reach > the phase of detailed design. Can you elaborate this a bit more? > > Isn't it true that the class model is just a domain > >modell adapted to the underlying technologie? > > Yes it should be. Most often technicians take over somewhere and they > most often dont bother the least with the domain and the most with the > "working" application. I think this is the point the there the other thread (see at top) should start. I guess this is basicly there MDA wants to fit in by providing a well defined way to translate from the domain to code. (see also the new thread "Where to make tradeoffs in OOA/D") > >Your approach seems to capture the requirement of easy understanding > >but isn't maintainability much more then that? > > I dont think I understand exactly what you mean here , nor do I think > we should bother with this if basics are violated. (see the aspects of maintainabilty in the new thread) > Certainly not > because you should know that this manager classes require not > independently userful "property bags". If an object cant do what it > should or isnt what it should be for layman your maintainability is > maybe not helped either. I guess I understand a bit better now and have to agree. > >Moreover the reconstruction > >process/algorithm is divided into a matching phase, simple and complex > >reconstruction. > > Then the questions. What would you call the series of points in the > matching phase ? Might this be an object ? could it have a > recognizable name ( ) a contour . the _contours_ of a two consecutive _slices_ are going to be connected (by creating the _triangles_ of the _surface_) if the probabilty that they belong together is high enough. -> objects are contour, slice, triangle, surface ?? > What is the essential difference between simple en complex > reconstruction and what are start and end of those phases ? Can you > find names for both series of points as a RESULT of both ? Usually one contour is connected to exactly one contour in the neighboring slice (simple case). But sometimes one contours need to be connected to many (complex case) or no (called final contours) contours in the neighboring slice. -> might implie that the resultant is _surface_? But there are two ways to get a surface? Whould you in this case subclass and create simpleSurface and complexSurface? > >To make the concepts clear I created an object that is > >calling an "triangulation service" class that in turn invokes the > >methodes of the "matching" class, the "simple reconstruction" class and > >so on. > > Does that mean that somebody who can follow the words of your thesis > can also understand the software ? I certainly hope so! > >> Give the least heavy class this new responsibility. > > > >Somehow I am not really comfortable doing so. I am still searching for > >some justification to put some responsibilities / behaviour in a > >certain class. After some thinking I guess I could be comfortable with the heuristic that the methode belongs to the more "active" class with might be the graph since it is splitting the contour. > More questions: what kind of collections of contrours can you detect ? a collection of contours is a slice or at least a part of it. > Can you give sensible *object like* names > to those ? Can you assign both behavior and state ? What is the > relation between your collection of contours and a graph ? There is no connection between a slice and a graph. The graph is created on basis of a set of contours in the complex case of reconstruction to divide the one contour that needs to be connected with many contours. This provides a one to one mapping of contours again (simple reconstruction). > Then much later link in your new object to your design and see what > is does( it surely will push towards a refactoring of other objects) Got it. > My question is not if its in the code or software . > My question was: are there, in your view, contours that are not dividable ? No, theoreticly all contours might be divided. But just a few are really going to be divided. > Your objects might not be the highlights or > the destinguishable aspects. Instead you might attribute different > behaviors to very well known objects. I am not sure whether I understood this. Are non highlights still "good" objects? > >Perhaps you can explain why you state that an sufficent domain > >knowledge helps to reduce the class size? > > Isnt that obvious ? It could be from our dialogue. You start with a > description of two objects, then when I have to know more about your > domain you introduce Point,Edge etc...If I have 4 objects to partition > system behavior I have more possibilities for a meaningful division > then with 2 etc. I Now I understand your point and have to agree once more. But some objects like edges or points really are just property bags. > > The class contour don't need to know anything about the graph. > > The interesting thing is that you said what a graph is. The definition > of graph seems related to the definition of contour an;yway. I think > that there is a composite/ collection of points and edges somewhere > too. But thats speculation ofcourse. The more interesting point would > be to divide behavior between > Point > Contour > Edge > Graph A contour is a collection of (object)points. A graph is a collection of (graph)points. Edges are given indirectly by references from one point to another. The concept of an edge doesn't contribute any good to the graph. So far it seems that my current implementation is going in the right direction to support your view of design. >.. acquire knowledge of concepts ( potential objects) in the neighboorhood. Then again, is any concept an candidat
From: Thomas Kowalski on 8 Aug 2006 08:05 Hello Ed, thanks for contributing to this thread. Maybe you might be also interested in the newly opened thread "Where to make tradeoffs in OOA/D". > "Basicly I want to use it to provide a way to save memory ressources in > case this application and an application that's based on a similar > datastructures are merged to one application." So you're working on one > application, and think it might be merged with another existing > application out there at some time in the future. Correct > I'm not entirely convinced that two applications can be cost-effectively merged just > because they share the same data-structures; The applications are solving the same problem (in a bigger picture). Workflow of user might be simplified a lot by providing a single interface for all this. > The important thing here, however, is that you're looking to, > "Save memory resources," and that's not a primary goal of OO. ( Please take a look at the newly opend thread) > I've never seen an independent > object myself :)) (There's no good way to end a bracketted aside that > ends with a smiley, is there?) I think is cite is a little far from my statement, but yes, there is no easy way to includ a smily in brackets. > Thomas: it's ok. There's no Absolute Software Law out there that says > it's better to put method X in Class A rather than Class B ... Still some helpfull ideas or guidlines might exist? E.g. after thinking a bit I felt comfortable assigning the methode to the more active object (the graph, since its splitting the contour like a knife cuts cake). > .. border cases that you're talking about; no policia will tear you from > your bed one stormy Tuesday night. That's the only reason I am still able to sleep well :) > For me, OO is flexibility through variance encapsulation What is this? > so if you're not sure in which class to put a > method, consider how the classes will develop over time; For a beginner it's impossible to tell. Especially then the requirements change _a lot_. Therefore I am searching for good advise here. > Another important question to come out of all this is: what is the > granularity of your encapsulation? In other words: are you using C++ > namespaces? Not yet, but I divided classes in coursly four groups: - framework (MFC and other GUI stuff) - common (datastructures like object, slice, contour etc) - filtering (manipulate the object) - reconstruction (graph and other datastructures just used for reconstruction) > (particularly if you're employing a hierarchical namespace, see: > http://www.edmundkirwan.com/servlet/fractal/cs1/frac-cs70.html). I will take a look. Thanks for your help, Thomas
From: Rick Elbers on 8 Aug 2006 10:57 Dear Thomas, It was certainly interesting. Your last reaction is still going deeper into your domain and thats also the point where I should really study it since I have no knowledge about it. I should at least study your dissertation to be of any help:-) I also suffer language problems when we go into details of the domain as we should. I hope that this discussion added anything to your feelings of competence concerning oo, Regards, Rick Op 8 Aug 2006 04:07:17 -0700 schreef "Thomas Kowalski" <th-ko(a)gmx.de>: >Dear Rick, >since this discussion seems to move from the original subject, I >created a new post "Where to make tradeoffs in OOA/D" > >> This might be the real problem. Are you absolutely sure nobody in the >> world has thought about this kind of things before ? > >Of course there are similar algorithms tackling that domain and I use >as much of the vocabulary as I think is appliable. But since there are >new aspects I sometimes try to emphasis this by "inventing" new names. > >> A good domain model even triggers new or sharpened >> requirements, but domain "fluency" is much more needed when we reach >> the phase of detailed design. > >Can you elaborate this a bit more? > >> > Isn't it true that the class model is just a domain >> >modell adapted to the underlying technologie? >> >> Yes it should be. Most often technicians take over somewhere and they >> most often dont bother the least with the domain and the most with the >> "working" application. > >I think this is the point the there the other thread (see at top) >should start. >I guess this is basicly there MDA wants to fit in by providing a well >defined way to translate from the domain to code. >(see also the new thread "Where to make tradeoffs in OOA/D") > >> >Your approach seems to capture the requirement of easy understanding >> >but isn't maintainability much more then that? >> >> I dont think I understand exactly what you mean here , nor do I think >> we should bother with this if basics are violated. > >(see the aspects of maintainabilty in the new thread) > >> Certainly not >> because you should know that this manager classes require not >> independently userful "property bags". If an object cant do what it >> should or isnt what it should be for layman your maintainability is >> maybe not helped either. > >I guess I understand a bit better now and have to agree. > >> >Moreover the reconstruction >> >process/algorithm is divided into a matching phase, simple and complex >> >reconstruction. >> >> Then the questions. What would you call the series of points in the >> matching phase ? Might this be an object ? could it have a >> recognizable name ( ) > >a contour . the _contours_ of a two consecutive _slices_ are going to >be connected (by creating the _triangles_ of the _surface_) if the >probabilty that they belong together is high enough. >-> objects are contour, slice, triangle, surface ?? > >> What is the essential difference between simple en complex >> reconstruction and what are start and end of those phases ? Can you >> find names for both series of points as a RESULT of both ? > >Usually one contour is connected to exactly one contour in the >neighboring slice (simple case). But sometimes one contours need to be >connected to many (complex case) or no (called final contours) contours >in the neighboring slice. >-> might implie that the resultant is _surface_? But there are two ways >to get a surface? Whould you in this case subclass and create >simpleSurface and complexSurface? > >> >To make the concepts clear I created an object that is >> >calling an "triangulation service" class that in turn invokes the >> >methodes of the "matching" class, the "simple reconstruction" class and >> >so on. >> >> Does that mean that somebody who can follow the words of your thesis >> can also understand the software ? > >I certainly hope so! > >> >> Give the least heavy class this new responsibility. >> > >> >Somehow I am not really comfortable doing so. I am still searching for >> >some justification to put some responsibilities / behaviour in a >> >certain class. > >After some thinking I guess I could be comfortable with the heuristic >that the methode belongs to the more "active" class with might be the >graph since it is splitting the contour. > >> More questions: what kind of collections of contrours can you detect ? > >a collection of contours is a slice or at least a part of it. > >> Can you give sensible *object like* names >> to those ? Can you assign both behavior and state ? What is the >> relation between your collection of contours and a graph ? > >There is no connection between a slice and a graph. The graph is >created on basis of a set of contours in the complex case of >reconstruction to divide the one contour that needs to be connected >with many contours. This provides a one to one mapping of contours >again (simple reconstruction). > >> Then much later link in your new object to your design and see what >> is does( it surely will push towards a refactoring of other objects) > >Got it. > >> My question is not if its in the code or software . >> My question was: are there, in your view, contours that are not dividable ? > >No, theoreticly all contours might be divided. But just a few are >really going to be divided. > >> Your objects might not be the highlights or >> the destinguishable aspects. Instead you might attribute different >> behaviors to very well known objects. > >I am not sure whether I understood this. Are non highlights still >"good" objects? > >> >Perhaps you can explain why you state that an sufficent domain >> >knowledge helps to reduce the class size? >> >> Isnt that obvious ? It could be from our dialogue. You start with a >> description of two objects, then when I have to know more about your >> domain you introduce Point,Edge etc...If I have 4 objects to partition >> system behavior I have more possibilities for a meaningful division >> then with 2 etc. I > >Now I understand your point and have to agree once more. But some >objects like edges or points really are just property bags. > > >> > The class contour don't need to know anything about the graph. >> >> The interesting thing is that you said what a graph is. The definition >> of graph seems related to the definition of contour an;yway. I think >> that there is
From: H. S. Lahman on 8 Aug 2006 12:45 Responding to Elbers... >>Inheritance is simply a <rather simple> set of rules for determining >>what properties a particular member of the root class actually has. >>That is very handy for generalization/specialization where the same >>basic entity can come in different flavors that have a few unique >>properties. > > > I am sorry to say but I really think this is a misconception. > Inheritance is ment to support behavioral relations of the type "is > a". In the real world "is a" doesnt mean having a few unique > properties imho. In fact every class "has " properties. Pointing to > delegation. Some have more others have less, in fact thats secundair > to their entity and resposibilities and certainly to their inheritance > tree. We can put it in a more filosofical way: something or someone is > characterized by: > 1) What it does. > 2) What is has. > Maybe its another Europe USA kind of thing:-) I don't think there is any misconception. OO subclassing is pure set theory (IMO, even purer in OOA/D class systems than in OOP type systems). In OOA/D class systems classes are sets and subclasses are subsets. (In OOP the OOA/D class system maps into an OOPL type system where the notions of identity and set membership are less explicit because of the emphasis on interfaces, but the mapping is still 1:1.) Subclassing just allows us to have specializations of the basic nature of an entity. Thus the members of a subclass are always members of the root superclass set and share their essential nature with all other members of that root superclass set. Hence the notion is is-a: the subclass member is <always> a member of the root superclass set (and any intervening superclasses in the line of ascent). [Note that a major difference between OO Class systems and Data Modeling class systems is that in an OO context the superclasses are not separately instantiated from the leaf subclasses as one can do in Data Models. A single object with unique identity implements the entire tree and must possess all of the properties defined in a line of ascent through the entire tree.] Thus an OOA/D subclassing diagram is simply a Venn Diagram in tree form. In an OO context that representation is convenient because entity sets are defined in terms of property sets that all members of the set share in common (as opposed to an individual property value defining the subset). The tree format simply makes it easy to define both the subset boundaries and the properties that define membership in those subsets (i.e., the defining nature of the set boundary). Thus members of OO subclasses all share the same common properties as all members of the superclass sets in a direct line of ascent. However, members of a subset are distinguished from members of other sibling subsets based on unique properties that only the members of their subset possess. Inheritance is simply that rule of direct line of ascent that determines what specific properties a member of a leaf subclass in hand actually has. (One can complicate it somewhat with implementation inheritance, interface inheritance, and multiple inheritance but it still comes down to a deterministic way to determine leaf subclass properties.) If one looked at an OO subclassing tree in Venn Diagram format, one would use inheritance in the same way. One would identify all the enclosing set boundaries, look up the properties that each enclosing set had, and assign those properties to members of the innermost subset. IOW, one has just replaced the direct line of ascent rule by a topological rule for tracing a path from the boundary of the innermost set to the outer boundary of the root superclass. <aside> In an OO context the nature of the properties one can abstract about a problem space entity is quite limited. The nature of the object is defined in terms of responsibilities rather than implementations (which provides a convenient mapping to 3GL type systems from OOA/D class systems). In addition, responsibilities are limited to knowledge (knowing something) and behavior (doing something). So your second property should be what the object knows rather than what it has. It is a subtle but important point because of the nature of "responsibility". It is only at the OOP level, where one is constrained by computational models, that a knowledge property must be mapped into a memory storage location as a value that the object "has". There is nothing in the OO paradigm that actually requires persistent data to implement a knowledge responsibility. So one occasionally encounters situations where a knowledge responsibility is met by simply computing a "new" value whenever the object is queried. BTW, inheritance and LSP apply to both knowledge and behavior responsibility properties. A lot of LSP debates about behaviors go in circles because nobody has noticed that LSP was violated because the knowledge attributes where redefined. In a classic recent example here the debate centered around deriving Rectangle behaviors from Square behaviors. The real problem was that Square was defined with a sideLength knowledge attribute while Rectangle was defined with majorSideLength and minorSideLength -- apples & oranges. </aside> >>OO subclassing and inheritance are defined in a manner that >>also allows polymorphic access of the /common/ properties. > > > This very surely is wrong even at the implementation level. > Polymorhpic behavior is certainly not mainly their to support > polymorphic access of common properties. Instead its their for common > access to polymorphic behavior. For instance ( in an old msdn example) > We have beasts that eat food. But we have food for carnivors, for > omnivors etc. Each eat different food, but all of them eat(food). The polymorphism associated with subclassing is known as inclusion polymorphism. Every member of the root set that is in direct line of descent /must/ provide an implementation for /every/ knowledge or behavior property defined in the superclasses in that direct line of ascent. Those implementations may be different among sibling subclasses but the semantics of the property defined at the superclass level is fixed and common to all members in direct line of descent. LSP provides a formalism for describing what
From: Dmitry A. Kazakov on 8 Aug 2006 14:15
On Tue, 08 Aug 2006 16:45:16 GMT, H. S. Lahman wrote: > BTW, inheritance and LSP apply to both knowledge and behavior > responsibility properties. A lot of LSP debates about behaviors go in > circles because nobody has noticed that LSP was violated because the > knowledge attributes where redefined. True. > In a classic recent example here > the debate centered around deriving Rectangle behaviors from Square > behaviors. The real problem was that Square was defined with a > sideLength knowledge attribute while Rectangle was defined with > majorSideLength and minorSideLength -- apples & oranges. It is not apples and oranges. It is squares and rectangles. (:-)) SideLength is a direct reflection of a trivial geometrical fact (theorem) about squares. This theorem does not hold for rectangles. End of story. The set of true propositions about squares is not a subset of the set of true propositions about rectangles. In other words: < Squares> is a subset <Rectangles>, but <Squares + the behavior of> is not a subset of <Rectangles + the behavior of> Most of LSP debates are about these apples and oranges. To believe in LSP is as silly as to do in that Shakespeare could write in Basic English. Isn't it a subset of English? -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de |