You friend Will has written a class to handle management information about articles. It's great as far as it goes, but you want to add extra stuff to it, so you persuade Will to give you a copy. He's a nice guy, he does so ... but then a month later he tells you he's added a lot more code and you're forced to make a lot of changes to your derivative work ... and so is Jane, to whom you had in turn passed a copy of the code. Far, far better to write the code to OO principles, in which you simply write a file that describes
the changes and can be automatically applied when you get Will's update. But this requires careful class design.
Here are some of the principles involved ...

From a class of "article", I have specified three derived classes - blog article, web published article and metro article. The blog article in turn is split into published and draft, and the draft is further split into withdrawn and future. In each case of inheritance, the class on which the new class is based is known as the "base class" and the newly created class is known as the "sub class" ... and we call this extending a class. This might sound back to front at first, but when you consider that you
extend the code to create a class that will be more specific and have
fewer members, it starts to make sense.

A base class of film contains a lot of methods and data .. but we have had to subclass it to "blockbuster" and "cinema" for our "getcost" method ... since you pay per person at the cinema, but per film hired from Blockbuster - a different algorithm demanding a different (but related) class

In order to minimise the amount of code you need, you should put common code as near to the root of the tree as possible. In this specification example, you'll see that I have put "gettext" into the base article class, as it's common over
most of the subclasses. I have then added a separate "gettext" method into my draft brog article class, as that works on different principles. This replacement technique is
overloading

Where there's no obvious way to overload a class, the addition of an intermediate class in the hierarchy - even if it's an object typel you'll never create - can help you out. In this example, I wanted a "getvet" method that applied to classes farm and pet, and a different one that applied to classes mythical and wild. But I didn't want to write either piece of code twice. The solution was to use an intermediate ("abstract") class .. and have one of the pieces of code in the base class, and the other in the abstract class.
(written 2009-05-11, updated 2009-05-12)
Associated topics are indexed under
Q907 - Object Orientation and General technical topics - Object Orientation: Design Techniques [3454] Your PHP website - how to factor and refactor to reduce growing pains - (2011-09-24)
[3260] Ruby - a training example that puts many language elements together to demonstrate the whole - (2011-04-23)
[3085] Object Oriented Programming for Structured Programmers - conversion training - (2010-12-14)
[3063] Comments in and on Perl - a case for extreme OO programming - (2010-11-21)
[2977] What is a factory method and why use one? - Example in Ruby - (2010-09-30)
[2953] Turning an exercise into the real thing with extreme programming - (2010-09-11)
[2889] Should Python classes each be in their own file? - (2010-07-27)
[2878] Program for reliability and efficiency - do not duplicate, but rather share and re-use - (2010-07-19)
[2865] Relationships between Java classes - inheritance, packaging and others - (2010-07-10)
[2785] The Light bulb moment when people see how Object Orientation works in real use - (2010-05-28)
[2747] Containment, Associative Objects, Inheritance, packages and modules - (2010-04-30)
[2741] What is a factory? - (2010-04-26)
[2717] The Multiple Inheritance Conundrum, interfaces and mixins - (2010-04-11)
[2523] Plan your application before you start - (2009-12-02)
[2501] Simples - (2009-11-12)
[2380] Object Oriented programming - a practical design example - (2009-08-27)
[2327] Planning! - (2009-08-08)
[2169] When should I use OO techniques? - (2009-05-11)
[1538] Teaching Object Oriented Java with Students and Ice Cream - (2008-02-12)
[1528] Object Oriented Tcl - (2008-02-02)
[1435] Object Oriented Programming in Perl - Course - (2007-11-18)
[1224] Object Relation Mapping (ORM) - (2007-06-09)
[1217] What are factory and singleton classes? - (2007-06-04)
[1047] Maintainable code - some positive advice - (2007-01-21)
[836] Build on what you already have with OO - (2006-08-17)
[831] Comparison of Object Oriented Philosophy - Python, Java, C++, Perl - (2006-08-13)
[747] The Fag Packet Design Methodology - (2006-06-06)
[656] Think about your design even if you don't use full UML - (2006-03-24)
[534] Design - one name, one action - (2005-12-19)
[507] Introduction to Object Oriented Programming - (2005-11-27)
[236] Tapping in on resources - (2005-03-05)
[80] OO - real benefits - (2004-10-09)
Q909 - Object Orientation and General technical topics - Object Orientation: Composite Objects [3251] C++ - objects that are based on other objects, saving coding and adding robustness - (2011-04-17)
[3152] Jargon busting - (2011-01-30)
[3142] Private and Public - and things between - (2011-01-22)
[2922] Getting the OO design write - with PHP a example - (2010-08-14)
[2641] Object Oriented Programming in PHP - (2010-02-19)
[1348] Screw it or Glue it? Access to Object variables - a warning - (2007-09-12)
[1345] Perl and Shell coding standards / costs of an IT project - (2007-09-11)
[592] NOT Gone phishing - (2006-02-05)
[477] Class, static and unbound variables - (2005-10-25)
Some other Articles
Application design in PHP - multiple step processesBasic OO principlesPHP4 v PHP5 - Object Model DifferenceCleaning up redundant objectsDesigning a heirarcy of classes - getting inheritance rightIn honour of the photograph, I present ... a walk from Reybridge to LacockWatching the teleCrossrefering documents with uniqueness and inconsistency issues - PHP proof of concept demoMaking Regular Expressions easy to read and maintain