Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > Searching a motivating example for upcasts

Reply
Thread Tools

Searching a motivating example for upcasts

 
 
Jim Janney
Guest
Posts: n/a
 
      12-21-2010
markspace <(E-Mail Removed)> writes:

> On 12/19/2010 8:26 AM, Stefan Ram wrote:
>
>> Thanks for all the answers! But I have not yet heard an
>> example that to me seems to be adapted better than the one I
>> usually use:
>>
>> In the Federal Republic of Germany, there are cars with
>> a manual gearbox and cars with an automatic gearbox.

>
>
> Thinking about this a bit, I don't like your example. I learned OOD
> on my own, because OOD didn't really become popular until after I had
> graduated.
>
> One thing I had to overcome was the over abundance of examples based
> on cars and other real world object (but especially cars). Objects in
> OOD don't always correspond to real objects or even other user
> requirements. Many objects are not objects per se, they are concepts.
> The objects encapsulate some notion of design or functionality that
> the designer needed to simplify his or her project, and are not really
> "objects" in the way that the natural language understands that term.


This mirrors my own experience as a self-taught OO programmer. As it
happens, the first project I attempted in an OO language (C++) was a
program that communicated with an ATM. I wasted a lot of time trying to
write classes to model the physical parts of the ATM -- card reader,
cash dispenser, printer, etc. -- and getting nowhere. Eventually I
figured out that what I was really dealing with was more abstract
concepts like messages, protocols, sessions, and state machines. I
started writing classes to model those instead, and then things started
falling into place. But the examples in the books I'd read were not
helpful; if anything they actively led me astray.

--
Jim Janney
 
Reply With Quote
 
 
 
 
Esmond Pitt
Guest
Posts: n/a
 
      12-21-2010
On 20/12/2010 5:58 AM, markspace wrote:
> One thing I had to overcome was the over abundance of examples based on
> cars and other real world object (but especially cars). Objects in OOD
> don't always correspond to real objects or even other user requirements.


I would go further. I would say they practically never correspond to
real-world objects. Real-world objects like customers, suppliers,
employees, managers etc are generally modelled as flat collections of
attributes, bearing in mind that customers can also be suppliers,
employees can become managers, etc. OO is used primarily to express
*programming* concepts like collections, connections, projections,
injections, ... Even in an OO/hierarchical thing like LDAP the accepted
wisdom is *not* to mirror your organizational structure in the LDAP
treee, despite the fact that that is exactly what it was originally
designed to do.
 
Reply With Quote
 
 
 
 
Arne Vajhøj
Guest
Posts: n/a
 
      12-22-2010
On 20-12-2010 00:43, Peter Duniho wrote:
> On 12/19/10 12:18 PM, Arne Vajhøj wrote:
>> [...]
>>> InputStream stream = new FileInputStream("foo");
>>>
>>> This helps document in the code that, while the object is in fact a
>>> FileInputStream, the code is intended only to use the functionality
>>> available in InputStream.

>>
>> I don't think that example is relevant.
>>
>> I would expect Stefan to be perfectly aware of that type
>> of code.
>>
>> It is very basic OOP.
>>
>> The example he gave had an explicit upcast.

>
> That does not mean that an explicit upcast is really what he's trying to
> teach.
>
> Fact is, an explicit upcast is required only for overload resolution,
> which is not something he mentioned at all, and which is not really an
> OOP concept at all. It doesn't seem likely to be relevant to a
> programming class such as what Stefan may be teaching.
>
> Of course, he is free to clarify. But it's not your place to discount
> replies based on _your_ ASSumptions about what he might or might not
> have meant.


Hm. You don't want me to discount your answer based on my assumptions.
But you think it is fine for you to call Chris Uppals answer for
"close-minded statement" base on your assumptions????

Arne
 
Reply With Quote
 
Arne Vajhøj
Guest
Posts: n/a
 
      12-22-2010
On 21-12-2010 21:33, Peter Duniho wrote:
> On 12/21/10 5:14 PM, Arne Vajhøj wrote:
>> Hm. You don't want me to discount your answer based on my assumptions.
>> But you think it is fine for you to call Chris Uppals answer for
>> "close-minded statement" base on your assumptions????

>
> They aren't assumptions. They are facts. His statement was trivial to
> demonstrate as false.


Well - he did public state that your interpretation of
his reply was not what he was trying to communicate.

So how do you know that your interpretation was correct
and his later explanation was wrong?

Mind reading??

Arne




 
Reply With Quote
 
Lew
Guest
Posts: n/a
 
      12-23-2010
Chris Uppal wrote:
> There seems to be a fairly large segment of the community of OO pundits who
> regard the word "modelling" as a mistake.


