Abstract public member variales?
in [OOP]
|
Prev: Name of construct
Next: Deriving - .NET example
From: H. S. Lahman on 8 Oct 2006 13:23 Responding to Guild... >>I think what it comes down to is that we still fundamentally >>disagree about what an application requirement is. So long as you >>believe that things like the formula one must use to compute >>benefits or specifying whether a list is ordered or not is an >>implementation option rather than an application requirement, we >>are at an impasse. > > > I know that my customer will not care how the software is implemented > so long as it produces the correct results and is maintainable. I agree > that using the formula supplied by the customer is probably the easiest > and best way to achieve that, but I am shocked by the suggestion that > it is the only way. I am sure I could come up with dozens of examples > of how formulas can be rearranged to produce the same results with > different computations, but I am just as sure that you can also do > that, so I do not think that would help. All you can do is cosmetic modification that is allowed via mathematics (e.g., transitive reordering of the computation of terms). For example, I can represent any algebraic expression in RPN and it will look vastly different. But it is still the same expression. [More at the end.] >>>It is the only bit of serious misunderstanding left between us. >>>You claim that every function that is called in functional >>>decomposition must have its requirements be a subset of the >>>requirements of the calling function. It seems as though you >>>cannot imagine how it could be otherwise, while I cannot imagine >>>why you would even suggest such a thing. >> >>You are correct. I cannot imagine that. That is the way >>functional decomposition trees are constructed. > > > I am shocked again. I suspect it is the danger of any discussion around > such a subtle topic, but if we understand each other (highly unlikely) > then what you just claimed to not be able to imagine is exactly what > you describe below. If you really could not imagine it, then you > certainly could not describe it! Yes, I can imagine a non-rigorous construction. I can also imagine lots of alternatives for doing functional decomposition than the SA/D/P way. But the SA/D/P paradigm did it this way. >>[That's assuming one wants to be rigorous. As I mentioned, simply >>working down from higher abstraction of function to lower >>abstraction has high risk of omitting requirements from the tree >>entirely. Even if one makes another pass to determine if any >>requirements are missing, the tree may require major surgery if >>there were omissions.] > > > Omitting requirements would not cause this issue. Remember, the > requirements of lower nodes are supposed to be subsets of the > requirements at higher nodes; in other words, they are expected to omit > some of the requirements of the higher nodes. The issue is that because > lower nodes are subsets, by the very definition of 'subset', the lower > nodes cannot have any requirements that are not requirements of the > higher nodes. As I said, the risk is of requirements being omitted from the /entire/ tree (i.e., never being resolved in the design). The rigor of delegating subsets of requirements is aimed at eliminating that problem. > However, now it seems that we both believe that lower nodes can have > requirements that do not appear in higher nodes, so I am not sure where > the confusion comes from. That's only true for requirements generated from the design itself; not the application requirements. >>>When you make a general claim like that, surely you must mean >>>that it is true in all cases, no matter how small. If you could >>>see exceptions, then you would understand where my position might >>>be coming from and everything would be cleared up. >> >>SA/D/P provided a methodology of constructing the tree. One >>either follows that or uses a different approach (e.g., the OO >>paradigm). > > > All that I actually want to do is send a message and expect a response > to that can use one object as part of the implementation of another in > the Strategy pattern. I do not understand where the idea of strict > adherence to a certain methodology came from. If one methodology does > not allow me to do what I want safely, then I choose a different one. > Unfortunately, no OO methodology can do that by nature. This is completely out of context (i.e., SA/D/P functional decomposition and Spaghetti Code). I have already explained why the coupling of request forwarding is bad in the GoF Strategy implementation. >>>If the requirements of the 'length()' function are truly a subset >>>of the requirements of a sorting function that uses it, then my >>>understanding would be aided immensely by simply defining a >>>requirements specification for a sort and a requirements >>>specification for length() such that the one for length() is a >>>subset of the one for sort(). >> >>Again, the length() example was from 'find', not sort. The 'find' >>requirement was not to provide a length; it was to properly deal >>with list termination. The notion of 'length' was the solely the >>designer's view of the implementation of 'find'. > > > Remember this proof: > > "If there was no decomposition below Benefit3 how does the overall > problem get solved? The only way it can be solved is if Benefit3 > implements all the functionality of ComputeAfterTaxIncome, GetDBInfo, > and Compute within it own <undecomposed> implementation. But that > functionality is defined by requirements on those functions. Therefore > the requirements that are delegated to Benefit3 for resolution must > include all the requirements that the decomposed functions resolved. > QED." > > Let me modify it to talk about find() and length(), since I presume the > proof was meant to be general and was only using Benefit3 as an > example: > > If there was no decomposition below find() how does the overall problem > get solved? The only way it can be solved is if find() implements all > the functionality of length() within it own <undecomposed> > implementation. But that functionality is defined by requirements on > length(). Therefore the requirements that are delegated to find() for > resolution must include all the requirements that length() resolved. > QED. That substitution is only valid if the application requirements
From: Brendan Guild on 8 Oct 2006 17:29 H. S. Lahman wrote in news:3uaWg.363$lj2.140(a)trndny01: > Responding to Guild... > > So this will be my last contribution to the thread. FWIW, I found > it quite interesting while it lasted. I suppose that it is getting to be about that time. Fortunately, I think all the major issues have been resolved. You can be sure that I will be studying this thread for quite a while, so here is my initial post-mortem. >> I agree that using the formula supplied by the customer is probably >> the easiest and best way to achieve that, but I am shocked by the >> suggestion that it is the only way. I am sure I could come up with >> dozens of examples of how formulas can be rearranged to produce the >> same results with different computations, but I am just as sure that >> you can also do that, so I do not think that would help. > > All you can do is cosmetic modification that is allowed via > mathematics (e.g., transitive reordering of the computation of > terms). For example, I can represent any algebraic expression in > RPN and it will look vastly different. But it is still the same > expression. [More at the end.] I am afraid that you might have missed the point slightly. I can use rearrangement of formulas in a way that is more damaging to your claim than that. I am aware that you will not respond to correct me, so I will be sure to make it completely bullet-proof and I think it will be. >> I suspect it is the danger of any discussion around such a subtle >> topic, but if we understand each other (highly unlikely) then what >> you just claimed to not be able to imagine is exactly what you >> describe below. If you really could not imagine it, then you >> certainly could not describe it! > > Yes, I can imagine a non-rigorous construction. I can also > imagine lots of alternatives for doing functional decomposition > than the SA/D/P way. > But the SA/D/P paradigm did it this way. It is odd, but it seems that somewhere along the way your side of the conversation shifted to talking about a particular standard of functional decomposition while I continued to talk about functional decomposition in general (or at least the way I would do it). I will have to wander back along the thread to discover where that happened. I hope you made it clear. >> Omitting requirements would not cause this issue. Remember, the >> requirements of lower nodes are supposed to be subsets of the >> requirements at higher nodes; in other words, they are expected >> to omit some of the requirements of the higher nodes. The issue >> is that because lower nodes are subsets, by the very definition >> of 'subset', the lower nodes cannot have any requirements that >> are not requirements of the higher nodes. > > As I said, the risk is of requirements being omitted from the > /entire/ tree (i.e., never being resolved in the design). The > rigor of delegating subsets of requirements is aimed at > eliminating that problem. Yes, I suppose that would make debugging easier. That way as one walks down the lattice the requirements that need to be checked do not change from level to level. However, I think we have both made it clear that one cannot strictly follow that rule in practice, there must always be design requirements. In fact, I do not see how it is possible to follow that rule at all. The notion of 'length()' resolving a termination requirement always seemed a little unlikely to me, like a far stretch to justify calling a useful function that does not really have a place in the requirements it is being used to satisfy. In this thread, you always seemed to assert that if there was an algorithm of multiple steps to satisfy a requirement, then that requirement was not indivisible. However, often a function is only required to produce a single value, and the various requirements are the properties of that value relative to the input to the function. In that situation, it is likely impossible to divide the properties of the result among the lower nodes, the properties are only achieved when the final result value is found. The requirements of the function are not achieved one at a time: they all occur only as the final result of all the function calls working together in an algorithm, just as length() aids in the process of getting the result for find(), but length() really has no part in satisfying one of the required properties of that result. >> However, now it seems that we both believe that lower nodes can >> have requirements that do not appear in higher nodes, so I am not >> sure where the confusion comes from. > > That's only true for requirements generated from the design > itself; not the application requirements. This is the part that makes it satisfying to end the thread here, because even after all this, it turns out that I was correct throughout this thread. The distinction between design and application requirements was something that you made only recently; until now requirements were just requirements. >>>>When you make a general claim like that, surely you must mean >>>>that it is true in all cases, no matter how small. If you could >>>>see exceptions, then you would understand where my position >>>>might be coming from and everything would be cleared up. >>> >>>SA/D/P provided a methodology of constructing the tree. One >>>either follows that or uses a different approach (e.g., the OO >>>paradigm). >> >> >> All that I actually want to do is send a message and expect a >> response to that can use one object as part of the implementation >> of another in the Strategy pattern. I do not understand where the >> idea of strict adherence to a certain methodology came from. If >> one methodology does not allow me to do what I want safely, then >> I choose a different one. Unfortunately, no OO methodology can do >> that by nature. > > This is completely out of context (i.e., SA/D/P functional > decomposition and Spaghetti Code). I have already explained why > the coupling of request forwarding is bad in the GoF Strategy > implementation. Unfortunately, I must admit to being shocked again. When did the context become SA/D/P functional decomposition? I ask that rhetorically because it no longer matters, but for me that context shift never took place. You were making incorrect 'responsibility subset' claims before SA/D
From: Brendan Guild on 8 Oct 2006 20:34 Dmitry A. Kazakov wrote in news:1rrf414ny5dzk$.7bnaxdo85uyj.dlg(a)40tude.net: > On Sat, 07 Oct 2006 22:11:07 GMT, Brendan Guild wrote: > >> interface Thing { >> Behaviour applyVerb(Verb v); >> IndirectBehaviour applyIndirectVerb(Verb v); >> } >> >> Where Behaviour has a method that might be called 'doIt()' and >> IndirectBehaviour might have 'doItTo(Thing t)'. > > And what do you do when there were more cases than nominative and > accusative? For instance dative: X gives Y to Z. (prepositions and > cases are interchangeable to some extent) In traditional IF adventures, there is no nominative case because verbs have no subjects. I actually meant applyVerb() to be used for the accusative case and applyIndirectVerb to be used for the dative case and whenever the verb is being applied to an indirect object. I perhaps should have written 'doItTo(Thing t)' as: IndirectBehaviour::doItTo(Thing indirectObject) just to make it clear. The thing which applyVerb() is being called on is implicitly the direct object, not the subject. Verbs which do not have a direct object would have to be handled differently.
From: Dmitry A. Kazakov on 9 Oct 2006 03:57
On Mon, 09 Oct 2006 00:34:00 GMT, Brendan Guild wrote: > Dmitry A. Kazakov wrote in > news:1rrf414ny5dzk$.7bnaxdo85uyj.dlg(a)40tude.net: > >> On Sat, 07 Oct 2006 22:11:07 GMT, Brendan Guild wrote: >> >>> interface Thing { >>> Behaviour applyVerb(Verb v); >>> IndirectBehaviour applyIndirectVerb(Verb v); >>> } >>> >>> Where Behaviour has a method that might be called 'doIt()' and >>> IndirectBehaviour might have 'doItTo(Thing t)'. >> >> And what do you do when there were more cases than nominative and >> accusative? For instance dative: X gives Y to Z. (prepositions and >> cases are interchangeable to some extent) > > In traditional IF adventures, there is no nominative case because > verbs have no subjects. I actually meant applyVerb() to be used for > the accusative case and applyIndirectVerb to be used for the dative > case and whenever the verb is being applied to an indirect object. > > I perhaps should have written 'doItTo(Thing t)' as: > IndirectBehaviour::doItTo(Thing indirectObject) > just to make it clear. > > The thing which applyVerb() is being called on is implicitly the > direct object, not the subject. Verbs which do not have a direct > object would have to be handled differently. I see. However a verb may have >2 arguments. The first is hidden, which is the object. What about the second, third, [forth]? Another problem with "do verb" is that some verbs are symmetric: "fairy dances with a dwarf." Probably natural language model is inadequate as a basis for implementation? After all, when we talk about dancing fairies, we mean a lot of shorter individual interactions between smaller objects. This decomposition happens in each other brain, which model and then render the scene. A game engine is more like brain than a natural language. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de |