""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 -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
