""Nathan Nobbe"" <quickshiftin@xxxxxxxxx> wrote in message news:7dd2dc0b0710090628k25b44c1dydd5342c81af3fddb@xxxxxxxxxxxxxxxxx > 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. 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 Not everybody in this universe agree with your opinion, so stop insisting that your opinion is the only one that counts. <snip> >> 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. You are confusing member variables with local variables. Member variables are part of the object's data which need to be made available to the outside world. Local variables are internal to the function, and do not need to be made available to the outside world. Local variables are part of the implementation, member varables are not. "Implementation" means the act of changing data, therefore it means the code and not the data itself. <snip> > 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. Then surely if a programmer fucks things up in such a fashion it would become apparent during unit testing? Then the culprit can be soundly whipped until he lears NOT to fuck up. > that is a violation of encapsulation, I disagree.Encapsulation is the act of placing the data, and the operations which act upon that data, in the same object. A violation of encapsulation is therefore to put the data and its operations in more than one object. Encapsulation has absolutely nothing to do with how those objects are used (or abused). > 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. I am sticking to the fundamentals and deliberately ignoring all the crap which has been added on by everybody and his dog. >>>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. If it is not obvious in the way that interfaces can provide benefits then they are useless as far as I am concerned. I have never seen ANY documentation which shows ANY benefits from using interfaces, so I simply do not see the point in using them. > as i said they offer an additional polymorphic mechanism > one that php4 doesnt supply. I can achieve all the polymorphism I need WITHOUT using interfaces, so I do not see the point in using them. > 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. I refuse to read any more books on design patterns. In my opinion they are abused, over-used and over-rated. Just because one or two design patterns use interfaces does not mean that interfaces are the best thing since sliced bread. >>> 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. This still does not get away from the fact hat it is still possible to create an absract class in PHP 4 without having to use the keyword "abstract" in the class definition. The PHP 5 implementation may be superior, but it is still possible in PHP 4 (if you are a competent programmer, that is) > btw, interface hierarchies are like class hierarchies; one interface can > extend another. So what? One class can extend another. The "extends" keyword does not rely on interfaces. -- 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
