[Tutor] impact of OO

[Erik Price]

On Sunday, April 7, 2002, at 07:13  PM, alan.gauld@bt.com wrote:

> Exactly so.
> The point being that you can take a bunch of objects (shapes
> in this case) and treat them generically, relying on each
> object to 'know' how to respond to the messages. In practice
> we do that by coding each object class with its own version
> of the operation and leave the language to figure out which
> one is needed. (This is *much* harder to do in statically
> typed languagesc like Javaand C++ BTW)

Is it achieved in the way you describe toward the bottom of the email?  
(By using multiple methods of the same name, but each takes a different 
'type'?  Because if so, this only seems like more work, and not *much* 
harder, but then having never done anything like that, what do I know -- 
I hope to find out at some point!)

>> abiding by a certain convention in naming class methods.
>
> Just so, in fact this has its own name in OO circles its
> called defining the "common protocol" of the objects.
>
> [ Getting more esoteric still its related to a bit of
>   Computer Science called the Liskoff Substitution Principle
>   which describes how to define abstract data types such
>   that they appear identical to the basic data type from
>   which they are descended. It is actually stricter than
>   normal OO inheritance/polymorphism rules. But if you are
>   interested there are some fairly heavy papers on the web
>   to read ]

Interested, but already hundreds of pages behind in books to read -- and 
this sounds like something that can wait :)  I seem to do best when I 
take it one step at a time... it took me a few months to get to the 
point where I can ask these questions about OOP.

> One thing you an't do in Python but can in some languages
> is override the same method name within the same class,
> like this:
>
> class C:
>    def F(self, anInt): ...
>    def F(self, aString): C.F(self,int(aString))
>    def F(self, aList):map(lambda n: C.F(self,int(n)),aList)
>    def F(self, intA,intB,intC): C.F(self,intA+intB+intC)
>
> This won't work min Python because its dynamically typed
> so they all look the same to the interpreter. But in C++
> its how you have the same method name but can pass different
> typed arguments (and different numbers of arguments) to it.

The above is the snip that I am referring to at the beginning of this 
email -- is this the way that statically-typed languages get around 
being unable to flexibly pass different types to different methods?

>> subclass its own, different, method name.
>
> But then you can't put your new object type in a list and expect
> the old list handling code to use your new class. It would
> have to be modified to call the new method name - baaaaad...

I think I have lost focus of the thread and am not sure what I should 
watch out for here -- :(   .


I am trying to use Object Oriented techniques in my PHP code for my work 
project.  Most of the work revolves around accessing and inserting and 
updating data in a database -- it is a web-based application and that is 
what most web applications do.  I have defined a class "recipient", 
which contains methods which accept user input, check the input via 
regexes for dangerous input, and then if it passes the error check then 
the input is stored as an attribute of the object.  There could be any 
number of "Recipient" objects being processed at any given time, so it 
seems perfect.  But I will really have to think of a clever way to take 
advantage of polymorphism, so that I do not waste time writing extra 
code -- because in addition to "Recipients" there will be "Senders", 
etc, and the fields will not necessarily all be identical.  So, what 
should I do in this case, where I care about a Recipient's name, 
address, and phone number, but for Senders I have a name and a FedEx 
code number?  It doesn't seem that the two different classes line up as 
well as the "Shapes" example -- FedEx code doesn't line up well with 
Address or Phone number.  Is this not a case where I should try to use 
polymorphism?  The reason I have assumed that I could is because in the 
end, all data is going to be inserted into a database, which is really 
the same thing -- just different table/field names, depending.  But it 
seems that these details could be worked into the class, whereas the 
method names could be "generic-ized" -- I just can't think of a good 
scheme.



Erik