""Nathan Nobbe"" <quickshiftin@xxxxxxxxx> wrote in message news:7dd2dc0b0710030811g43d5f4e8ka0d6c14633794412@xxxxxxxxxxxxxxxxx > keeping data private is how encapsulation in facilitated. Absolute rubbish. 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. > here is a really simple way to violate encapsulation in php4 > > class BreakMe { > // private > var $iWishIWasPrivate; > } > > // later on > > $instance = new BreakMe(); > > $instance->iWishIWasPrivate = 'encapsulation violated'; > > if the member variable was supposed to be private well we have just > violated > encapsulation. Encapsulation is NOT data hiding. > further more when you migrate to php5 you will find many > headaches > as you mark the would-be private variable in php4 private in php5. My code has to run using both PHP 4 and PHP 5, so I don't waste my time marking any variables as private or protected. > the proper technique is to drive all access to member variables in php4 > through member functions. That is *A* technique, but not the only technique. > the problem that arises is anybody can simply go and violate the > encapsulation > as i have demonstrated w/o any warning. I repeat, encapsulation has absolutely nothing to do with data hiding. > the only way to discover this is > through reading > the code, which in a large environment is a lengthy time consuming > process. > > i never said interfaces needed to be used to facilitate polymorphism. i > just said they supply an additional means of polymorphism, I do not need an interface to access a method, therefore interfaces are redundant. > its actually more powerful than inheritance alone because > a class can implement any number of interfaces, not just one parent class. A class can implement any number of methods, and I do not need interfaces to access those mehods, so interfaces are redundant. > also, interfaces > dont require that the behavior be carried over, which is one of the > problems > w/ overusing > inheritance; it isnt always the case that behavior should be propagated. Then don't overuse inheritance. > admittedly your abstract class mechanism is somewhat similar to what the > keyword supplies in > php5, but i beg the question; why clutter up userspace and contrive > techniques that the language > supplies in php5. Because I originally wrote my code using PHP 4, and the same code has to run in both PHP 4 and PHP 5. > php4 is outdated; that is the point. But is is still widely used. There are a lot of hosting companies who have yet to upgrade to PHP 5, so the need for PHP 4 is still there. > for someone trying to learn oop, i > maintain that doing so using php4 > is a waste of time. That is just your opinion. I beg to differ. > that would be like learning java4 even though java6 is > in use, its just silly. But if a lot of servers refused to upgrade from java 4 it would be pointless using code that only worked in java 6.. -- Tony Marston http://www.tonymarston.net http://www.radicore.org > -nathan > > On 10/3/07, Tony Marston <tony@xxxxxxxxxxxxxxxxxxxxxxxx> wrote: >> >> >> ""Nathan Nobbe"" <quickshiftin@xxxxxxxxx> wrote in message >> news:7dd2dc0b0710030636w5dc967f9yfeb9bf768724d43e@xxxxxxxxxxxxxxxxx >> > there is no way to create an abstract class in php4. >> >> Oh yes there is! I knw, because I have done it! The definition of an >> abstrract class is one that cannot be instantiated into an object. It >> can, >> however, be extended into a subclass, and that subclass can be >> instantiated >> into an object. >> >> Although in PHP 5 this can be achieved by using the "abstract" keyword in >> the class definition, in PHP 4 you can achieve exactly the same result by >> defining a method in the abstract class which contains code which forces >> an >> error, but when redefined in the subclass this code is replaced so that >> it >> does not cause an error. >> >> The end result is the same, but the mechanism is different. >> >> > in an abstract class definition subclasses are forced to implement >> > those >> > methods >> > that have been declared abstract. or they are allowed to declare the >> > method >> > as abstract themselves and force their children to provide a concrete >> > definition. >> > the only way to achieve this in php4 is to have an essentially empty >> > definition in a >> >> Not an empty definition, but one that contains code which triggers an >> error. >> >> > class and through external documentation or communication w/ other >> > developers, >> > indicate the function need be overridden to be usable. >> > communicating externally, something that could be communicated inside >> the >> > language >> > itself is very delicate, one that would not do well in a scenario with >> > a >> > large >> > number of developers. >> > >> > interfaces introduce the concept of design-by-contract. they are very >> > powerful because >> > they give code another avenue to be polymorphic. >> >> You DO NOT need interfaces to activate a class method. >> >> You DO NOT need interfaces to utilise polymorphism. >> >> > inheritance is often >> > overused because >> > people dont understand the power of composition and the benefit of >> > interfaces to facilitate >> > composition. >> >> Just because SOME people overuse inheritance does not mean that EVERYBODY >> overuses inheritance. My class structure is only two levels deep - an >> abstract superclass with any number of concrete subclasses underneath it. >> >> > for people coming to php4 from languages like java, or even .net; >> anything >> > that >> > implements proper access control mechanisms, abstract classes and >> > interfaces; those >> > people may be able to design systems w/ php4 that are properly >> structured. >> >> You do not need access contol mechanisms or interfaces to write properly >> structured code. >> >> > starting out w/ >> > php4 and trying to learn oop will likely lead individuals into bad >> > practices >> > that they cannot foresee >> > until years down the road, when their systems are growing at a slow >> > rate >> > and >> > they have to >> > figure out why or somebody who understands oop comes in and explains >> where >> > the problems are. >> > >> > the most common mistake i encounter with oop php4 is accessing class >> > member >> > functions directly. >> > this is a complete violation of encapsulation and php4 provides no way >> to >> > enforce it. >> >> Absolute rubbish. Keeping data private has nothing to do with >> encapsulation. >> >> > yes, php4 does provide some of the fundamental oop facilities and its >> all >> > the community had for a while. >> > the bottom line is the facilities it offers for oop are bare and i see >> no >> > reason to try to understand its >> > peculiarities and weaknesses when php5 is here and php6 is on the way. >> >> Rubbish. PHP 4's implementation of OO supports classes, objects, >> encapsulation, inheritance and polymorphism. That is more than enough for >> a >> competent programmer. Everything else is eye candy. >> >> -- >> Tony Marston >> http://www.tonymarston.net >> http://www.radicore.org >> >> > -nathan >> > >> > On 10/2/07, Tony Marston <tony@xxxxxxxxxxxxxxxxxxxxxxxx> wrote: >> >> >> >> >> >> ""Nathan Nobbe"" <quickshiftin@xxxxxxxxx> wrote in message >> >> news:7dd2dc0b0709292018q6a5aa7d1w1c422628ca00ae7d@xxxxxxxxxxxxxxxxx >> >> > although some people believe differently than i; i would argue >> >> > trying to learn how to design w/ the classes that php4 provides >> >> > is a waste of time. >> >> >> >> I disagree. PHP 4 gives you access to classes, encapsulation, >> inheriance >> >> and >> >> polymorphism. This is all you need for OO programming. All that extra >> >> crap >> >> in PHP 5 is just window dressing. >> >> >> >> > most books you will find regarding object oriented >> >> > design assume the language has the basic constructs. ppp mainly. >> >> > also, there are other important facilities php4 lacks like abstract >> >> > classes >> >> >> >> You can write abstact classses in PHP 4, it's just that you can't use >> the >> >> word "abstract". Interfaces are totally irrelevant as any method can >> >> be >> >> accessed directly through its function definition. >> >> >> >> > and interfaces, not to mention you have to explicitly assign objects >> by >> >> > reference in php4. (if you dont want a copy created). >> >> > unless you are bound to php4 by work or something >> >> > i suggest you start working w/ php5. also, if your looking for some >> >> > design >> >> > techniques i recommend studying design patterns. >> >> >> >> Design patterns are overrated. For building transactions in CRUD >> >> applications you need transaction patterns. >> >> >> >> -- >> >> Tony Marston >> >> http://www.tonymarston.net >> >> http://www.radicore.org >> >> >> >> > the heads first book >> >> > is a great starting point. >> >> > actually if you want a solid reference thats free on the web look at >> >> > phpPatterns <http://www.phppatterns.com/docs/start> >> >> > the code is mostly php4 i believe. >> >> > >> >> > -nathan >> >> > >> >> > >> >> > On 9/29/07, Jeff Cohan <jdcohan@xxxxxxxxxxxxx> wrote: >> >> >> >> >> >> Yes, I know how to Google, and I've been Googling... >> >> >> >> >> >> But I would appreciate advice about good beginner tutorials using >> >> >> classes in PHP4 based on your actual experiences. I.e., have some >> >> >> of >> >> >> you found tutorials that really unlocked the doors for you? >> >> >> >> >> >> Ideally, such tutorials would have somewhat realistic examples. (I >> >> >> already know how to output "Hello, World" using a class, and I tend >> >> >> to find examples like those unhelpful. Maybe it's just me.) >> >> >> >> >> >> My main challenge is modularizing yer basic BREAD/CRUD operations >> >> >> with MySQL databases. >> >> >> >> >> >> I've made some strides in creating increasingly modular functions >> >> >> to >> >> >> present browse lists, edit forms and add forms; to perform >> >> >> field-level and form-level validations; and to perform inserts, >> >> >> updates and deletes. My approach is to utilize multidimensional >> >> >> arrays which define the column names, column labels (for forms), >> >> >> form control types (input, select, checkbox, etc.) and other >> >> >> attributes of the form controls. I've got a "library" of validation >> >> >> routines with error messages that appear on the form under the >> >> >> culprit form control. >> >> >> >> >> >> But I think taking the next step to use classes is going to make my >> >> >> life much easier. >> >> >> >> >> >> TIA for any guidance you might be able to offer. >> >> >> >> >> >> Jeff >> >> >> >> >> >> -- >> >> >> PHP General Mailing List (http://www.php.net/) >> >> >> To unsubscribe, visit: http://www.php.net/unsub.php >> >> >> >> >> >> >> >> > >> >> >> >> -- >> >> PHP General Mailing List (http://www.php.net/) >> >> To unsubscribe, visit: http://www.php.net/unsub.php >> >> >> >> >> > >> >> -- >> PHP General Mailing List (http://www.php.net/) >> To unsubscribe, visit: http://www.php.net/unsub.php >> >> > -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