Because it's misspelled?

Unless your program entity is the thing itself, it's a model of the thing, and
since no program manipulates actual domain entities but coded representations
of those entities, modeling the domain in a program is inevitable and ineluctable.

> On the whole, I agree. Where OO brings /me/ benefit is that I can create
> whatever abstractions I need to handle my target domain /without/ thereby being
> forced to work at an unnatural distance from anything I can treat as "real".
>
> I can create objects, and use the parts of my mind which are adapted to


You can create /models/ of domain objects using code objects.

> thinking about physical "things", and especially to thinking about /people/, to
> understand them. But the advantage comes precisely because the abstractions
> the object represent are /not/ actual, physical, things. I.e. I can extend the
> reach of my biologically hard-wired expertise in "people& things" into the
> domain of abstractions (in general), and the target domain (in particular).
>
> No models involved. Everthing is real in its own right.


Nothing but models involved. Nothing in your code is the real thing.

--
Lew
Ceci n'est pas une pipe.
 
Reply With Quote
 
Tom McGlynn
Guest
Posts: n/a
 
      12-23-2010
On Dec 22, 7:26*pm, Lew <(E-Mail Removed)> wrote:
> Chris Uppal wrote:
> > There seems to be a fairly large segment of the community of OO pundits who
> > regard the word "modelling" as a mistake.

>
> Because it's misspelled?
>

Not at all. 'Modelling' is a perfectly acceptable spelling, perhaps
the preferred version outside the US. The US dictionaries give
'modeling' as the normal spelling with double-l acceptable but marked
as a UK variant. The British dictionaries make that the standard with
the single-l version marked as a mostly US variation. You shouldn't be
so parochial.

Regards,
Tom McGlynn
 
Reply With Quote
 
Mike Schilling
Guest
Posts: n/a
 
      12-23-2010


"Tom McGlynn" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> On Dec 22, 7:26 pm, Lew <(E-Mail Removed)> wrote:
>> Chris Uppal wrote:
>> > There seems to be a fairly large segment of the community of OO pundits
>> > who
>> > regard the word "modelling" as a mistake.

>>
>> Because it's misspelled?
>>

> Not at all. 'Modelling' is a perfectly acceptable spelling, perhaps
> the preferred version outside the US. The US dictionaries give
> 'modeling' as the normal spelling with double-l acceptable but marked
> as a UK variant. The British dictionaries make that the standard with
> the single-l version marked as a mostly US variation. You shouldn't be
> so parochial.


Or even "parochiall".

 
Reply With Quote
 
Lew
Guest
Posts: n/a
 
      12-23-2010
On 12/22/2010 10:20 PM, Mike Schilling wrote:
>
>
> "Tom McGlynn" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
>> On Dec 22, 7:26 pm, Lew <(E-Mail Removed)> wrote:
>>> Chris Uppal wrote:
>>> > There seems to be a fairly large segment of the community of OO pundits >
>>> who
>>> > regard the word "modelling" as a mistake.
>>>
>>> Because it's misspelled?
>>>

>> Not at all. 'Modelling' is a perfectly acceptable spelling, perhaps
>> the preferred version outside the US. The US dictionaries give
>> 'modeling' as the normal spelling with double-l acceptable but marked
>> as a UK variant. The British dictionaries make that the standard with
>> the single-l version marked as a mostly US variation. You shouldn't be
>> so parochial.


You shouldn't be such a namby-pamby.

> Or even "parochiall".


I can't help it. I went to parochial school.

I should have said, "Because it was mispieled?"

Y'all don't do dry very well, do you? Too bad for you. Not only did you
comPLETEly miss out on the joke, you comPLETEly ignored the serious part of my
post, didn't you?

Again, too bad for you.

--
Lew
Ceci n'est pas une pipe.
 
Reply With Quote
 
Tom Anderson
Guest
Posts: n/a
 
      12-23-2010
On Wed, 22 Dec 2010, Lew wrote:

> Chris Uppal wrote:
>> There seems to be a fairly large segment of the community of OO pundits who
>> regard the word "modelling" as a mistake.

>
> Because it's misspelled?
>
> Unless your program entity is the thing itself, it's a model of the thing,
> and since no program manipulates actual domain entities but coded
> representations of those entities, modeling the domain in a program is
> inevitable and ineluctable.
>
>> On the whole, I agree. Where OO brings /me/ benefit is that I can
>> create whatever abstractions I need to handle my target domain
>> /without/ thereby being forced to work at an unnatural distance from
>> anything I can treat as "real".
>>
>> I can create objects, and use the parts of my mind which are adapted to

