php 5 classes: public, protected and private

Hi,

finally giving php 5 a go, and going over the new approach to classes.
Can someone clarify the public, private and protected to me?

I quote the php manual: "The visibility of a property or method can be
defined by prefixing the declaration with the keywords: public,
protected or private. Public declared items can be accessed
everywhere."

But should I read "...can be accessed everywhere within a given class."
or "...can be accessed by all other classes." ?

Job

jopperdepopper wrote:
> Hi,
>
> finally giving php 5 a go, and going over the new approach to classes.
> Can someone clarify the public, private and protected to me?
>
> I quote the php manual: "The visibility of a property or method can be
> defined by prefixing the declaration with the keywords: public,
> protected or private. Public declared items can be accessed
> everywhere."
>
> But should I read "...can be accessed everywhere within a given class."
> or "...can be accessed by all other classes." ?
>
> Job
>

Job,

You should read "can be accessed everywhere".

Private members can be accessed by members of the class only.
Protected members can be accessed by members of the class or a derived
class.
Public members can be accessed by anyone, including other classes,
functions and any other code.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

>
> You should read "can be accessed everywhere".
>
> Private members can be accessed by members of the class only.
> Protected members can be accessed by members of the class or a derived
> class.
> Public members can be accessed by anyone, including other classes,
> functions and any other code.


Thanks Jerry. I'm trying to make a bit of sense of the php 5 approach
to classes, and so far having a hard time. I fail to see the 'why'
behind the 'public, protected and private' and stuff like abstraction,
interfaces and whatnot. Feels like things are being over-complicated
somehow... or it's just my being inexperienced on this...

Any other reading material on this suggested, someone?

jopperdepopper wrote:
>>You should read "can be accessed everywhere".
>>
>>Private members can be accessed by members of the class only.
>>Protected members can be accessed by members of the class or a derived
>>class.
>>Public members can be accessed by anyone, including other classes,
>>functions and any other code.
>
>
>
> Thanks Jerry. I'm trying to make a bit of sense of the php 5 approach
> to classes, and so far having a hard time. I fail to see the 'why'
> behind the 'public, protected and private' and stuff like abstraction,
> interfaces and whatnot. Feels like things are being over-complicated
> somehow... or it's just my being inexperienced on this...
>
> Any other reading material on this suggested, someone?
>

Look for some good books on OO theory and design.

Two of the concepts in OO are 'encapsulation' and 'methods'.

Encapsulation means the internals of an object are managed only by that
object and are not available to anyone else. In PHP these are private
members.

Methods are implemented as functions in PHP. They operate on the object.

The idea is to completely separate the implementation of the class from
the use of it. It means you can change the class any way you want. As
long as the public interface remains the same, it makes no difference.

A good example of this is floating point numbers. They are stored as a

x * 2^y

X is the mantissa, y is the base 2 exponent. For instance, 8 would be
stored as x=1 and y=3, because 8 is 1 * 2^3. But all of this is hidden
behind the scenes; you can do operations on a floating point number such
as add, subtract, print, etc.

And if at some other time PHP changed the implementation to something
else, none of your code would change.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

> Look for some good books on OO theory and design.
>

Thanks Jerry, maybe the php 5 approach is a better implementation than
the php 4 approach? I have always felt that in php 4 using classes (or
at least my way of using them) was more a convenient way to organise
code, grouping some related functions in one class, other related ones
in another...

Gotta get me some books & hope it's going to be a loooong coooold
winter ;)

jopperdepopper wrote:
>>Look for some good books on OO theory and design.
>>
>
>
> Thanks Jerry, maybe the php 5 approach is a better implementation than
> the php 4 approach? I have always felt that in php 4 using classes (or
> at least my way of using them) was more a convenient way to organise
> code, grouping some related functions in one class, other related ones
> in another...
>
> Gotta get me some books & hope it's going to be a loooong coooold
> winter ;)
>

Yes, I think it is - but then I've been doing OO programming for a
number of years, both in C++ and Java.

Classes are a good way to organize code - but more importantly, they are
a way of organizing code AND DATA. A properly constructed class should,
as much as possible, manage it's own data independent of other classes
and code.

