Prev: Proxy pattern: remote chat proxy and interfaces
Next: Derived class calling overriden base class methods
From: topmind on 12 Jan 2008 20:36


Stefan Ram wrote:
> alexcpn <alexcpn(a)gmail.com> writes:
> >question more clearly- what is it so special
> >in OO that makes it so successfully industrially.
>
> Verbs can be extended without the need to modify existing code.
> For example, in Java, a new type can extend the verb �toString�.
> This extension can then be used immediatly by the existing
> �println� verb, without the need that the author of the code
> for �println� was aware of the new type, so it is not
> necessary to modify the given Java SE library, which contains
> other definitions of the verb �toString�. One only needs to
> /add/ new code. Thus, the �open/closed principle� is fulfilled.
>
> A Java program illustrating the answer to the previous question:
>
> class Position
> { int x, y; public java.lang.String toString(){ return x + ", " + y; }}
>
> public class Main
> { public static void main( final java.lang.String[] args )
> { java.lang.System.out.println( new Position() ); }}
>
> 0, 0

How is this better than a subroutine that prints a string? Each app or
usage is going to need a different format anyhow in my experience. A
one-size-formatter-fits-all is a rarity. Plus, I store coordinates in
databases, not RAM-only stuff.

-T-
From: topmind on 12 Jan 2008 20:55


Daniel T. wrote:
> alexcpn <alexcpn(a)gmail.com> wrote:
>
> > Maybe I should frame the question more clearly- what is it so special
> > in OO that makes it so successfully industrially. I really don't
> > 'believe' that it is because of the way OO entity help us in closely
> > modeling real life etc
>
> Here I must disagree. I think OO does help us to more closely model the
> real world.

Note that a good many OO proponents disagree that OO is mostly about
"modeling the real world". Bertrand Meyer, for example, dismisses the
idea that modeling the real world is the key point of OO. Further, the
real world sometimes is not the ideal approach. We wouldn't want to
model a physical card catalog in a library, for example. We have
technology that transcends 3D card cabinets. Why be stuck in the 3D
world when a virtual world (indexing) can have gazillion dimensions?

>
> When I say that, I don't mean in the simple terms expressed in some
> beginner books (the silly "Nouns are classes" approach.) Rather, I mean
> in the way an OO system is structured. Well designed OO systems are less
> centralized than previous approaches.
>
> Some quotes:
>
> What do we find in our day-to-day lives...? We find many machines,
> which interact with each other in a very decentralized fashion. There
> is no central control mechanism... Structured methods are built on
> the idea of centralized control... If decentralization allows the
> real world... to operate, shouldn't we attempt to handle complex
> software problems in the same way? (Riel 1996)
>
> or
>
> Plants consist of three major structures (roots, stems, and leaves),
> and each of these has its own structure... the parts of a plant form
> a hierarchy, and each level of this hierarchy embodies its own
> complexity.
>
> All parts at the same level of abstraction interact in well-defined
> ways....
>
> There are always clear boundaries between the outside and the inside
> of a given level. For example, we can state that the parts of a leaf
> work together to provide the functionality of the leaf as a whole,
> and yet have little or no direct interaction with the elementary
> parts of the roots. In simpler terms, there is a clear separation of
> concerns among the parts at different levels of abstraction. (Booch
> 1994)

Yet to extrapolate this to the business domain has been nearly
impossible. This is because in the real world thing are often
interrelated and this interrelatedness is what gives it its power.
Nested wrapping can only be taken so far and runs out of steam very
quickly as you scale.

Relational theory allows one to provide as-needed relatedness instead
of trying to hard-wire relatedness into code, as OO does. OO is stiff
and static in this regard, unless you like surfing around Christmas-
wire-like pasta messes, Aka "pointer hell".

-T-
From: topmind on 12 Jan 2008 21:14


Stefan Ram wrote:
> topmind <topmind(a)technologist.com> writes:
> >How is this better than a subroutine that prints a string?
>
> I do not claim that �this is better than
> a subroutine that prints a string�.

What was your point in demonstrating it, then? How code is divided
into files and how names are resolved is very language-specific. It is
not really a paradigm-level issue.

OCP can be made to fail any language or design if you look for the
change patterns that tend to kick it. No technique is friendly to all
change patterns. I find the change patterns used with OCP demos in OO
books to be rather artificial.

-T-
oop.ismad.com
From: Daniel T. on 12 Jan 2008 21:43
topmind <topmind(a)technologist.com> wrote:
> Daniel T. wrote:
> > alexcpn <alexcpn(a)gmail.com> wrote:
> >
> > > Maybe I should frame the question more clearly- what is it so special
> > > in OO that makes it so successfully industrially. I really don't
> > > 'believe' that it is because of the way OO entity help us in closely
> > > modeling real life etc
> >
> > Here I must disagree. I think OO does help us to more closely model the
> > real world.
>
> Note that a good many OO proponents disagree that OO is mostly about
> "modeling the real world". Bertrand Meyer, for example, dismisses the
> idea that modeling the real world is the key point of OO. Further, the
> real world sometimes is not the ideal approach. We wouldn't want to
> model a physical card catalog in a library, for example. We have
> technology that transcends 3D card cabinets. Why be stuck in the 3D
> world when a virtual world (indexing) can have gazillion dimensions?