>
> You can create /models/ of domain objects using code objects.
>
>> thinking about physical "things", and especially to thinking about
>> /people/, to understand them. But the advantage comes precisely
>> because the abstractions the object represent are /not/ actual,
>> physical, things. I.e. I can extend the reach of my biologically
>> hard-wired expertise in "people& things" into the domain of
>> abstractions (in general), and the target domain (in particular).
>>
>> No models involved. Everthing is real in its own right.

>
> Nothing but models involved. Nothing in your code is the real thing.


I suspect that this is a matter of semantics. The point is that the
classes are not attempting to be little pictures of some real-world
entities like Managers, Trucks, Card Readers, etc. Whether you still
consider them models or not is, i think, not very interesting.

I lean towards siding with Chris, in that i believe there can be code
which is not a model. For instance, the last code i worked on before the
christmas holiday was reading messages out of a database, parsing them,
and sending the information in them to various consumers. The whole
business centres around the information in the messages; that information
does not exist anywhere outside my software (not once it's been read and
deleted from the database, anyway). If my message objects are models, what
are they models of?

tom

--
In-jokes for out-casts
 
Reply With Quote
 
Lew
Guest
Posts: n/a
 
      12-23-2010
On 12/23/2010 04:42 PM, Tom Anderson wrote:
> On Wed, 22 Dec 2010, Lew wrote:
>
>> Chris Uppal wrote:
>>> There seems to be a fairly large segment of the community of OO pundits who
>>> regard the word "modelling" as a mistake.

>>
>> Because it's misspelled?
>>
>> Unless your program entity is the thing itself, it's a model of the thing,
>> and since no program manipulates actual domain entities but coded
>> representations of those entities, modeling the domain in a program is
>> inevitable and ineluctable.
>>
>>> On the whole, I agree. Where OO brings /me/ benefit is that I can create
>>> whatever abstractions I need to handle my target domain /without/ thereby
>>> being forced to work at an unnatural distance from anything I can treat as
>>> "real".
>>>
>>> I can create objects, and use the parts of my mind which are adapted to

>>
>> You can create /models/ of domain objects using code objects.
>>
>>> thinking about physical "things", and especially to thinking about
>>> /people/, to understand them. But the advantage comes precisely because the
>>> abstractions the object represent are /not/ actual, physical, things. I.e.
>>> I can extend the reach of my biologically hard-wired expertise in "people&
>>> things" into the domain of abstractions (in general), and the target domain
>>> (in particular).
>>>
>>> No models involved. Everthing is real in its own right.

>>
>> Nothing but models involved. Nothing in your code is the real thing.


Tom Anderson wrote:
> I suspect that this is a matter of semantics.


You say that as if it dismisses the point. It does not.

Since "semantics" means "meaning", it's rather important. If you don't mean
"modeling" when you say "modeling", that's rather significant.

Why do people say "matter of semantics" or "only semantics" as if semantics
were trivial? They're actually at the very core of successfully modeling your
problem or process in your code.

> The point is that the classes
> are not attempting to be little pictures of some real-world entities like
> Managers, Trucks, Card Readers, etc. Whether you still consider them models or
> not is, i think, not very interesting.


It may not be interesting to you, but as a response when someone says, "code
has no modeling in it" and "pundits think 'modeling' is a mistake", it's
directly to the point.

> I lean towards siding with Chris, in that i believe there can be code which is
> not a model. For instance, the last code i worked on before the christmas
> holiday was reading messages out of a database, parsing them, and sending the
> information in them to various consumers. The whole business centres around
> the information in the messages; that information does not exist anywhere
> outside my software (not once it's been read and deleted from the database,
> anyway). If my message objects are models, what are they models of?


Your messages are models of thoughts to be communicated. To put it another
way, your messages are electronic models of words. If you could use carrier
pigeons to carry the messages as quickly and with the same throughput, it
would work just as well. It's not the messages themselves that count, it's
the information they convey. The messages model the information in a way that
can be transmitted through your system.

It's models and only models. People who assert that "modeling" is a mistake
are way off base.

--
Lew
Ceci n'est pas une pipe.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Google search result to be URL-limited when searching site, but notwhen searching Web stumblng.tumblr Javascript 1 02-04-2008 09:01 AM
Motivating high-school students to join college after completing high school m1@mailinator.com Computer Support 4 08-13-2007 04:00 AM
Searching for a working example of a curses application that resizes in xterm schwerdy@web.de Python 4 09-20-2005 06:35 AM
On motivating a Ruby nubie Sy Ruby 23 04-22-2005 05:59 PM
Searching Example-Code for J2ME - creating Random Integers via java.util.Random() Elmar Baumann Java 0 02-02-2004 08:32 PM



Advertisments