[SOLVED] Inheritance a bad idea?

[alexweber15]

in a nutshell i had the following classes planned out:

 

abstract class Lead{
    $attributes=array();

    function __construct($params){
        // if params is array copy to internal array attribute
    }

    // some other abstract and other not methods like validation for each attribute, getters and setters and so on
}

class InsuranceLead extends Lead{
    // basically the same functionality as a Lead with 1 additional attributes
}

class FinanceLead extends Lead{
  // basically the same funcionality as a Lead with 5 additional attributes
}

 

so basically it made sense to me to make both InsuranceLead and Finance Lead inherit from Lead because they share most of the same attributes and also common getter and setter methods

 

 

I recently had to have this diagram reviewed by a veteran VB.NET coder and he crushed it saying that the dependance on the parent Lead class was a fundamental weakness and that instead I should have the two seperate classes (FinanceLead and InsuranceLead) and have the original Lead object as an attribute instead of superclass.

 

 

Is this a good idea?  It kinda makes sense but I kinda just gotta let it settle in a bit and think about it before taking any action...

 

ANY feedback is GREATLY appreciated, thanks!

 

-Alex

[KevinM1]

Well, I think your VB.NET coder friend was thinking of the solution as some sort of Strategy pattern implementation (http://en.wikipedia.org/wiki/Strategy_Pattern).  That's the only reason why I can see them suggesting storing the base functionality as an attribute.

 

In general, though, inheritance isn't bad per se, but when building program structures, composition is much more flexable.  Looking at your example, without any other context to base my opinion on, I don't think your idea is bad at all.

[alexweber15]

his main argument was talking about project layers and that the logic layer should communicate directly with the DAO layer, passing back and forth the data objects and that the GUI layer should have no knowledge of how the DAO layer works, interacting directly with the logic layer and the data objects passed to it.

 

i agree with him on that point.

 

he also mentioned for example that if i were to create a separate branch of development such as creating a web-service (this is a dynamic website) i would run into problems because of the excessive dependancy on the Lead class and the lack of cohesion.

 

 

[keeB]

Generally, what you're VB.Net coder was referring to was having a fragile base class. You can google this term for more clarity. If you're really interested, there's an article written by Allen Holub called 'Why Extends is Evil' [1] which should shed some light on it.

 

Basically, he argues it's usually better to write to a concrete interface than to extend a base class. If inheriting and the base class changes, you have to worry about all classes which derive from it and how this affects them. I'm not as good at making the case, so you should probably just read the article.

 

[1]: http://www.javaworld.com/javaworld/jw-08-2003/jw-0801-toolbox.html

 

[alexweber15]

thanks for the links

 

 

[448191]

his main argument was talking about project layers and that the logic layer should communicate directly with the DAO layer, passing back and forth the data objects and that the GUI layer should have no knowledge of how the DAO layer works, interacting directly with the logic layer and the data objects passed to it.

 

i agree with him on that point.

 

he also mentioned for example that if i were to create a separate branch of development such as creating a web-service (this is a dynamic website) i would run into problems because of the excessive dependancy on the Lead class and the lack of cohesion.

 

 

 

If those where his arguments for shooting down that basic set of classes, I would have laughed at him right in his face. 95% of that has nothing to do with your code example. Just seems to me he wanted to show off.

 

That said, I'm not saying he was completely wrong if he meant it could be better. Because it can.

 

Sure, inheritance causes coupling to the parent class. But common bevaviour has to be abstracted out, or a different kind of coupling, caused by code duplication, will get the better of you in the end.

 

The main issue with your example code is that the implementations aren't interchangable (LSP). Inheritance isn't the best way to add behaviour.

 

As has been suggested, a basic Strategy would work better:

 

<?php
class Lead
{
private $_aLeadAttribute;
private $_strategy;

public function __construct(LeadStrategy $strategy)
{
	$this->_strategy = $strategy;
}

public function doSomething()
{
	$this->_strategy->doSomething();
}
}

interface LeadStrategy
{
public function doSomething();
}

class InsuranceLead implements LeadStrategy
{
private $_anInsuranceAttribute;

public function doSomething()
{
	//Do the insurance thing to do
}
}

class FinanceLead implements LeadStrategy
{
private $_aFinanceAttribute;

public function doSomething()
{
	//Do the finance thing to do
}
}
?>

 

Of course this has the special case 'problem', but judging by your code comments, I don't think that will be an issue this time around.

 

 

[alexweber15]

hmmmm gotcha!

 

so then i would always instantiate Lead objects, which would be defined more specifically by their strategy attribute.

 

i like

 

also, on a side note, i didn't realize you could use an interface as a function parameter (not sure i used the correct terminology here but i think you know what i mean right?)

[Mchl]

It's not a parameter, but a type hint

 

public function __construct(LeadStrategy $strategy)
{
	$this->_strategy = $strategy;
}

 

means that $strategy argument has to implement LeadStrategy interface.

[alexweber15]

It's not a parameter, but a type hint

 

public function __construct(LeadStrategy $strategy)
{
	$this->_strategy = $strategy;
}

 

means that $strategy argument has to implement LeadStrategy interface.

 

 

that's what i meant by maybe not using the correct terminology... 

[Mchl]

Cool then

 

Shame it's not possible with non_object types.

[alexweber15]

hey, since your out and about on the forums atm i'd like to bother you with one more question if you don't mind

 

as far as i understand:

even though you didn't define constructor methods for the InsuranceLead and FinanceLead classes they should in fact have constructors to initialize their private attributes right?

 

Reason I ask is I was considering using a SimpleFactory design pattern (based on my previous inheritance-based Lead class architecture), but now I'm having second thoughts as to whether it's really necessary, since the Lead class you proposed is at first sight robust enough to carry out any of the tasks the SimpleFactory object would have had to do, in terms of generating leads of a specific strategy... right?

 

if i'm being vague i'd be happy to explain further but I think you'll get the gist of it

 

thanks again!

[Mchl]

Uhuh...

 

Better ask someone who actually knows something about design patterns. I still am learning basics of OOP.

[alexweber15]

thanks anyway for your time dude!

[Mchl]

It wasn't me who helped you the most. Thank guys above

 

You're welcome of course

[alexweber15]

It wasn't me who helped you the most. Thank guys above

 

You're welcome of course

 

True that, and of-course, A HUGE COLLECTIVE THANKS TO ALL WHO HELPED!

 

I've gone on a posting rampage the past few days and I've seen a lot of familiar faces helping me so I hope I can give back soon when I'm more proficient!

 

on an additional note, I created a new post on Design Patterns which should hopefully pick up where this thread left off!

[keeB]

hey, since your out and about on the forums atm i'd like to bother you with one more question if you don't mind

 

as far as i understand:

even though you didn't define constructor methods for the InsuranceLead and FinanceLead classes they should in fact have constructors to initialize their private attributes right?

 

Reason I ask is I was considering using a SimpleFactory design pattern (based on my previous inheritance-based Lead class architecture), but now I'm having second thoughts as to whether it's really necessary, since the Lead class you proposed is at first sight robust enough to carry out any of the tasks the SimpleFactory object would have had to do, in terms of generating leads of a specific strategy... right?

 

if i'm being vague i'd be happy to explain further but I think you'll get the gist of it

 

thanks again!

 

I believe you're talking about the Abstract Factory pattern.

 

http://en.wikipedia.org/wiki/Abstract_factory_pattern

 

[alexweber15]

KeeB, dude, you're like my new hero!

 

lol thx and props on the dedication and patience with new members here!

 

i wish there was a beer or cookie icon so i could give you one