Re: [PHP] Beginner Tutorials for using CLASSES in PHP4

On 10/9/07, Tony Marston <tony@xxxxxxxxxxxxxxxxxxxxxxxx> wrote:


""Nathan Nobbe"" <quickshiftin@xxxxxxxxx> wrote in message
news:7dd2dc0b0710091106n7f6f6c20i4997cd1fc606ffb4@xxxxxxxxxxxxxxxxx
On 10/9/07, Tony Marston <tony@xxxxxxxxxxxxxxxxxxxxxxxx> wrote:


""Nathan Nobbe"" <quickshiftin@xxxxxxxxx> wrote in message
news:7dd2dc0b0710091015g7c29be93h671aa51bb125198e@xxxxxxxxxxxxxxxxx
On 10/9/07, Robert Cummings <robert@xxxxxxxxxxxxx> wrote:

Why would I use an interface? :)

because inheritance is not always optimal.

I have never found a prolem when using an interface was the only
solution,
or even ANY kind of solution. The fact that your designs need it speaks
volumes of the problems with your designs.

im not the one whose been defending my designs in this conversation;
you
are.

But you are the one who keeps saying that your approach, where all member
variables are hidden, is far superior. I'm just saying that I do share
that
opinion.


fine; lets agree to disagree on that point.

there are plenty of situations where the interface is the more elegant
approach, thats why its here; and thats why it was added in php5.

There's your problem, then. You are wasting your time trying to
implement
fancy design patterns just because design patterns are supposed to be
"cool".

i dont recall reading any suggestions to use design patterns because
they
are cool.

But you are the one who pointed out that interfaces are used in design
patterns, therefore they *must* be OK. I am saying that I have never seen
any advantages from using interfaces, and I don't waste my time with
design
patterns.


no; i stated interfaces offer an alternate mechanism to realize
polymorphism.
i brought design patterns in when i suggested a book that would illustrate
by
example how interfaces can be used and when they are a better choice than
inheritance.

infact the advice ive read is to only use them when they make sense.

My point is that interfaces do not make anysense to me at all. I can
access
all my class methods without them, so what benefit do they give?


if you just read the one chapter im sure they would make sense; they offer
polymorphism w/o the cost of the parent behavior.

Loader class, Controller Base class, Front Controller - I have none
of that crap in my code, so I don't encounter the problems you have.
When
I
see code like "$this->load->library('email') " I just thank my lucky
stars
that I don't have to maintain it. I think some serious refactoring is
long
overdue.

id have to say code igniter is quite a bit more popular than radicore.
maybe youre the one who has some refactoring to do.

Perhaps you are trying to implement something from another language and
expecting PHP to be just like that other language, which is always a
stupid
mistake. PHP is different, therefore the solution will be different. I
suggest you learn how PHP works and design accordingly, and stop trying
to
force it into emulating another language.


well php has certainly gotten its influence from a number of other
languages.
where do you think the additional features in php5 got their inspiration
from?

Some of those features were implemented just because some a*sholes who are
more familiar with other languages keep saying "I can do so-and-so in
language X, and I want to do exactly the same thing in PHP". Language X
has
interfaces, so PHP *must* have interfaces, Why?


youre probly right; if i were to guess id say the interface keyword was
borrowed from
java; im sure .net ripped it off of java too.

What purpose do they serve?


they offer an additional polymorphic mechanism.

What benefits do they bring?


if you havent noticed a class can implement any number of interfaces; it can
only
extend a single class. this means that the same class could potentially be
used
polymorphically in several scenarios.
part of the problem w/ inheritance is you can only put methods in the
superclass that
all the children will absolutely need. otherwise that behavior will be
available in the
child classes and that can be bad news. the bottom line is; if behavior is
changing
across all subclasses; it is not beneficial to have it in the superclass;
but if a method
will say, still be in many of the children it is desirable to still indicate
they are similar;
in comes the interface to save the day.

btw;
heres the definition of implement from dictionary.com

im·ple·ment
<
https://secure.reference.com/premium/login.html?rd=2&u=http%3A%2F%2Fdictionary.reference.com%2Fbrowse%2Fimplementation

/n. '?mpl?m?nt; v. '?mpl??m?nt, -m?nt/ Pronunciation Key - Show Spelled
Pronunciation[n. *im*-pl*uh*-m*uh*nt; v. *im*-pl*uh*-ment, -m*uh*nt]
Pronunciation
Key - Show IPA Pronunciation -noun 1.any article used in some activity,
esp.
an instrument, tool, or utensil: agricultural implements.
notice the use of article; ie data; ie; you are wrong about member
variables
not being part of a classes implementation.
if a variable local to a function can be considered part of its
implementation; then a variable local to a class can be
considered part of its implementation; its that simple.

Implementation is still an activity or a procedure. A lawnmower is a tool
which implements lawnmowing, and it acts upon a lawn. However, the lawn is
not part of the implementation, it is the subject of the implementation.
An
object may contain both variables and operations, but the data is not part
of those operations, it is the subject of those operations.


does a lawn mower not have blades; and gas and a control panel; does it not
have
wheels? my object modeling of a lawn mower would certainly have these
things;
and most likely i would mark components of the engine as private.
and what does a lawn mower cut anyway; grass; i thought that was it. so if
there
was no grass could there still be an algorithm to cut it?
i say grass is part of the grass-cutting algorithm.

-nathan