From: reju on
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
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
"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
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
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