On 10/6/07, Tony Marston <tony@xxxxxxxxxxxxxxxxxxxxxxxx> wrote: > > Encapsulation and information hiding are separate topics. It is possible > to > have one without the other. see the revision of my php4 critique. > 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. when variables store data needed to realize the outcome of some method; they become part of the implementation and therefore should not be exposed to client code. > 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. it is also about client code not being able to view and manipulate the implementation. if client code can access data that the implementation (as you define it [not consisting of data]) uses, or relys upon, then the outcome of the implementation can be altered by client code. that is a violation of encapsulation, which is precisely why data is part of the implementation, and it needs to be concealed from client code to maintain the integrity of the implementation. 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. youre missing out on like the last decade or so of oop. > 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. not every system will benefit from interfaces. it sounds like you dont fully understand the use of them; and i wont say its immediately obvious. as i said they offer an additional polymorphic mechanism one that php4 doesnt supply. if you want a great example of how they are used and when extension is not desirable (because the behavior is passed along) read the first chapter of heads first design patterns. > 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. actually, im trying to illustrate bad habits so they may be avoided by other developers. That is just your opinion. My opinion is totally different. thats why i gave an alternate critique based upon your definition of encapsulation. also, i should mention its occurred to me that the abstract class mechanism in php5 is superior to your mechanism in php4. if a method marked as abstract in php5 is not overridden by client code, an error is raised at compile time, and the class is not allowed to be utilized. btw, interface hierarchies are like class hierarchies; one interface can extend another. -nathan
