""Nathan Nobbe"" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > On 10/6/07, Robert Cummings <[EMAIL PROTECTED]> 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.
It is not PART of the deinition of encapsulation, it is THE definition of encapsulation. making variables (or even methods for that matter) is an optional addition. Data does not HAVE to be hidden to be encapsulated. > 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 repeat, hiding data is optional, not mandatory. > i pointed out that classes that do not utilize ppp allow client code to > become dependent upon their implementation. This is a meaningless statement. ALL classes are dependent on their implementation. The implementation is the code which is executed when a method is called, not the data which is manipulated. > 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. Hiding meber variables may be important to some people, but it is entirely optional, not mandatory. > 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. Hiding variables does not make code less delicate. Just suppose class A calls a method on class B, but some dimwit code monkey removes (or renames) that method? The result is broken code. Making a variable hidden *in itself* does not guarantee unbroken code - that depends entirely on the expertise of your programmers. > 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, So in other words it is important because you have been taught that it is important. I was taught no such thing, therefore I have to disagree. > because ive worked with > a number of languages that dont allow you to create class members without > specifying an access level? The default access level in PHP 4 is "public". The fact that the options "private" and "protected" are not available has absolutely no effect on the resulting code. > 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. PPP (Public/Private/Protected) on its own will not guarantee clean code. That is dependent upon man other factors. > 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? The definition of OOP is "programming which is oriented around objects, thus taking advantage of Encapsulation, Polymorphism, and Inheritance to increase code reuse and decrease code maintenance". It is possible to do this in PHP 4 without all the fancy add-ons which appeared in PHP 5. How do I know? Because I have written an entire framework using objects in PHP 4, and the result is high code reuse and low maintainence. There are no additional OO features in PHP 5 which could deliver any measurable improvements. > any oo php4 'program' is inherently > weak for the reasons i have sighted, namely the implementation can be > latched onto producing tightly coupled code. Coupling is the degree of interaction between two modules. Low levels of coupling tend to create code which is more reusable, whereas high levels of coupling tend to create code which is less reusable. Coupling is therefore directly related to reusability. Making all variables private does not *in itself* make the code more reusable, therefore it does not make the code more "coupled" or less "coupled". > 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. It also includes a lot of those who *think* they know abou OOP. There are numerous dfferent opinions as to what OOP either is or is not, so it is quite easy for a novice to be led up the wrong path. > 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 :) So all your access is via getters and setters? Guess what, there is a school of thought that says these are evil - take a look at http://www.javaworld.com/javaworld/jw-09-2003/jw-0905-toolbox.html > 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. There are no OO features n PHP 5 which will improve on what I have written in PHP 4, so why waste time using them? Just because they are there? That's a very poor argument. > truthfully i still think > there are some features missing; interface hierarchies being the main one, WTF is an "interface hierarchy"? Is this something to do with multiple inheritance? -- Tony Marston http://www.tonymarston.net http://www.radicore.org > perhaps well get lucky in php6... > > -nathan > -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
