On 15 Apr 2012, at 19:41, Lester Caine wrote: > Stuart Dallas wrote: >>> Stuart Dallas wrote: >>>> >> No code duplication but clear separation between static and >>>> >> instantiated usage. However, this is not the best way to structure this >>>> >> code IMO. The better option would be to extract the static parts into a >>>> >> separate class, and use that new class from the instantiated version. >>> > >>> > I've sort of got a problem with that since duplicating every content >>> > package class and then deciding which version I should be accessing does >>> > not make sense. >> I didn't suggest duplicating anything, just separating the elements so >> there's a clear distinction between static and instantiated. This is basic >> software engineering if you ask me. I was going to rant about defensive >> programming here, but life's too short! >> >>> > I'm slowly pulling the 'static' elements into their own function and >>> > leaving the instantiated elements alone but it's slow work. Those people >>> > who kept telling me 'just fix the errors' simply don't understand how >>> > complex that CAN be:( I've only worked my way through half a dozen >>> > packages and I've 20 or so to go ... all just to bring things 'up to >>> > acceptable php code';) >> >> It is as simple as that. Fix the errors. There may be a lot of them, and >> there may be complex interplay between different parts of your code, but >> it's still as simple as just fixing the errors. > > Actually is NOT as simple as that ... > > I have fixed the problems on the package set I use on a number of my sites, > but it simply brings me back to your first comment, since fixing the problems > is not the same as producing tidy code going to build on. The original code > base comes from PHP4 times, but has now been developed into a base 'content' > class from which all other 'content' classes are descended. The static > functions create generic url, uri and the like, while the 'instantiated' > version simply uses the objects own values to provide the variable elements. > If I move the static functions into separate classes why is that better than > packaging the descended code in the class itself?
"Better" is highly subjective. For me it's better because it follows the DRY and KISS principles. If the URL building is going to be used both statically as well as within the context of an object, that code does not belong within the class which is the type of that object. If we were only talking objects then yes, it would make sense to put that functionality into the base class, but NOT as a static method. To repeat, this is highly subjective, and I can only base my opinion on my education and experience. There is no "right" way. > What I'm trying to establish here is in what way the code base needs > re-writing in line with 'current good practice' while keeping the sites > running as reliably as they have over the last few years with the 'bad > practice' being flagged by 'STRICT' :( The code needs rewriting so that static functions are called statically, and non-static functions are called on an object. Outside of that and a few other simple rules PHP doesn't care how you organise your code. -Stuart -- Stuart Dallas 3ft9 Ltd http://3ft9.com/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
