Prev: Session Factory Error
Next: looking for a predicate hierarchy
From: topmind on 10 Dec 2006 16:11
Dmitry A. Kazakov wrote:
> 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.


On c2.com I've been involved in many debates related to this. Most seem
to agree that they are interchangable views of the same thing. The
issue thus becomes which is "better" for software engineering.

I argue that there are more "maths" for data-oriented viewpoints (such
as relational) and thus it is easier to abstract on a large scale.
Large-scale behavioral abstractions currently lack discipline, and this
is one reason why I don't like OOP. GOF patterns are an attempt, but
they are ugly, inconsistent, and don't make it clear when to use one
over the other.

The biggest problem is OOP has not figured out how to manage
*relationships* between behaviors in a well-defined way.

>
> --
> Regards,
> Dmitry A. Kazakov
> http://www.dmitry-kazakov.de

-T-
oop.ismad.com

From: topmind on 10 Dec 2006 16:14

H. S. Lahman wrote:
> 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.


That is because it is poorly defined and inconsistent, not because it
is some grand productive rocket science that will save software
engineering if you simply rent the right properly-educated OOD
consultants for $70/hour.


> 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

-T-

From: Daniel Parker on 11 Dec 2006 19:55

Dmitry A. Kazakov wrote:
> On 8 Dec 2006 18:37:10 -0800, Daniel T. wrote:
>
> > 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.
>
In the context of enterprise integration, it seems to me that the trend
is towards standardization on the representation of data, and away from
the idea of distributed objects (aka CORBA, DCOM, RMI, etc.) So date
is represented as the text value "2006-10-10T12:00:00-05:00" (noon on
10 October 2006, Central Daylight Savings Time) as opposed to a date
ADT (with getYear(), getMonth() etc.) Every industry from life
insurance to publishing seems to be participating in consortiums for
standardizing on a representation of data that fits their business
context. Communication is through the transfer of documents containing
data adhering to standards. One big reason is decoupling; from a
document centric approach, no matter how many code decoupling
strategies Robert Martin comes up with, the result is still tightly
coupled, it is in the nature of code. (I'm not exactly sure what
"behaviour" means, I haven't seen the term used in formal treatments of
ADTs, but I think it has something to do with code.)

Regards,
Daniel Parker
http://servingxml.sourceforge.net/

From: S Perryman on 12 Dec 2006 04:19
Daniel Parker wrote:

> Dmitry A. Kazakov wrote:

>>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.

> In the context of enterprise integration, it seems to me that the trend
> is towards standardization on the representation of data, and away from
> the idea of distributed objects (aka CORBA, DCOM, RMI, etc.) So date
> is represented as the text value "2006-10-10T12:00:00-05:00" (noon on
> 10 October 2006, Central Daylight Savings Time) as opposed to a date
> ADT (with getYear(), getMonth() etc.)

You seem to be confused here.

The representation of information for the purposes of information
*exchange* is a different issue to the representation of information for
*system development* . The latter is what ADTs deal with (manipulation
of information without knowledge of its underlying representation) .


> I'm not exactly sure what
> "behaviour" means, I haven't seen the term used in formal treatments of
> ADTs, but I think it has something to do with code.)

Behaviour is observable changes/settings of the properties of an ADT.
Usually expressed using artifacts such as pre/post/invariant conditions.

Think of a stack.
The behaviour of the push op is observed by an increase in size of the
stack, a specific value produced by the top op, and the stack that
existed before invoking the push op is a sequence suffix of the stack
that exists after the invocation.


Regards,
Steven Perryman
From: Dmitry A. Kazakov on 12 Dec 2006 06:36
On 11 Dec 2006 16:55:51 -0800, Daniel Parker wrote:

> Dmitry A. Kazakov wrote:
>> On 8 Dec 2006 18:37:10 -0800, Daniel T. wrote:
>>
>>> 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.
>>
> In the context of enterprise integration, it seems to me that the trend
> is towards standardization on the representation of data, and away from
> the idea of distributed objects (aka CORBA, DCOM, RMI, etc.) So date
> is represented as the text value "2006-10-10T12:00:00-05:00" (noon on
> 10 October 2006, Central Daylight Savings Time) as opposed to a date
> ADT (with getYear(), getMonth() etc.)

As Steven has pointed out these are not equivalent. We have to decide
whether data represented by a text value show a behavior of a date or text.
Consider T1 - T2, what is the result? Does < compare dates or texts? Can I
add "1" to the text and get the date of 1 second later?

> Every industry from life
> insurance to publishing seems to be participating in consortiums for
> standardizing on a representation of data that fits their business
> context.

This is an obvious and easy step ... in a totally wrong direction. One
could agree on a representation format of something which behavior is
known. For this you have to define the behavior. How could we do that? What
is the behavior of date? Has it day savings? Is it monotonic? Is it
astronomical time. Would it work on the moon? etc. Even for simple things
like floating point number it is very difficult to define the behavior of.
What about any more complex stuff? The point is, you need a language (not
necessarily a programming one) to describe the behavior. You cannot come
out with some implied behavior. Text is not a language. Should we do
natural text processing, or what? Even if we managed it perfectly, an A.I.
from UK could ask, damn it, is 12:00 in the text above PM or AM?

People are doing things you are describing, just because they don't want to
think any further, and because any kind of more precise definition is not
in the economical and political interests of the parties involved. The
least common denominator is what we get.

> Communication is through the transfer of documents containing
> data adhering to standards. One big reason is decoupling; from a
> document centric approach, no matter how many code decoupling
> strategies Robert Martin comes up with, the result is still tightly
> coupled, it is in the nature of code. (I'm not exactly sure what
> "behaviour" means, I haven't seen the term used in formal treatments of
> ADTs, but I think it has something to do with code.)

I see your point. But the decoupling you are talking about were achieved
through making everything static. All and everybody should agree on an
implied, not stated, behaviour of dates. You cannot communicate things you
didn't agree in advance. This is an utopia. It has no future, because it
imposes a much tighter coupling on the whole software developing
infrastructure, including people. You lifted a local coupling and moved it
to the global scope, probably beyond mere software developing. Yuck.

--
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