It's a whole different way of thinking which is usually quite a jump for
experienced programmers. In fact, I find newer programmers typically
have less problems, because structured code techniques are not so deeply
ingrained in their mind. :-)

But it's well worth it; the resulting code can be much more readable and
maintainable.

A good example. I needed to implement some pages based on a database.
However, the particular host being used at the time did not have MySQL
available (they claimed they did, but it wasn't very reliable...).

So I implemented the code in flat files using a class for the data being
displayed, and pages to use that class. Later, when they changed to a
host which had MySQL, all I had to do was go back to the class and
change it to read from a database instead of a flat file. No changes to
the pages were needed at all. Very clean and easy to do, because I
segregated the operations on the data in the class, and used the web
page code just to display the data.


--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

"Jerry Stuckle" <jstucklex@attglobal.net> wrote in message
news:Ib6dna_BtYQSifbYnZ2dnUVZ_sSdnZ2d@comcast.com. ..
> jopperdepopper wrote:
>>>You should read "can be accessed everywhere".
>>>
>>>Private members can be accessed by members of the class only.
>>>Protected members can be accessed by members of the class or a derived
>>>class.
>>>Public members can be accessed by anyone, including other classes,
>>>functions and any other code.
>>
>>
>>
>> Thanks Jerry. I'm trying to make a bit of sense of the php 5 approach
>> to classes, and so far having a hard time. I fail to see the 'why'
>> behind the 'public, protected and private' and stuff like abstraction,
>> interfaces and whatnot.

Intefaces are not necessary in PHP. Once you have defined a method it is a
total waste to time to also define an interface. Interfaces are a "fix" in
those languages as a means of dealing with optional arguments and statyic
typing. PHP has ifferent ways of dealing with bth of these, therefore
interfaces serve no useful purpose.

>> Feels like things are being over-complicated
>> somehow... or it's just my being inexperienced on this...
>>
>> Any other reading material on this suggested, someone?
>>
>
> Look for some good books on OO theory and design.
>
> Two of the concepts in OO are 'encapsulation' and 'methods'.
>
> Encapsulation means the internals of an object are managed only by that
> object and are not available to anyone else. In PHP these are private
> members.

Wrong. Encapsulation means that the data and the functions which operate on
that data are contained (encapsulated) within a single object. While the
methods (functions) thenselves may be visible the code behind those methods
(i.e. the implementaton behind those methods) is not. Encapslation is NOT
about hiding information, it is about hiding the implementation. It is not
necessary to use public/private/protected on any methods or properties. It
does not add any functionality, it merely creates restrictions which often
get in the way.

> Methods are implemented as functions in PHP. They operate on the object.

That's one thing you got right.

--
Tony Marston
http://www.tonymarston.net
http://www.radicore.org

..oO(Tony Marston)

>Intefaces are not necessary in PHP. Once you have defined a method it is a
>total waste to time to also define an interface. Interfaces are a "fix" in
>those languages as a means of dealing with optional arguments and statyic
>typing. PHP has ifferent ways of dealing with bth of these, therefore
>interfaces serve no useful purpose.

What's called an interface in PHP is a completely different mechanism
than what you described above.

>Wrong. Encapsulation means that the data and the functions which operate on
>that data are contained (encapsulated) within a single object. While the
>methods (functions) thenselves may be visible the code behind those methods
>(i.e. the implementaton behind those methods) is not. Encapslation is NOT
>about hiding information, it is about hiding the implementation. It is not
>necessary to use public/private/protected on any methods or properties.

Of course it is necessary.

>It
>does not add any functionality, it merely creates restrictions which often
>get in the way.

It prevents developers from doing things that shouldn't be done, for
example calling an internal method out of context. I don't want all my
methods being publicly available, simply in order to avoid errors and
unpredictable results.

Micha

Tony Marston wrote:
> "Jerry Stuckle" <jstucklex@attglobal.net> wrote in message
> news:Ib6dna_BtYQSifbYnZ2dnUVZ_sSdnZ2d@comcast.com. ..
>
>>jopperdepopper wrote:
>>
>>>>You should read "can be accessed everywhere".
>>>>
>>>>Private members can be accessed by members of the class only.
>>>>Protected members can be accessed by members of the class or a derived
>>>>class.
>>>>Public members can be accessed by anyone, including other classes,
>>>>functions and any other code.
>>>
>>>
>>>
>>>Thanks Jerry. I'm trying to make a bit of sense of the php 5 approach
>>>to classes, and so far having a hard time. I fail to see the 'why'
>>>behind the 'public, protected and private' and stuff like abstraction,
>>>interfaces and whatnot.
>
>
> Intefaces are not necessary in PHP. Once you have defined a method it is a
> total waste to time to also define an interface. Interfaces are a "fix" in
> those languages as a means of dealing with optional arguments and statyic
> typing. PHP has ifferent ways of dealing with bth of these, therefore
> interfaces serve no useful purpose.
>

Ah, the great Tony Marston is back to trolling again.

Wrong. In OO terms, the interface is the way to interact with the
object. It consists of all public members - both methods (functions, in
PHP) and variables. And for derived classes, the base class adds
protected members.

A PHP interface is something entirely different.

>
>>>Feels like things are being over-complicated
>>>somehow... or it's just my being inexperienced on this...
>>>
>>>Any other reading material on this suggested, someone?
>>>
>>
>>Look for some good books on OO theory and design.
>>
>>Two of the concepts in OO are 'encapsulation' and 'methods'.
>>
>>Encapsulation means the internals of an object are managed only by that
>>object and are not available to anyone else. In PHP these are private
>>members.
>
>
> Wrong. Encapsulation means that the data and the functions which operate on
> that data are contained (encapsulated) within a single object. While the
> methods (functions) thenselves may be visible the code behind those methods
> (i.e. the implementaton behind those methods) is not. Encapslation is NOT
> about hiding information, it is about hiding the implementation. It is not
> necessary to use public/private/protected on any methods or properties. It
> does not add any functionality, it merely creates restrictions which often
> get in the way.
>

Wrong again, Tony. Encapsulation means internal representations of the
object are not visible outside of the class. Just like the base &
mantissa are not visible outside of a floating point number.

>
>>Methods are implemented as functions in PHP. They operate on the object.
>
>
> That's one thing you got right.
>

More than you got right. Go crawl back into your hole and don't come
out again until you know what you're talking about.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

"Michael Fesser" <netizen@gmx.de> wrote in message
news:fdvmm2hngste2mc3v3q50g23ggkra6u2js@4ax.com...
> .oO(Tony Marston)
>
>>Intefaces are not necessary in PHP. Once you have defined a method it is a
>>total waste to time to also define an interface. Interfaces are a "fix" in
>>those languages as a means of dealing with optional arguments and statyic
>>typing. PHP has ifferent ways of dealing with bth of these, therefore
>>interfaces serve no useful purpose.
>
> What's called an interface in PHP is a completely different mechanism
> than what you described above.

I disagree. It is possible to define a function (method) within a class,
then to define a separate thng called an "interface". It is possible access
he function without using the interface, therefore the inteface is not
necessary.

>>Wrong. Encapsulation means that the data and the functions which operate
>>on
>>that data are contained (encapsulated) within a single object. While the
>>methods (functions) thenselves may be visible the code behind those
>>methods
>>(i.e. the implementaton behind those methods) is not. Encapslation is NOT
>>about hiding information, it is about hiding the implementation. It is not
>>necessary to use public/private/protected on any methods or properties.
>
> Of course it is necessary.

I disagree. it is *not* necessary for the simple reason that the code will
perform exactly the same function whether methods and properties are marked
as public/private/protected or not.

>>It
>>does not add any functionality, it merely creates restrictions which often
>>get in the way.

That is why I said "It does not add any functionality, it merely creates
restrictions"

> It prevents developers from doing things that shouldn't be done, for
> example calling an internal method out of context. I don't want all my
> methods being publicly available, simply in order to avoid errors and
> unpredictable results.

That is a matter for programmer discipline, it is not a matter of additional
functionality. The code will do exactly the same with or without it.

--
Tony Marston
http://www.tonymarston.net
http://www.radicore.org