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


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


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

Encapsulation is NOT data hiding. Take a look at


please stop putting words into my mouth. i never once said
encapsulation
is
data hiding.
I stated PublicPrivateProctected facilitates encapsulation.

The dictionary definition of "facilitate" is to make easier or better.
Data
and methods are either contained within the same capsule or they are not.
There are no intermediate levels of encapsulation. Data hiding has
absolutely no effect on encapsulation. Hiding data does not make
encapsulation better, and not hiding data does not make encapsulation
worse.

Encapsulation and data hidng are NOT connected in any way. You can have
encapsulation without data hiding, and you can have data hiding without
encapsulation.



i will now be strengthening my previous statements and issuing the new
statement;
information hiding is an integral part of encapsulation.

Encapsulation and information hiding are separate topics. It is possible to
have one without the other.

here are excerpts from 4
books, 2 on java, one on c++, and one on php:

This abstraction works only if we are careful to respect its boundaries.
An
object should be self-governing, which means
that the variables contained in an object should be modified only within
the
object. Only the methods within an object should
have access to the variables in that object.

The principle of encapsulation has no such rule! Encapsulation is merely the
act of placing variables and the methods which act upon those variables in
the same object. It is not necessary to hide any variables.

Encapsulation is NOT data hiding. Take a look at

http://www.javaworld.com/javaworld/jw-05-2001/jw-0518-encapsulation.html
http://www.itmweb.com/essay550.htm
http://c2.com/cgi/wiki?EncapsulationIsNotInformationHiding

For example, the methods of
the Coin class should be solely responsible for changing
the value of the face variable. We should make it difficult, if not
impossible, for code outside of a class to "reach in" and change the
value of a variable that is declared inside the class.
Page 220. - 221
Java Software Solutions foundations of program design 3rd edition Lewis &
Loftus
The specification of what a function does and how it is invoked defines
its
interface. By hiding a module implementation, or encapsulating
the module, we can make changes to it without changing the main function,
as
long as the interface remains the same. For example, you
might rewrite the body of a function using a more efficient algorithm.
Encpasulation: Hiding a module implementation in a separate block with a
formally specified interface.

The implementation is the CODE behind the method, not the DATA that the code
manipulates. Encapsulation is IMPLEMENTATION hiding, not DATA hiding.

Page 354
Programming and Problem Solving with C++ Second Edition
Nell Dale, Chip Weems, Mark Headington

OOP revolves around the concept of grouping code and data together in
logical units called classes. This process is usually referred to as
encapsulation,

Correct.

or information hiding,

INCORRECT

since its goal is that of dividing an
application into separate entities whose internal components can
change without altering their external interfaces.

No. The idea behind encapsulation is that the implementation, the code
behind a method, can change at any time without the outside world being
aware of it. Data is *NOT* the implemetation.

Page 113.
Zend PHP5 Certification Study Guide
Davey Shafik

Access control is often referred to as implementation hiding.

But wrongly! Access control is NOT implementation hiding, it is a totally
separate issue.

Wrapping data
and methods within classes in combination with implementation
hiding is often called encapsulation4*

That is correct. But only the implementation (the code behnd each method) is
hidden, not the data.

The result is a data type with
characteristics and behaviors.
* However, people often refer to implementation hiding alone as
encapsulation.
Page 231
Thinking in Java Third Edition
Bruce Eckel

tonight when i get home ill post
a snippet from an entry level oop book (such that i recommend earlier)
that
says almost
verbatim what i have.

practically any non-trivial class will have member variables that it
uses
in
order to facilitate
its member functions.

So what? Those variables do not have to be private or protected in order
to
function.


They dont have to be marked private or protected to function, but in order
to prevent
client code from latching onto the implementation details of the class;
they
need to be
hidden.

Wrong! DATA does not define the implementation, it is the CODE which
manipulates that data which defines the implementation. The idea of
encapsulation is that you can change the code within any method at will
without the outside world being aware of it.

many of those variables have nothing to do w/ the
functionality the
class exposes to client code. if those variables are modified
directly,
because they cant be
protected by ppp, then the functionality of the class can be distorted.
that is why ppp exists.

PPP exists to place restrictions on stupid programmers. It does not add
an
functionality, or make the code run faster.


Run faster, who said anything about that? Given that ive shown examples
from 4
books, some with multiple authors, we can either assume there are a lot of
stupid
programmers out there or your opinion is the less popular of the 2.

Encapsulation is NOT data hiding. Take a look at

http://www.javaworld.com/javaworld/jw-05-2001/jw-0518-encapsulation.html
http://www.itmweb.com/essay550.htm
http://c2.com/cgi/wiki?EncapsulationIsNotInformationHiding


what you dont seem to understand is the important of stressing the
distinction
between specification and implementation. maybe youve had the benefit of
working
with other developers that arent infact stupid; and they know not to
access
class
member variables directly; but the point is that is a very delicate
system.
stupid,
or more likely uneducated developers will go in and latch onto class
implementation
details which leads to tight coupling, which makes systems a massive pain
to
extend
and maintain.

lets be fair though; youve defined encapsulation as grouping variables and
methods,
and defined data-hiding as a separate concept, fair enough. my criticism
of
php4,
based upon those definitions can be revised to,
php4 is inferior, because although it provides encapsulation, it does not
provide data-hiding
capabilities. this can lead to very fragile object oriented systems
unless
developers rely
heavily on external documentation, communication and agree to strictly
avoid
accessing
class member variables directly.
the language also lacks many other powerful object oriented facilities.

if a class has variables client code doesnt need to know about to do its

job, then client code
by no means should have access to it.
interfaces are a powerful mechanism. its a shame youre turning your
back
on
them.

Using interfaces does not give me access to any functionality that I do
not
have by accessing methods directly, so why waste time in using them?


given that you dont understand the fundamental concepts of oop;

The fundamental concepts of OOP consist of nothing more than encapsulation,
inheritance and polymorphism. Data hiding, interfaces and all that other
fancy stuff are irrelevant.

im not going to take the
time to try and explain the power of the interface construct. imho, you
have a long way to
go before you can grasp the power of the mechanism.

I have never seen any gain from using interfaces in PHP, only pain,
therefore I refuse to use them. Yet what functinality I am losing? None
whatsoever.

in summary, i still maintain, based upon the contents of this post and the
many previous posts
that sitting down and trying to learn oop with php4 is a waste of time.

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

at the very least php5
could still be used by marking everything public, which just illustrates
how
silly the lack of
data-hiding really is.

That is just your opinion. My opinion is totally different.

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

Quantcast