[RESOLVED] What to implement in this case

[stlaural]

Hi guys, I'm kinda having a brain freeze here thinking about this.
Simple best practice question here I would say.

I have a class to create lets call it "Contract" and it has a type property that can be "Service" or "Product"

If I instantiate a Contract of Service type, it should have a start date and and end date. These two dates should be mandatory but only if the instantiate Contract is a Service.

What are the different ways to implement that ? I thought about using the Factory design pattern so if you ask the factory of a Service type Contract you need to provide the two dates but I kinda find it overkill for just two different cases (Service and Product) Any Ideas of other efficient ways of doing that? I Just can't believe there wouldn't be something else.

Thanks for any suggestion.

[jmcilhinney]

You could provide multiple constructors and the constructor you use determines the type. If you don't specify the dates then type Product is used and if you do specify the dates then the type Service is used.

That said, does it really make sense for these to be the same class? If the dates don't relate to products at all then maybe you should have a Contract class that is inherited by a ServiceContract class that then adds the extra properties.

[stlaural]

Hey JMC, Thanks for answer.
I did thought about using multiple constructor but as you said it didn't seem very appropriate.
I finally ended up creating a small factory that can return a Product or a Service which are two seperate classe that inherits from the interface IItem. And the class Contract now accepts IItem to add new Items to it.

[Shaggy Hiker]

Why an interface, in this case? This seems like a place for simple inheritance. Are there really no functions that are implemented the same between the two, and which would therefore be suitable in a base class?

[stlaural]

Why an interface, in this case? This seems like a place for simple inheritance. Are there really no functions that are implemented the same between the two, and which would therefore be suitable in a base class?

Yes there are functions that are implemented the same between the two. The only difference is that if the Item is to be a Product then it doesn't need a start and an end date, while if its a Service then these two dates are mandatory.

[Shaggy Hiker]

So you could have the base class be Item, and both the Product and the Service class could inherit Item. The common functionality would be in Item. Actually, from your description, ALL the functionality would be in Item. If that is the case, then the base class could be Product, and the Service class could derive from Product. The Service constructor would take the two start dates as arguments. Therefore, to create an instance of Service, you would HAVE to supply the dates, but to create an instance of Product, you would not. Since every object can be cast to an instance of its base, your Contract class could take an instance of Product, and you would be able to pass it either a Product or a Service and it would work fine. If you then needed to know the specific type, you'd have to use GetType to determine that, but the same would be true using an interface.

I'm not opposed to the interface route, either. It's a good solution, too, and I know of no reason why my suggestion would be better in any way, other than it might be a bit easier to implement. The only problem with the interface route would be that if you wanted to change how method X worked for both of them, you'd have to make the change to both classes, whereas using inheritance you would only need to make the change to one place. That's nothing but a housekeeping improvement, though, and would have zero impact on runtime. The only reason I suggested the other route is to give you other options to consider in case you had overlooked them.

[stlaural]

So you could have the base class be Item, and both the Product and the Service class could inherit Item. The common functionality would be in Item. Actually, from your description, ALL the functionality would be in Item. If that is the case, then the base class could be Product, and the Service class could derive from Product. The Service constructor would take the two start dates as arguments. Therefore, to create an instance of Service, you would HAVE to supply the dates, but to create an instance of Product, you would not. Since every object can be cast to an instance of its base, your Contract class could take an instance of Product, and you would be able to pass it either a Product or a Service and it would work fine. If you then needed to know the specific type, you'd have to use GetType to determine that, but the same would be true using an interface.

I'm not opposed to the interface route, either. It's a good solution, too, and I know of no reason why my suggestion would be better in any way, other than it might be a bit easier to implement. The only problem with the interface route would be that if you wanted to change how method X worked for both of them, you'd have to make the change to both classes, whereas using inheritance you would only need to make the change to one place. That's nothing but a housekeeping improvement, though, and would have zero impact on runtime. The only reason I suggested the other route is to give you other options to consider in case you had overlooked them.

Thanks a lot Shaggy, it does give me another option to consider.