Composition and Inheritance Wrap up
I have been very pleased with the response to the topic of when to use Composition and when to use Inheritance. The responses demonstrate that SSWUG is valued by an audience much broader than just database professionals.
Ian shares some thoughts that wrap up this topic very nicely.
Your example of a Car inheriting from an Engine is inappropriate – because a car is not a refinement of an engine, but contains an engine. This is the key criteria when one considers whether inheritance is the appropriate relationship – is class B a refinement of class A? If so, then inheritance is the appropriate relationship – if not, then it isn’t. Plain and simple.
A far better example to demonstrate inheritance would have been class Car inheriting from Vehicle. Then you could have had a Motorcycle inheriting from Vehicle too.
The base class could contain properties that are applicable to all vehicles, e.g. MaxSpeed, Colour. The Car class could have a property NumberOfDoors, which would not be appropriate to the Motorcycle.
Similarly another common question is when should should I define an interface? The answer to this is that an interface represents a common contract that is fulfilled by all classes implementing the interface. Therefore interfaces tend to be used to standardize behavioral attributes of a class. For example, defining the IPrintable interface would allow us to specify a Print() method which defaults to printing one copy, and an overloaded Print(NumberOfCopies) method where we could stipulate the number of copies. Because interfaces specify contracts, they tend to be more suitable for doing-stuff and therefore are more useful for containing method calls rather than properties.
The issue of optional parameters has been introduced (wrongly in my opinion) in order to cope with a deficiency in the understanding of such basic object-oriented concepts. Similarly defining properties as Vars is equally weak – just because you can pass in a type doesn’t mean that you should.
Object orientation is based upon the three core principals of abstraction, encapsulation and polymorphism. Changing the type of properties from outside the class violates encapsulation and therefore is an attempt to undermine one of the core principals of OO.
Readers Comments – Health at the Office
Tomas writes:
Several of the programmers in my office have started standing part of the day. Our company has been nice enough to purchase things like adjustable arms for our laptops, monitors and keyboards. I have gone so far as to get a tall desk. I do have a drafting chair where I can sit when I want.
For fun, watch the video here: http://www.ergotron.com/WorkFit/tabid/649/default.aspx
Your comments are always welcome. Feel free to submit responses to any editorial, or even introduce your own topic of interest or personal experience. Send your comments to btaylor@sswug.org.
Cheers,
Ben
$$SWYNK$$
Featured Article(s)
Tips for using SQL Server 2008 Table Hints
In this article, you can find some helpful tips to use SQL Server 2008 table hints.
Featured White Paper(s)
Hybrid Management White Paper
Written by AvePoint
As organizations worldwide continue to look for ways to… (read more)