Object inheritance/specialisations

[furious5]

Hi

I was wondering how some of you guys would approach a problem I have at the moment.

I have a base product class, which I have began to extend with a number of different product types inheriting the product class.

Using inheritance I'm therefore able to amend the new product types business logic to overide the base class methods where different business logic applies.

What I'm now beginning to find is that as more and more business rules are applied to the product specialisations I have a number of different methods which don't sit with the base class.

For instance:

class Product { 
	
	function __construct() {
		$this->price = 1;		
	}
	
	public function getPrice() {
		return $this->price;
	}
	
}

class Product1 extends Product { 
	
	function __construct() {
		parent::__construct();
	}	

	
	public function getPrice() {
		return $this->price + 1;
	}
	
	public function getNetPrice() {
		return $this->price - 100;
	}
	
}

As you can see from the example above, whilst I have the same method (getPrice) in Product1 as I do the Product class, I have additional methods in Product1.

Whilst this isn't a problem if all I do is interact with only Product1 objects, how would I be best to approach this if I had an array of 'Product' objects (containing both Product, Product1) and wanted to call the getPrice method for Product objects and getNetPrice method for Product1 objects. Sorry if this sounds convoluted.

I guess a simple approach would be to add stub methods to the Product class however this strikes me as clumsy and this would need to be reflected across every other product specialisation.

Would a better approach to use something like reflection?

[kyberfabrikken]

What's the difference between getPrice() and getNetPrice()? What are they supposed to return?

[furious5]

Probably not the best example, given that you could argue that both objects should have the same behaviour regardless of type given they are common attributes of the object.

What I'm more concerned with is that each object could have differences in the methods they provide and how best to handle this.

[kyberfabrikken]

What I'm more concerned with is that each object could have differences in the methods they provide and how best to handle this.

Yeah, but I think you somehow are getting it backwards. The intention is to have a common interface, with different implementations. That way, the consumer doesn't need to know about how the provider implements the interface. If you find, that you need to call a different method, depending on the type then you should rather declare an abstract method in the superclass, which each child class can implement, and then call this from the consumer.

[furious5]

Kyberfabrikken you're right.

I'm tying myself in knots over something that doesn't need to be fixed. I'll add the relevant stubs to the other objects to ensure I've got a consistent interface for all product objects.

Thanks for responding, its good to have someone to bounce ideas off from time to time.

[Czaries]

I think the Decorator pattern might help you solve this problem. A good simple overview of this pattern can be found in the example chapter of the book Head First Design Patterns.