On 10/9/07, Tony Marston <tony@xxxxxxxxxxxxxxxxxxxxxxxx> wrote: > > 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. no im not confusing anything; local variables are within the scope of the function; therefore they are part of the function implementation. instance variables are part of the scope of a class instance, therefore they are part of its implementation. "Implementation" means the act of changing data, therefore it means the code > and not the data itself. code is nothing w/o data to manipulate; what is an algorithm w/o data to manipulate; it simply would not exist. <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. or better yet; protect the implementation so he wouldnt have to be whipped in the first place. > 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. hmm; the rest of the oop community seems to be flocking to the crap. >>>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. like i said not every system will benefit. > 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. it would be nice if you saw just one example why they are sometimes better than inheritance and therefore useful. >>> 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) but you admit, the php5 construct is better and therefore strengthen my initial argument, which was, if php5 is better and php4 is deprecated; why bother w/ php4. > 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. if you read that one chapter i recommended you will see; acquiring the behavior of the parent is not always desirable. -nathan
