"Pete Dashwood" <dashwood@[EMAIL PROTECTED]
> wrote in message
news:66durcFk6oreU1@[EMAIL PROTECTED]
> OK, I read your response and thought about it.
>
> I can see that it may be impossible for us to communicate on objects
because
> we have different intentions and different world views.
>
> I believe you are sincere and not doing it out of mischief so I'll stay
with
> it for now.
>
> You have stated elsewhere that you don't like the use of the word
"object",
> but that is what is used, and it can have different meanings depending
on
> the context.
>
> I gave some thought to why the use of "object" should be so troublesome
(at
> least for you and me...)
>
> I use "object" in a broader sense than you do (except when I
don't...:-))
> and, as you are not interested in the overall concept I am trying to
express
> (and, I might add it is extremely difficult for me to express something
that
> is a purely conceptual abstraction, despite normally having little
> difficulty expressing my thoughts) you seized on what I wrote and
attacked
> it
> because it doesn't match your definition. It's like you make no attempt
to
> see what I am trying to say, and are more interested in a hair splitting
> argument about it on grounds I have no intention of discussing, let
alone
> defending.
>
> During this discussion I have sometimes used "object" in a much broader
> sense than merely "an instance of a Class".
>
> Peter Coad (Coad/Yourdon) gives some good advice on what he calls
"Object
> think"... and I believe this is the basic fundamental way of looking at
> objects which I absorbed many years ago and still operate upon. For me
now,
> it is "taken as read" and I am usually communicating with others who
> understand this definition also, so no problem arises. On the fairly
rare
> occasions when I am discussing an object as being computer code
representing
> an instance of a class, I believe that is pretty obvious from the
context,
> but it may not be.
>
> Coad views each object as knowing things and knowing how to do things;
> whether you agree with it or not, it will at least help to clarify for
you
> how I see it...
>
> When modelling with objects (or even generally thinking about them) I
tend
> to personalize them, so...
>
> I am a Customer.
> I know my:
> name
> address
> phone number
> date of birth
> I know how to:
> display my details on various devices and media
> update my details
> create a new instance of myself
> cancel my account
> create a new account for myself
> display details of any account I hold
> get a balance of any account I hold
>
> This is a long way from COBOL 68 :-)
>
> You can see that this kind of view is quite distant from the formalism
of
> OOA, OOD, OOP although it can certainly be applied there also.
>
> I think that an article I read back in the early days (around 10 years
> ago...) makes an accurate statement of some of the problems being
> encountered here...
>
> The following is extracted from one small part of it:
>
> "The Problem of Adults Learning New Concepts
>
> Business engineering teams are increasingly turning to object-oriented
> techniques to model business processes. In the future, the business
model
> and the software model will become fused. Both business and computing
> professionals must learn to "object think" in order to gain the
knowledge
> and skills needed for business reengineering. However, since object
> orientation involves a paradigm shift, the principles of adult learning
must
> be carefully applied. One mainframe programmer (quoted from an article
in
> Computerworld March 14, 1994) who made the transition to objects,
described
> the essence of the new way of thinking: "In any kind of procedural
language,
> you are breaking down work flow and coding it. In object-oriented
design,
> you're breaking down events and assigning responsibilities to *OBJECTS*
and
> not really dealing with work flow anymore." Once the new way of thinking
is
> instilled, the syntax, grammar and complexities of object-oriented tools
and
> techniques become manageable to the learner. "
>
> (My emphasis...)
>
> I don't know if any of this helps at all, but this is my best shot at
> explaining what I mean (usually) when I use the term "object".
Some of the difficulties I have with the term "object-oriented"
are addressed in a blog by Chuck Hoffman titled, "conventional
OO syntax considered <strike>harmful</strike> needlessly
misleading", January 9, 2008.
< http://nothinghappens.net/?p=214
>
< http://en.wikipedia.org/wiki/Class-based_programming
>
describes an "object" similar to the way I have understood it
to be, with additions I hadn't thought about at all..
-----
An object is similar to a structure, with the addition of method
pointers, member access control, and an implicit data member
which locates instances of the class (i.e. actual objects of that
class) in the class hierarchy (essential for runtime inheritance
features).
-----
I find no immediate connection between this or other
formal definitions of "object" and the identification of
objects during the earlier phases of analysis and design;
however, these phases together with programming may
be (and in my case are) connected by "class".
At least eight years ago, I made a mental shift from
"object-oriented" to what is now called "class-oriented"
and, once I did that, the benefits and problems of using
object-oriented techniques became clearer.
I have no reason to doubt that "object" was clear in
Dr. Kay's mind when he coined the term "object-oriented";
but that same clarity has eluded me. Even today, "object"
in "object-oriented" seems contrived, rather that natural;
especially in contrast to "procedure" in "procedural".
"Encapsulation-oriented" might be a better term than
"object-oriented".
"Alan Kay is often quoted as having said that, in retrospect,
he would have called it 'message oriented' rather than
'object oriented'." -- < http://nothinghappens.net/?p=214
>
However, I find "class-oriented" to be just fine.
My experience, for more than twenty years, was with a
company that produces both hardware and software.
Embedded systems and stand-alone software are two
places where object-oriented (or class-oriented) is
an excellent fit. This is, therefore, the point of view from
which I studied object-orientation. From this perspective,
the goal was, as I saw it, to create separate, reusable,
application-centric class structures, similar in form to
Microsoft's Foundation Classes and, from those class
structures embedded programs and stand-alone
applications.
Admittedly, this is probably not the best frame of mind
for learning about shape objects, ball objects bouncing,
or velociraptor objects chasing, pouncing on, and eating
prey objects. While I don't know how my transition
occurred, I imagine the mention of object and seeing a
class may have equated the two and led me to think about
class only. Once I made the transition, object became
rather meaningless and I was free to learn what I needed.
|