That sort of "modeling the real world" is a fantastic example what I
called "the simple terms expressed in some beginner books."

> > When I say that, I don't mean in the simple terms expressed in some
> > beginner books (the silly "Nouns are classes" approach.) Rather, I mean
> > in the way an OO system is structured. Well designed OO systems are less
> > centralized than previous approaches.
> >
> > Some quotes:
> >
> > What do we find in our day-to-day lives...? We find many machines,
> > which interact with each other in a very decentralized fashion. There
> > is no central control mechanism... Structured methods are built on
> > the idea of centralized control... If decentralization allows the
> > real world... to operate, shouldn't we attempt to handle complex
> > software problems in the same way? (Riel 1996)
> >
> > or
> >
> > Plants consist of three major structures (roots, stems, and leaves),
> > and each of these has its own structure... the parts of a plant form
> > a hierarchy, and each level of this hierarchy embodies its own
> > complexity.
> >
> > All parts at the same level of abstraction interact in well-defined
> > ways....
> >
> > There are always clear boundaries between the outside and the inside
> > of a given level. For example, we can state that the parts of a leaf
> > work together to provide the functionality of the leaf as a whole,
> > and yet have little or no direct interaction with the elementary
> > parts of the roots. In simpler terms, there is a clear separation of
> > concerns among the parts at different levels of abstraction. (Booch
> > 1994)
>
> Yet to extrapolate this to the business domain has been nearly
> impossible. This is because in the real world thing are often
> interrelated and this interrelatedness is what gives it its power.
> Nested wrapping can only be taken so far and runs out of steam very
> quickly as you scale.

Life proves you wrong. Nested levels of abstraction scales very well
indeed. I agree that OO isn't for all domains. I'll take your word for
it that the kind of business apps you write are one of them. If all you
are doing is selecting and presenting information, then OO is probably
way more than you need.
From: topmind on 12 Jan 2008 22:29


Daniel T. wrote:
> topmind <topmind(a)technologist.com> wrote:
> > Daniel T. wrote:
> > > alexcpn <alexcpn(a)gmail.com> wrote:
> > >
> > > > Maybe I should frame the question more clearly- what is it so special
> > > > in OO that makes it so successfully industrially. I really don't
> > > > 'believe' that it is because of the way OO entity help us in closely
> > > > modeling real life etc
> > >
> > > Here I must disagree. I think OO does help us to more closely model the
> > > real world.
> >
> > Note that a good many OO proponents disagree that OO is mostly about
> > "modeling the real world". Bertrand Meyer, for example, dismisses the
> > idea that modeling the real world is the key point of OO. Further, the
> > real world sometimes is not the ideal approach. We wouldn't want to
> > model a physical card catalog in a library, for example. We have
> > technology that transcends 3D card cabinets. Why be stuck in the 3D
> > world when a virtual world (indexing) can have gazillion dimensions?
>
> That sort of "modeling the real world" is a fantastic example what I
> called "the simple terms expressed in some beginner books."

Everybody claims the *other* guy's view of OO is over-simplistic. The
field needs science so that we can avoid dark-age-like anecdote
battles.

>
> > > When I say that, I don't mean in the simple terms expressed in some
> > > beginner books (the silly "Nouns are classes" approach.) Rather, I mean
> > > in the way an OO system is structured. Well designed OO systems are less
> > > centralized than previous approaches.
> > >
> > > Some quotes:
> > >
> > > What do we find in our day-to-day lives...? We find many machines,
> > > which interact with each other in a very decentralized fashion. There
> > > is no central control mechanism... Structured methods are built on
> > > the idea of centralized control... If decentralization allows the
> > > real world... to operate, shouldn't we attempt to handle complex
> > > software problems in the same way? (Riel 1996)
> > >
> > > or
> > >
> > > Plants consist of three major structures (roots, stems, and leaves),
> > > and each of these has its own structure... the parts of a plant form
> > > a hierarchy, and each level of this hierarchy embodies its own
> > > complexity.
> > >
> > > All parts at the same level of abstraction interact in well-defined
> > > ways....
> > >
> > > There are always clear boundaries between the outside and the inside
> > > of a given level. For example, we can state that the parts of a leaf
> > > work together to provide the functionality of the leaf as a whole,
> > > and yet have little or no direct interaction with the elementary
> > > parts of the roots. In simpler terms, there is a clear separation of
> > > concerns among the parts at different levels of abstraction. (Booch
> > > 1994)
> >
> > Yet to extrapolate this to the business domain has been nearly
> > impossible. This is because in the real world thing are often
> > interrelated and this interrelatedness is what gives it its power.
> > Nested wrapping can only be taken so far and runs out of steam very
> > quickly as you scale.
>
> Life proves you wrong.
> Nested levels of abstraction scales very well
> indeed. I agree that OO isn't for all domains. I'll take your word for
> it that the kind of business apps you write are one of them. If all you
> are doing is selecting and presenting information, then OO is probably
> way more than you need.

This implies that biz apps are simple. If they were truly simple,
they'd be abstracted away by domain-specific languages/libraries. (to
some extent they are, but there's a lot that resists cookie-cutter pre-
packaging.)

-T-
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14
Prev: Proxy pattern: remote chat proxy and interfaces
Next: Derived class calling overriden base class methods