Proper object extension convention

Do you have a question? Post it now! No Registration Necessary.  Now with pictures!

Threaded View
I'm writing a bunch of classes (specifically, for parsing) but have a
question about class inheritance.

I understand that with textbook object orientation, a class
extension/inheritance represents "a type of" ... like a carrot being a
'type of vegetable'. However, in my case there is no such association :
I am making a class for parsing and extending it to another class
called Alert.

'Alert' is not a type of 'Parser', but because I want to share some of
the functions/variables defined in Parser I decided inheritance was the
best way to achieve this. I don't particularly want to re-instantiate
Parser inside of Alert, nor do I want to redo things such as MySQL

Someone told me that a solution is to pass in my 'Parser' object to the
new Alert instance ... but is this better?

Or should I just ignore what the textbook says and do what is easiest
for me... or is there another method i'm overlooking?



Re: Proper object extension convention wrote:
Quoted text here. Click to load it

If Alert is not a type of Parser, then you should not be deriving Alert  
from Parser.

Quoted text here. Click to load it

That's one way.

Quoted text here. Click to load it

The textbook says this for a reason.  It's not just theory - it will  
eventually cause other problems in your code, also.

Quoted text here. Click to load it

Or, extract the common elements of both into a third class and derive  
both Alert and Parser from that class.  That is, of course, assuming  
they do have something in common.  Not seeing your classes, I can't tell.

But this isn't going to help you with common variables.  Instantiating a  
new Alert class will give you all new variables - even if you derive  
Alert from Parser.

Or, maybe you have things in Parser which really don't belong in Parser  
- they should be in their own class and passed to Parser.  For instance,  
  the code to connect to a database isn't really important in Parser.  
Sure it needs to be done, but it's not critical to that class's  
processing.  So it should be in its own class.  Then you can also use it  
in other classes.

Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.

Re: Proper object extension convention

Jerry Stuckle wrote:
Quoted text here. Click to load it

Building on what Jerry is saying, it is commonly referred to as 'is a'
and 'has a'/'uses' relationships.

You should be asking yourself:
Is Alert a Parser? => Derive
Does Alert use a Parser or have a Parser within it? => Alert contains
an instance of Parser as a property
Does Alert need to behave like a Parser? => Use an interface

Another way to ask yourself is:
Do I need the polymorphism of overriding the methods?
Do I need direct access to underlying code (when there are protected
Does this new class need to interoperate with routines that expect a
normal Parser object?

Judging from only your class names, I'm going to guess that you don't
need to derive Alert from Parser, the logic being Alert probably uses
data that has been parsed, not it does the parsing itself.

Re: Proper object extension convention

Richard Levasseur wrote:
Quoted text here. Click to load it

Thanks for both of your replies. Going by what you guys say then you're
right - Alert doesn't need to be derived from Parser nor does it do the
parsing itself.

To me, logic aside, it just seemed the easiest thing to do to get my
classes to work with each other and share variables (such as path
settings) and instances (such as MySQL or Logger instance) without
having to have the variables passed in.

However, i'll try to re-organise things and see if I can instantiate
objects & declare variables at a non-class PHP page that brings them
altogether. That might be the best solution.

Thanks again!


Site Timeline