From: Robert C. Martin on
On 20 Jun 2005 21:58:51 -0700, "topmind" <topmind(a)technologist.com>
wrote:

>Those tend to be the domain of "systems software", an area already
>over-explored with OO. Many of us want to see more business-oriented
>examples rather than writing text editors and device drivers.

There is no predilection towards systems software amongst the design
patterns. They are simply patterns that have recurred in a wide
variety of applications including business, graphics, text
manipulation, etc.



-----
Robert C. Martin (Uncle Bob) | email: unclebob(a)objectmentor.com
Object Mentor Inc. | blog: www.butunclebob.com
The Agile Transition Experts | web: www.objectmentor.com
800-338-6716


"The aim of science is not to open the door to infinite wisdom,
but to set a limit to infinite error."
-- Bertolt Brecht, Life of Galileo
From: Robert C. Martin on
On 20 Jun 2005 09:48:47 -0700, "Juancarlo Aýez" <apalala(a)gmail.com>
wrote:

>Robert, (Bob?)
>
>>Of course they describe the whole things as approaching programming
>>from a different perspective -- and that's a fair comment.
>
>It is *much more* than a "fair comment". It is what it's all about!

Of course. And yet the beginnings were still humble. OO did not
spring fully formed from a flash of divine revelation. It was a
simple progression of happy accidents coupled with great insight. The
result was greater than the sum of it's parts.

This is not a denigration. OO is a wonderful way of thinking about
software. The tools that OO provides are very helpful. However, they
aren't based on a philosophy of "modeling the real world". They are
based on some very simple ideas that have a lot to do with geeks
messing around with code structures.

Some time ago I used to argue with a fellow on this newsgroup who was
convinced that OO was a leftist attitude. That only leftists could
truly understand the beauty and power of OO. Balderdash! I recently
heard the exact same argument about Agile. Someone was claiming that
only leftists could really understand Agile Development. Phooey.

These are SOFTWARE techniques. They are about Software, and not about
the meaning of life. They are important, they are effective, they are
even beautiful in a way that a craftsman can appreciate. But they are
not the solution to world peace.

>If you're defending that OO is a small step from function tables
>implementation-wise, I could not argue that. But what matters is that
>OO (from Simula onwards), whichever the implementation (a dynamic
>language may choose maps instead of vectors) was a huge conceptual step
>respect how we approach problem solving with programming. As big as
>Dijsktra's proving structured programing was complete. As big as
>Hoare's concept of "monitor", which provided a new insight into
>parallel programming (who cares if you need one, two, or three of
>Dijstra's "semaphores" to implementa a monitor?)

I agree with the exception that it was not a single step. It was a
succession of small steps, some accidental, coupled with the insight
of those folks who were making those steps.

>It is all machine code, bits, and transistors in the end, but that is
>not what it's all about.

We must never forget that machine code is, in fact, what it is all
about. We must also never forget that we manipulate that machine code
through an abstract grammar that can be very expressive. Our concern
must be for both. Making beautiful models that don't execute is
worthless.

>For example, portable, compiled-to-byte-code languages is a very old
>idea that has became mainstream only recently, after people found ways
>to implement them efficiently. Byte-code is now much more than a
>convenience: it is a resource that enables designs that one would not
>had risked imagine just a while ago.

Agreed.

>The way we approach software analysis and design today is fundamentally
>different because of the availability of OO.

I agree with respect to design. I don't know what analysis is.



-----
Robert C. Martin (Uncle Bob) | email: unclebob(a)objectmentor.com
Object Mentor Inc. | blog: www.butunclebob.com
The Agile Transition Experts | web: www.objectmentor.com
800-338-6716


"The aim of science is not to open the door to infinite wisdom,
but to set a limit to infinite error."
-- Bertolt Brecht, Life of Galileo
From: Robert C. Martin on
On 20 Jun 2005 10:52:49 -0700, "Isaac Gouy" <igouy(a)yahoo.com> wrote:

>Robert C. Martin wrote:
>> On 20 Jun 2005 02:16:36 -0700, ggroups(a)bigfoot.com wrote:
>>
>> >Of course, the words of the creators of Simula will be of no comfort
>> >to prevaricators who cannot deal with the fact that OO did not appear
>> >from some programmers hacking around with Algol-60 and discovering
>> >things by mistake (a s/w Penicillin in effect) ... ***
>>
>> Steve, there is a difference between accusing someone of being
>> incorrect, and accusing someone of being a liar. The first is
>> civilized, and the second is libelous.
>
>Robert, I was puzzled by your reaction (in English prevaricate is not a
>synonym for lie) - so after checking the OED, I looked in Websters and
>found the definition I expected "to turn aside from, or evade, the
>truth; equivocate" and then a secondary meaning "to tell an untruth".
>
>Maybe something was lost in translation between English and American.

Perhaps. When I saw Prevaricator, I read "liar". I'll leave it to
Steve to clarify.





-----
Robert C. Martin (Uncle Bob) | email: unclebob(a)objectmentor.com
Object Mentor Inc. | blog: www.butunclebob.com
The Agile Transition Experts | web: www.objectmentor.com
800-338-6716


"The aim of science is not to open the door to infinite wisdom,
but to set a limit to infinite error."
-- Bertolt Brecht, Life of Galileo
From: Juancarlo Añez on
Robert,

To be honest, OO for me was originally a small conceptual step from
ADTs (Abstract Data Types) as described by Aho et. al (ISBN
0201000237). OO just made some stuff easier. But today, after Design
Patterns, the formalization of refactoring, and AOP, I think that OO is
much more. It was the quantum conceptual shift that allowed for the
90's revolution in design. OO was the enabler, and C++ the playground
in which we learned how _not_ to do things<s>

As to "analysis" versus "design", I don't want to engage in that
discussion yet again. After years of arguments, for me "analysis" is
everything one does to know the "what", "design" is everything one does
about the "how", and "programming" is "design" from begining to end.

Regards,

Juanco

From: Juancarlo Añez on
Christer,

Thanks for the clarifications. I promise to do my research better next
time<s>

Juanco

First  |  Prev  |  Next  |  Last
Pages: 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65
Next: Use Case Point Estimation