On 10/6/07, Robert Cummings <robert@xxxxxxxxxxxxx> wrote: > > Tony is right here. Encapsulation is about hiding the details of the > implementation rob, here is tonys definition of encapsulation: Encapsulation is the act of placing data and the operations that perform on that data in the same class. The data does not have to be private at all. tony did not at any point say that encapsulation is about hiding implementation details. im the one who indicated encapsulation is about hiding implementation details. tonys definition is contrary to all the definitions i have pulled from books on object oriented programming (see last post). actually, its not contrary, but it is only part of the definition. encapsulation is infact about hiding implementation details; its about driving client code through a well defined interface, to get access to the behavior the class supplies. in order to implement this behavior there are often times variables *and* methods that client code should not have access to. i pointed out that classes that do not utilize ppp allow client code to become dependent upon their implementation. because weve only been stressing the hiding of member variables (i guess thats what data hiding means) in this conversation i think we have glossed over the fact that it is also important to be able to hide certain member functions as well. this cannot be done in php4, and as i said can lead to systems where client code is made dependent upon the implementation of other classes, which leads to very delicate systems. you guys are not the only php4 advocates ive run into; it just so happens i have a good friend with a very strong php background who tells me practically the same thing, ppp isnt that big of a deal. i disagree, why, is it because ive had a classical education in oop, because ive worked with a number of languages that dont allow you to create class members without specifying an access level? for those reasons and because ive had the misfortune of working in places that have tightly coupled code. im talking about hundreds of thousands of lines of madness. ppp could have saved these systems greatly. Also, don't forget that abstraction, encapsulation, and information > hiding all have a price. > if youre referring to performance i think the price of not using these tools is also worth mention. namely code which is easily subject to tight coupling, which as i said leads to systems that are difficult to maintain and extend. personally i value maintainability and extensibility over performance, but thats merely a personal preference. (tony) > I strongly disagree. It *IS* possible to write perfectly adequate OO programs > using PHP 4. If you cannot then you have been taught some bad habits. and what exactly does adequate mean? any oo php4 'program' is inherently weak for the reasons i have sighted, namely the implementation can be latched onto producing tightly coupled code. dont worry tony, i can construe some pretty decent php4 code myself; i wrote a date time package that ive ported to 3 projects including a conversion to php5 in one of those. the point is that the other developers i work with dont have a clue about object oriented concepts which in my experience constitutes the vast majority of php developers. the even bigger point, on the topic of this thread is that php4 is out the door, so there is yet another possibly more important reason not to waste time learning oop studying php4. ive studied oop for years and worked with a number of oop languages; many of the bad habits i had at one point or another have been removed. guess what the first one was, not letting client code access member variables directly :) if you dont mind brittle oop code, php4 will suffice. if you want to tap into real object oriented features, many of which i consider fundamental (such as ppp [to name just one]) go for php5. truthfully i still think there are some features missing; interface hierarchies being the main one, perhaps well get lucky in php6... -nathan
