Prev: what's the future of Object Oriented Programming
Next: help me.
From: topmind on 18 Sep 2006 17:38
Phlip wrote:
> Bruno Desthuilliers wrote:
>
> >>>Haven't you read Design Patterns?
>
> >> Yes, I have. But this debate is about advantages and disadvantages of
> >> polymorphism. Not about different design patterns.
>
> > I clearly see how polymorphism can help, but I fail to see what the
> > "disadvantages" of polymorphism could be (unless you count "doesn't solve
> > my actual problem" as a "disadvantage").

I have a list of potential down-falls of polymorphism on my website.
However, I can sum most of them up with one sentence: Polymorphism does
not easily lend it itself to SET THEORY.

I often find it easier to describe an instance or variation on a theme
as sets or a set expression. Polymorphism seems fundimentally against
this. At least it does not naturally help it.

After exploration, you will eventually have to agree that it is better
to model something like an Employee using sets rather than
polymorphism. Polymorphism is simply too limiting. Sure, you can use it
to make strategy patterns etc. that are a kind of set engine, but there
are usually more convenient ways to get the same thing without OO,
especially if you want to query the set info.

>
> I tend to ask "Have you read /Design Patterns/" as short-hand for "Have you
> seen examples of OO techniques being used correctly, to simplify programs?"
>

Like I said elsewhere, the Design Patterns books is geared toward
systems software. It's lessons so far appear not applicable to other
domains, such as custom business software. I do not question OO's
abilities for systems software, but that is not my domain.

-T-

From: Nick Malik [Microsoft] on 24 Sep 2006 22:42
"topmind" <topmind(a)technologist.com> wrote in message
news:1158615511.931176.222270(a)h48g2000cwc.googlegroups.com...
> Phlip wrote:
>>
>> I tend to ask "Have you read /Design Patterns/" as short-hand for "Have
>> you
>> seen examples of OO techniques being used correctly, to simplify
>> programs?"
>>
>
> Like I said elsewhere, the Design Patterns books is geared toward
> systems software. It's lessons so far appear not applicable to other
> domains, such as custom business software. I do not question OO's
> abilities for systems software, but that is not my domain.
>

Well, you've answered my original question. Many if not most of the
examples of design patterns in the DP literature (both the DP book and other
books) use business software examples. Note: I consider systems software to
mean "operating systems" as in device drivers, hardware abstraction layers,
file storage drivers, system navigation and configuration functions, etc.

(before someone jumps on me, being from Microsoft: I consider things like
browsers and media players to be "extra features," like the radio that you
get when you buy a new car... you can get the car without it, but why would
you... And most people are happy with the one that comes with the car. You
haven't seen Bose complain because Toyota includes a Japanese radio
"bundled" in their new cars.)

I do not consider graphics packages, personnel systems, inventory systems,
and the like, to be systems software. Examples of using OO in these cases
abound.

So, the answer you gave is the one I expected: No. You have made no real
attempt to understand that which you criticize.

Look: I've listened to you, and tried to understand your viewpoint. I am a
fair person. On occasion, you make a good point. But most of the time, I
cannot imagine how you are drawing the conclusions you are drawing. I can
only assume you are considering different input than I am... or following
different logic. An understanding of Object Oriented software appears to be
one of the inputs on which our understanding varies. Perhaps our criteria
for a good result varies as well. I don't believe, from your words, that
you understand OO software. Perhaps I am wrong, but I do not believe that
to be the case.

You have every right to be here, and to discuss issues as you do. However,
it is difficult to convince anyone, or even earn a minimum of respect, when
you speak poorly of techniques that you cannot speak well of.

--
--- Nick Malik [Microsoft]
MCSD, CFPS, Certified Scrummaster
http://blogs.msdn.com/nickmalik

Disclaimer: Opinions expressed in this forum are my own, and not
representative of my employer.
I do not answer questions on behalf of my employer. I'm just a
programmer helping programmers.
--


From: topmind on 25 Sep 2006 00:33
Nick Malik [Microsoft] wrote:
> "topmind" <topmind(a)technologist.com> wrote in message
> news:1158615511.931176.222270(a)h48g2000cwc.googlegroups.com...
> > Phlip wrote:
> >>
> >> I tend to ask "Have you read /Design Patterns/" as short-hand for "Have
> >> you
> >> seen examples of OO techniques being used correctly, to simplify
> >> programs?"
> >>
> >
> > Like I said elsewhere, the Design Patterns books is geared toward
> > systems software. It's lessons so far appear not applicable to other
> > domains, such as custom business software. I do not question OO's
> > abilities for systems software, but that is not my domain.
> >
>
> Well, you've answered my original question. Many if not most of the
> examples of design patterns in the DP literature (both the DP book and other
> books) use business software examples. Note: I consider systems software to
> mean "operating systems" as in device drivers, hardware abstraction layers,
> file storage drivers, system navigation and configuration functions, etc.
>

> I do not consider graphics packages, personnel systems, inventory systems,
> and the like, to be systems software. Examples of using OO in these cases
> abound.

Note that I said *custom* business software. This would not include
graphics packages. Most businesses are not going to pay somebody to
build Adobe Photoshop from scratch for their internal stuff (yes, there
are probably rare exceptions.)

If they "abound", where are they?

>
> So, the answer you gave is the one I expected: No. You have made no real
> attempt to understand that which you criticize.

You have not pointed out specifics. Can you name at least 3 GOF
patterns that are shown with custom biz examples *in* the GOF book?

>
> Look: I've listened to you, and tried to understand your viewpoint. I am a
> fair person. On occasion, you make a good point. But most of the time, I
> cannot imagine how you are drawing the conclusions you are drawing. I can
> only assume you are considering different input than I am... or following
> different logic. An understanding of Object Oriented software appears to be
> one of the inputs on which our understanding varies. Perhaps our criteria
> for a good result varies as well. I don't believe, from your words, that
> you understand OO software. Perhaps I am wrong, but I do not believe that
> to be the case.

You have not presented a single public-viewable example of OO being
better at custom biz-ware. I don't want to remenis about what I did in
1999. Why the hell should I? I cannot even spell remenis.

>
> You have every right to be here, and to discuss issues as you do. However,
> it is difficult to convince anyone, or even earn a minimum of respect, when
> you speak poorly of techniques that you cannot speak well of.

Screw words then and show code. Show me OO code being better for custom
biz apps. If you cannot deliver, then we should part ways.

-T-

From: vermeeca on 25 Sep 2006 09:45
You know, the beauty of these newsgroups is that anybody can jump in on
any conversation going on here and say something that's blindingly
obvious to everyone else. I think may be what I'm about to do.

>>> Like I said elsewhere, the Design Patterns books is geared toward
>>> systems software. It's lessons so far appear not applicable to other
>>> domains, such as custom business software. I do not question OO's
>>> abilities for systems software, but that is not my domain.

*snip*

> If they "abound", where are they?

If you're looking for examples of GOF patterns in business software,
have you checked out Craig Larman's book?

http://www.amazon.com/Applying-UML-Patterns-Introduction-Object-Oriented/dp/0130925691

If I remember correctly, he builds up a POS system design from the
ground up in the book using many of the GOF patterns.


topmind wrote:
> Nick Malik [Microsoft] wrote:
> > "topmind" <topmind(a)technologist.com> wrote in message
> > news:1158615511.931176.222270(a)h48g2000cwc.googlegroups.com...
> > > Phlip wrote:
> > >>
> > >> I tend to ask "Have you read /Design Patterns/" as short-hand for "Have
> > >> you
> > >> seen examples of OO techniques being used correctly, to simplify
> > >> programs?"
> > >>
> > >
> > > Like I said elsewhere, the Design Patterns books is geared toward
> > > systems software. It's lessons so far appear not applicable to other
> > > domains, such as custom business software. I do not question OO's
> > > abilities for systems software, but that is not my domain.
> > >
> >
> > Well, you've answered my original question. Many if not most of the
> > examples of design patterns in the DP literature (both the DP book and other
> > books) use business software examples. Note: I consider systems software to
> > mean "operating systems" as in device drivers, hardware abstraction layers,
> > file storage drivers, system navigation and configuration functions, etc.
> >
>
> > I do not consider graphics packages, personnel systems, inventory systems,
> > and the like, to be systems software. Examples of using OO in these cases
> > abound.
>
> Note that I said *custom* business software. This would not include
> graphics packages. Most businesses are not going to pay somebody to
> build Adobe Photoshop from scratch for their internal stuff (yes, there
> are probably rare exceptions.)
>
> If they "abound", where are they?
>
> >
> > So, the answer you gave is the one I expected: No. You have made no real
> > attempt to understand that which you criticize.
>
> You have not pointed out specifics. Can you name at least 3 GOF
> patterns that are shown with custom biz examples *in* the GOF book?
>
> >
> > Look: I've listened to you, and tried to understand your viewpoint. I am a
> > fair person. On occasion, you make a good point. But most of the time, I
> > cannot imagine how you are drawing the conclusions you are drawing. I can
> > only assume you are considering different input than I am... or following
> > different logic. An understanding of Object Oriented software appears to be
> > one of the inputs on which our understanding varies. Perhaps our criteria
> > for a good result varies as well. I don't believe, from your words, that
> > you understand OO software. Perhaps I am wrong, but I do not believe that
> > to be the case.
>
> You have not presented a single public-viewable example of OO being
> better at custom biz-ware. I don't want to remenis about what I did in
> 1999. Why the hell should I? I cannot even spell remenis.
>
> >
> > You have every right to be here, and to discuss issues as you do. However,
> > it is difficult to convince anyone, or even earn a minimum of respect, when
> > you speak poorly of techniques that you cannot speak well of.
>
> Screw words then and show code. Show me OO code being better for custom
> biz apps. If you cannot deliver, then we should part ways.
>
> -T-

From: topmind on 25 Sep 2006 17:06
vermeeca(a)gmail.com wrote:
> You know, the beauty of these newsgroups is that anybody can jump in on
> any conversation going on here and say something that's blindingly
> obvious to everyone else. I think may be what I'm about to do.
>
> >>> Like I said elsewhere, the Design Patterns books is geared toward
> >>> systems software. It's lessons so far appear not applicable to other
> >>> domains, such as custom business software. I do not question OO's
> >>> abilities for systems software, but that is not my domain.
>
> *snip*
>
> > If they "abound", where are they?
>
> If you're looking for examples of GOF patterns in business software,
> have you checked out Craig Larman's book?
>
> http://www.amazon.com/Applying-UML-Patterns-Introduction-Object-Oriented/dp/0130925691
>
> If I remember correctly, he builds up a POS system design from the
> ground up in the book using many of the GOF patterns.

Are you confident that the POS design is better than an equivalent
procedural/relational version of the same thing? Remember, I don't
question that design patterns run and produce the correct output.
Running is not the issue. The issue is whether it is better from a
programmer productivity and/or software *maintenance* point of view.

Thus, before I fork over the money and time for such a book, I shall
request some specifics about what to look for and what to compare and
what kind of metric you are using. Does the author provide the
comparison and metrics? If not, where do I get them from?

I believe these are fair questions.

(I think I browsed that book in the store once and was not very
impressed with it, but can't remember why at the moment.)

-T-

 | 
Pages: 1
Prev: what's the future of Object Oriented Programming
Next: help me.