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

On Sat, 2007-10-06 at 22:20 -0700, Nathan Nobbe wrote:
On 10/6/07, Robert Cummings <robert@xxxxxxxxxxxxx> wrote:


Tony is right here. Encapsulation is about hiding the details of the
implementation


rob, here is tonys definition of encapsulation:
Encapsulation is the act of placing data and the
operations that perform on that data in the same class. The data does not
have to be private at all.
tony did not at any point say that encapsulation is about hiding
implementation details.
im the one who indicated encapsulation is about hiding implementation
details.

Yes but you also said it is about data hiding. That is not true. They
are related, but data hiding is not a requirement of encapsulation.

tonys definition is contrary to all the definitions i have pulled from books
on object oriented programming (see last post).
actually, its not contrary, but it is only part of the definition.

encapsulation is infact about hiding implementation details; its about
driving client code through a well defined interface, to get access to the
behavior the class supplies.
in order to implement this behavior there are often times variables *and*
methods that client code should not have access to.

Sure, but those variables don't need to be hidden. In fact, if the
purpose of the variable will never change then there's no need to hide
it. And if later down the road you must... refactor.

i pointed out that classes that do not utilize ppp allow client code to
become dependent upon their implementation. because weve only been
stressing the hiding of member variables (i guess thats what data hiding
means) in this conversation i think we have glossed over the fact that it is
also important to be able to hide certain member functions as well.

this cannot be done in php4, and as i said can lead to systems where client
code is made dependent upon the implementation of other classes, which leads
to very delicate systems.

This CAN be done in PHP4. It is common convention to precede your
variable with an underscore or more if it is intended to be private.
Either way, nothing replaces good documentation. A short comment by the
variable that says "PRIVATE" is usually sufficient to get the point
across. If someone then uses outside the class, well tough luck.

you guys are not the only php4 advocates ive run into;

Don't confuse my stance on PHP4 and PHP5 as being an explicit advocate
of PHP4 over PHP5. PHP5 and beyond is where things are going and my code
is already ready. But I do not believe in blatantly throwing away
compatibility for the convenience of syntactic sugar.

it just so happens i
have a good friend with a very strong php background who tells me
practically the same thing, ppp isnt that big of a deal.

It isn't.

i disagree, why,
is it because ive had a classical education in oop

What the heck is a classical education in OOP? Are you saying your old
and therefore smarter? Young and therefor smarter? WTF?

, because ive worked with
a number of languages that dont allow you to create class members without
specifying an access level?

Many of us have done this. Your point?

for those reasons and because ive had the
misfortune of working in places that have tightly coupled code. im talking
about hundreds of thousands of lines of madness. ppp could have saved these
systems greatly.

Once again, just because someone writes bad programs doesn't make PPP
the superior choice. A shitty programmer faced with PPP will more than
likely declare all of their member variables as public and as such will
have gained nothing.

Also, don't forget that abstraction, encapsulation, and information
hiding all have a price

if youre referring to performance i think the price of not using these tools
is also worth mention. namely code which is easily subject to tight
coupling, which as i said leads to systems that are difficult to maintain
and extend.
personally i value maintainability and extensibility over performance, but
thats merely a personal preference.

Tell that to an embedded systems programmer.

(tony)
I strongly disagree. It *IS* possible to write perfectly adequate OO
programs
using PHP 4. If you cannot then you have been taught some bad habits.

Hear hear.

and what exactly does adequate mean? any oo php4 'program' is inherently
weak for the reasons i have sighted, namely the implementation can be

I'm sur eyou meant "cited" above.

latched onto producing tightly coupled code.
dont worry tony, i can construe some pretty decent php4 code myself; i wrote
a date time package that ive ported to 3 projects including a conversion to
php5 in one of those. the point is that the other developers i work with
dont have a clue about object oriented concepts which in my experience
constitutes the vast majority of php developers. the even bigger point, on
the topic of this thread is that php4 is out the door, so there is yet
another possibly more important reason not to waste time learning oop
studying php4.

Once again, if you suck at programming you suck at programming. Those
sucky programmers are probably going to declare all their member vars
public, aren't going to understand encapsulation, probably will have
terrible class hierarchies, etc. You can't make a good programmer by
holding their hand.

ive studied oop for years and worked with a number of oop languages; many of
the bad habits i had at one point or another have been removed. guess what
the first one was, not letting client code access member variables directly
:)

I've worked with many languages too. I found my code getting better
while using C. I learned to properly prefix function names, collect them
together in the same file, use structures instead of 20 parameter
functions, etc. Lessons are learned wherever you spend your time.

if you dont mind brittle oop code, php4 will suffice. if you want to tap
into real object oriented features, many of which i consider fundamental
(such as ppp [to name just one]) go for php5. truthfully i still think
there are some features missing; interface hierarchies being the main one,
perhaps well get lucky in php6...

Nothing brittle at all about PHP4 code. I can completely screw up any
PHP5 code you send my way too.

Cheers,
Rob.
--
............................................................
SwarmBuy.com - http://www.swarmbuy.com

Leveraging the buying power of the masses!
............................................................
.

Quantcast