Sunday, 22 March 2009

Delegation and Interfaces 1.

Browsing through programming pages in Wikipedia has led me to the Delegation Pattern which in typical Wikipedia fashion has been explained quite clearly with examples. Does it solve my question of wanting to create a clear system of classes with a simple logical behaviour wrapped by a standard presentation layer. I'll sketch out something for this tomorrow.

Heirarchical Classes for code reuse

I was reading the other day about programming with classes. The article, by John K. Ousterhout (who is actually talking about scripting languges and programming in the next century) said that class inheritance and multiple level of classes didn't actually help that much with code reuse as you often the classes were not useful seperately and hence the code was more bulky and difficult to reuse. Which made me think about the codebase I'm starting to work on now. Classic 5 year old PHP codebase programmed by enthusiastic and very smart 'amateurs'. I've not met the people who compiled most of the code but it has just been lumped together over the years and as such is a comprehensive jumble of multi-thousand line long PHP scripts with the single page to a single file paradigm with only a minimal amount of code reuse. So since I've been hired to work on the code and not to rearchitect it I'm left with the puzzle of how to build something in the middle of the mess and untangle it as I go. So are classes the way to go? I think classes are an excellent way of compartmentalising functionality. So I think accessing a datastore - whether it be a database or a file with a particular format - should be done through a class. Classes seem to be used a lot in this codebase to group together similiar functionality. So there are classes full of static functions which provide functionality. This is good but it creates a question about when some of the functions should be grouped into different classes. And what form should these new classes take? Should they be subclasses of some helpful parent class so I don't repeat code? Or should that parent class actually not be a parent. Should the functionality in it just be pushed into a class which is used by all the new classes. Question for today How to tell if a class should be subclassed into a heirarchy of classes with different subclasses to provide different functionality? Discussion I'm not sure although I think the answer might lie in the wikipedia article for inheritance and particularly the quote, 'In most quarters, class inheritance for the sole purpose of code re-use has fallen out of favor. The primary concern is that implementation inheritance does not provide any assurance of polymorphic substitutability—an instance of the re-using class cannot necessarily be substituted for an instance of the inherited class'. So if my parent class and the child class cannot be substituted into the same bit of code to provide different functionality then probably it's not appropriate to structure your code like that. I think I agree with that. Conclusion The parent class should be an ancestor or perhaps a more primitive instance of a class and shouldn't exist just to provide a neat library of functions.