On Sat, 2007-10-06 at 22:20 -0700, Nathan Nobbe wrote: > 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.
Yes but you also said it is about data hiding. That is not true. They are related, but data hiding is not a requirement of encapsulation. > 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. Sure, but those variables don't need to be hidden. In fact, if the purpose of the variable will never change then there's no need to hide it. And if later down the road you must... refactor. > 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. This CAN be done in PHP4. It is common convention to precede your variable with an underscore or more if it is intended to be private. Either way, nothing replaces good documentation. A short comment by the variable that says "PRIVATE" is usually sufficient to get the point across. If someone then uses outside the class, well tough luck. > you guys are not the only php4 advocates ive run into; Don't confuse my stance on PHP4 and PHP5 as being an explicit advocate of PHP4 over PHP5. PHP5 and beyond is where things are going and my code is already ready. But I do not believe in blatantly throwing away compatibility for the convenience of syntactic sugar. > 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. It isn't. > i disagree, why, > is it because ive had a classical education in oop What the heck is a classical education in OOP? Are you saying your old and therefore smarter? Young and therefor smarter? WTF? > , because ive worked with > a number of languages that dont allow you to create class members without > specifying an access level? Many of us have done this. Your point? > 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. Once again, just because someone writes bad programs doesn't make PPP the superior choice. A shitty programmer faced with PPP will more than likely declare all of their member variables as public and as such will have gained nothing. > 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. Tell that to an embedded systems programmer. > (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. Hear hear. > and what exactly does adequate mean? any oo php4 'program' is inherently > weak for the reasons i have sighted, namely the implementation can be I'm sur eyou meant "cited" above. > 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. Once again, if you suck at programming you suck at programming. Those sucky programmers are probably going to declare all their member vars public, aren't going to understand encapsulation, probably will have terrible class hierarchies, etc. You can't make a good programmer by holding their hand. > 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 > :) I've worked with many languages too. I found my code getting better while using C. I learned to properly prefix function names, collect them together in the same file, use structures instead of 20 parameter functions, etc. Lessons are learned wherever you spend your time. > 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... Nothing brittle at all about PHP4 code. I can completely screw up any PHP5 code you send my way too. Cheers, Rob. -- ........................................................... SwarmBuy.com - http://www.swarmbuy.com Leveraging the buying power of the masses! ........................................................... -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
