|
From: reju on 6 Dec 2006 01:18 Hi, I have a little bit confusion about data abstraction in object oriented programming. 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. can anyone explain about this? Reju
From: S Perryman on 6 Dec 2006 06:07 reju wrote: > I have a little bit confusion about data abstraction in object oriented > programming. 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. > can anyone explain about this? Ignore the term "data" (it is a relic of the 1970s when the CS community were thinking in terms of data types) . Now 1 and 2 are the same thing. Which are both correct. And I would change "abstract attributes" to "abstract properties" . Regards, Steven Perryman
From: Daniel T. on 6 Dec 2006 06:24 "reju" <rejumgeorge(a)gmail.com> wrote: > I have a little bit confusion about data abstraction in object oriented > programming. > 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. > > can anyone explain about this? The OO paradigm doesn't care much about data abstraction, *behavioral* abstraction is more important. -- To send me email, put "sheltie" in the subject.
From: Dmitry A. Kazakov on 6 Dec 2006 08:34 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. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de
From: H. S. Lahman on 6 Dec 2006 14:41
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 |