Philosophy behind object design - and how I applied in to a Java example
Archive - Originally posted on "The Horse's Mouth" - 2015-01-14 19:27:47 - Graham Ellis
* When you're writing all the logic to deal with a particular type of data, it's a good idea to write it into a CLASS
* Where you have similar types of data, it's a good idea to put the shared logic into a BASE CLASS and then write SUBCLASSES which are based on that base class. That way your common code is in one place, can be maintained easily and shared later on with any other subclasses too.
* When you write your code in classes, you can write a TEST PROGRAM to check that just the class works, thus segmenting your testing and getting a far easier regime, yet far more robust results
* Should you wish to have type of objects outside your "interitance tree" which perform in the same way as the object within the tree, you can declare that they conform to an INTERFACE.
* You can then write FURTHER PROGRAMS that use arrays of objects of classes which conform to the interface.
* And you can place all of the classes and the interface defintion into a package and bundle them up together for distribution and use into a single jar file.
I did the above in Java today.
There's a base class called Bird - [here]. It's desribed as an abstarct class because it only contains common logic - not the full definition of a bird, as that's completed in the next classes.
There are subclasses for Duck and Gull - [here] and [here].
There's a first program that creates and uses a duck and a gull object and extracts data from them - [here]
I then defined an interface called Friend - that's [here].
And finally, my example that uses an array of friends - in my simple example they're all birds, but I can have friend who aren't birds too provided that they conform to the interface which requires them to return a greeting when their greet method is called. See [here].
* When you're writing all the logic to deal with a particular type of data, it's a good idea to write it into a CLASS