confusion about data abstraction
in [OOP]
|
From: reju on 7 Dec 2006 00:37 Hi Lahman, Thanks for the explanation. Reju H. S. Lahman wrote: > Responding to Reju... > > > I have a little bit confusion about data abstraction in object oriented > > programming. > > My gut response is: Don't Do That! B-) > > Data is abstracted in OO development, but so much so that it often isn't > data anymore. In the OO paradigm objects are abstracted in terms of > responsibilities. Behavior responsibilities are an object's obligation > to do something. Knowledge responsibilities are an object's obligation > to know something. > > While what an object is obligated to know may be represented as data, > there is no requirement in the OO paradigm that it must be data. Thus > it is fair for something an object is supposed to know to be computed > every time that knowledge is requested. > > So think in terms of /what/ an object needs to know to contribute to the > problem solution and don't worry about how one represents that knowledge > later. > > > I have seen that two perspective of data abstraction, > > > > 1. Data abstraction can be viewed as the process of refining away the > > unimportant details of an object, so that only the useful > > characteristics that define it remain. > > > > 2.Abstraction refers to the act of representing essential features > > without including the background details or explanations. Classes use > > the concept of abstraction and are defined as a list of abstract > > attributes. > > (2) is close to the OO perspective. The OO paradigm is based upon > problem space abstraction but the paradigm limits how a problem space > 'feature' may be abstracted. All features of problem space entities > must be abstracted as either behavior responsibilities or as knowledge > responsibilities. Thus there is no direct way to represent a notion > like 'purpose'; it must somehow recast as a responsibility for doing > something or knowing something (or both). > > Typically that recasting will be tailored to the problem in hand. Thus > the notion of 'purpose' might be abstracted as a knowledge > responsibility with a value domain of {WIN, SET_PACE, WORK_OUT} for a > Thoroughbred in a claiming race. But when abstracting the notion of > 'purpose' for an Assassin, it might be abstracted as a behavior > responsibility, kill. > > IOW, in the OO paradigm problem space abstraction involves more than > just simplification. > > > ************* > There is nothing wrong with me that could > not be cured by a capful of Drano. > > H. S. Lahman > hsl(a)pathfindermda.com > Pathfinder Solutions > http://www.pathfindermda.com > blog: http://pathfinderpeople.blogs.com/hslahman > "Model-Based Translation: The Next Step in Agile Development". Email > info(a)pathfindermda.com for your copy. > Pathfinder is hiring: > http://www.pathfindermda.com/about_us/careers_pos3.php. > (888)OOA-PATH
From: reju on 7 Dec 2006 00:58 Hi, Thanks to all for the response. But i need little more explanation, as a programmer is i need to care about this absraction? is this coming in the design phase or in later stage? Reju H. S. Lahman wrote: > Responding to Reju... > > > I have a little bit confusion about data abstraction in object oriented > > programming. > > My gut response is: Don't Do That! B-) > > Data is abstracted in OO development, but so much so that it often isn't > data anymore. In the OO paradigm objects are abstracted in terms of > responsibilities. Behavior responsibilities are an object's obligation > to do something. Knowledge responsibilities are an object's obligation > to know something. > > While what an object is obligated to know may be represented as data, > there is no requirement in the OO paradigm that it must be data. Thus > it is fair for something an object is supposed to know to be computed > every time that knowledge is requested. > > So think in terms of /what/ an object needs to know to contribute to the > problem solution and don't worry about how one represents that knowledge > later. > > > I have seen that two perspective of data abstraction, > > > > 1. Data abstraction can be viewed as the process of refining away the > > unimportant details of an object, so that only the useful > > characteristics that define it remain. > > > > 2.Abstraction refers to the act of representing essential features > > without including the background details or explanations. Classes use > > the concept of abstraction and are defined as a list of abstract > > attributes. > > (2) is close to the OO perspective. The OO paradigm is based upon > problem space abstraction but the paradigm limits how a problem space > 'feature' may be abstracted. All features of problem space entities > must be abstracted as either behavior responsibilities or as knowledge > responsibilities. Thus there is no direct way to represent a notion > like 'purpose'; it must somehow recast as a responsibility for doing > something or knowing something (or both). > > Typically that recasting will be tailored to the problem in hand. Thus > the notion of 'purpose' might be abstracted as a knowledge > responsibility with a value domain of {WIN, SET_PACE, WORK_OUT} for a > Thoroughbred in a claiming race. But when abstracting the notion of > 'purpose' for an Assassin, it might be abstracted as a behavior > responsibility, kill. > > IOW, in the OO paradigm problem space abstraction involves more than > just simplification. > > > ************* > There is nothing wrong with me that could > not be cured by a capful of Drano. > > H. S. Lahman > hsl(a)pathfindermda.com > Pathfinder Solutions > http://www.pathfindermda.com > blog: http://pathfinderpeople.blogs.com/hslahman > "Model-Based Translation: The Next Step in Agile Development". Email > info(a)pathfindermda.com for your copy. > Pathfinder is hiring: > http://www.pathfindermda.com/about_us/careers_pos3.php. > (888)OOA-PATH
From: H. S. Lahman on 7 Dec 2006 11:07 Responding to Reju... > But i need little more explanation, as a programmer is i need to care > about this absraction? > is this coming in the design phase or in later stage? Problem space abstraction is largely what OOA/OOD is all about and the topic too complex for USENET forums. I would suggest reading a basic text on OOA/D. (The Books category of my blog has some suggestions for finding such a book.) ************* There is nothing wrong with me that could not be cured by a capful of Drano. H. S. Lahman hsl(a)pathfindermda.com Pathfinder Solutions http://www.pathfindermda.com blog: http://pathfinderpeople.blogs.com/hslahman "Model-Based Translation: The Next Step in Agile Development". Email info(a)pathfindermda.com for your copy. Pathfinder is hiring: http://www.pathfindermda.com/about_us/careers_pos3.php. (888)OOA-PATH
From: Daniel T. on 8 Dec 2006 21:37 Dmitry A. Kazakov wrote: > On Wed, 06 Dec 2006 11:24:09 GMT, Daniel T. wrote: > >> The OO paradigm doesn't care much about data abstraction, >> *behavioral* abstraction is more important. > > Rather data are abstracted as behavior of. Reverse is also true - > data can also serve purpose of abstraction of some behavior. > Consider data sheet, as an example. > > OO is rather a view on both data and behavior as a whole, embodied > in objects. To quote Uncle Bob: Unfortunately, representational modeling is often taken for object-oriented modeling... Representational models are an abstraction of static entities and relationships, devoid of behavior; object-oriented models are abstractions of dynamic behavior devoid of representation.
From: Dmitry A. Kazakov on 9 Dec 2006 05:36 On 8 Dec 2006 18:37:10 -0800, Daniel T. wrote: > Dmitry A. Kazakov wrote: >> On Wed, 06 Dec 2006 11:24:09 GMT, Daniel T. wrote: >> >>> The OO paradigm doesn't care much about data abstraction, >>> *behavioral* abstraction is more important. >> >> Rather data are abstracted as behavior of. Reverse is also true - >> data can also serve purpose of abstraction of some behavior. >> Consider data sheet, as an example. >> >> OO is rather a view on both data and behavior as a whole, embodied >> in objects. > > To quote Uncle Bob: > > Unfortunately, representational modeling is often taken for > object-oriented modeling... Representational models are an > abstraction of static entities and relationships, devoid of > behavior; object-oriented models are abstractions of dynamic > behavior devoid of representation. This is a very good one. However. Look what happens once we've got rid of data. Which, by the way, is a very important step. Also, no data exist. Hooray! But now the behavior itself inevitably starts to form new abstractions which are first perceived as data. The text of a program or an UML diagram are just data. At some stage these abstractions are again considered as a behavior (of behavior). Patterns is a typical example. This is a never ending process. I think that OO and OOPLs try to embrace it more or less successfully. I don't know if this any close to Robert's view, but this is one of the key factors which make me disagree with H.S. He believes that he could stay on the top of this pyramid. I argue that there is no any top. Data and behavior are relative and mutually complementary. In that sense neither exist. This is a platform on which we could talk to the relational camp. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de
First
|
Prev
|
Next
|
Last
Pages: 1 2 3 4 5 Prev: Session Factory Error Next: looking for a predicate hierarchy |