NYCPHP Meetup

[Tim Gales]

 Chris Snyder writes: 
> The example was simplistic of course.
> 
> Let's say football::kickBall() is a complex method that needs 
> to be updated every time some external API changes (welcome 
> to the world of .NET, right?).

Well, the I in API stands for Interface. 
It doesn't matter if the method underneath is simple 
or complex (hopefully the complexity/simplicity of how things 
get done is hidden).

If the API you are using keeps changing, perhaps its time 
to shop around for a better thought-out framework.

Does the .NET API really change that often -- 
I don't really keep close tabs on what's happening 
with it. But Microsoft developers in the past have 
avoided changes to the MFC API like the plague -- 
if for no other reason than to avoid admitting that 
the framework wasn't too well thought-out -- so I 
would assume the NET developers would follow suit 
and avoid changes to the NET API unless things get 
pretty drastic.

(As an interesting footnote concerning the 
the 'though-out-ed-ness' of the NET API, many 
developers laugh at the fact that the C# spelling 
of 'Icloneable' is uncomfortably close to the spelling 
of the Java interface 'Cloneable', which probably 
should be spelled 'Clonable' -- somebody may have 
copied JINI's (instead of Jimmy's) homework)

> 
> You have fifteeen diverse classes that you want to add 
> kickBall() functionality to.
> 
> Unless you want to copy-and-paste through fifteen source 
> files every time the damn football API changes, you have to 
> jump through some kind of hoop:
> 
> 1) you refactor all of your classes to extend the football class
> 2) you implement football::kickBall() as a static method
> 3) you use classkit_method_copy()
> 

Couldn't you just require a file which implements the 
interface function (in this case 'kickball')? That way no 
matter how many classes depend on it, they would all get
the latest and the greatest.

T. Gales & Associates
'Helping People Connect with Technology'

http://www.tgaconnect.com