On 10/7/07, Robert Cummings <robert@xxxxxxxxxxxxx> wrote: > > On Sun, 2007-10-07 at 11:42 +0100, Tony Marston wrote: > > > > 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. not all systems will stand to gain from the features in php5. but ppp is a very important feature; i would say any code that is not using ppp could stand to benefit from it. the interface construct is in my opinion the biggest enhancement to the php5 oop feature set, as it offers a new avenue for polymorphic code. > > > > 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". all i said is that it prevents client code from becoming dependent upon implementation details, which doesnt reduce reusability, but does make the code difficult to change because at that point the client code needs to be changed as well. Well, Nathan is assuming that if you have a public member that you > probably didn't provide get/set wrappers for it. As such directly using > the member variable does indeed increase the couple of your code to that > module because if the variable needs to change in some way it's not > possible to change the behaviour across the board without updating all > uses of the member variable. > > However, just because it's public doesn't mean it doesn't have a get/set > wrapper and doesn't mean it should be used directly. Yes, using a > private declaration enforces use of the get/set wrapper, but once again, > documentation can make this point also and as such marking a member > variable as private is just syntactic sugar. > > Strangely enough though, PHP5 provides the means to NOT provide get/set > methods and still modify the behaviour of direct access to a member > variable via the magic __get/__set methods. Therefore the coupling issue > is pretty moot for PHP5 regardless of how the variable is accessed. a class writer would have to use the __get and __ set methods in their class to expose access to private members. those methods are suitable for special purposes and anyway client code cant use them if theyre not defined in a class, so i dont consider the coupling issue moot. -nathan
