K. Tsang CEng MBCS PMP PMI-ACP OCMJEA OCPJP
andy kumar wrote:
Now the question is, is it right to use instanceOf operator here?
...
Which is the right way to do it and why, also can there be a better design?
I was leaning towards using instanceOf as I think creating an enum of discountType is just extra work.
andy kumar wrote:Junilu,
First of all I sincerely appreciate your response.
I don't really see how the second set would be simpler but Ok, if you say so...
Ok more realistic discounts are promotionalDiscount, couponDiscount, frequentlyBoughtTogetherDiscount. Now in promotionalDiscount we could have shippingPromotionalDiscount or itemPromotionalDiscount or orderPromotionalDiscount but for simplicity lets not consider that, so we just have promotionalDiscount, couponDiscount, frequentlyBoughtTogetherDiscount.
Ok, I'm still with you, except for the statement "insert it into the product" which doesn't make a lot of sense to me if I were "thinking objects" -- "insert into the product" smells more like procedural type thinking. There's nothing wrong with procedural thinking per se, but you must be careful not to mix your paradigms inappropriately. If you're going to mix paradigms, I would say mix functional and object thinking. That seems to work better than procedural and object thinking.
And a product can have all 3 discounts at a time. so lets assume a product like computer table worth $150 which has promotionalDiscount $10 , couponDiscount $15 and frequentlyBoughtTogetherDiscount $20 so total discount is $45.
So first step is to determine all the discounts and lets say in this scenario all the 3 discount apply, so I calculate the discount amount create the discount object and insert it into the product.
Now based on business rules we can apply
1) all the discount or
2) we have to find the best of discount between promotionalDiscount & couponDiscount and give the better one and always give frequentlyBoughtTogetherDiscount
3) in some scenarios we find the best of the 3 discounts
So I have a service class that takes the product as an argument, this class needs to have a knowledge of the individual type of discounts as it has to make a decision to find the better discounts. It has comples business logic to decide which discount applies and which does not.
So my previous suggestion was like this:-
But I don't like this at all because as the types of discount increase each of the concrete classes have to implement the extra unnecessary method, I hope you are getting what I mean.
There is nothing wrong with this thought except the naming -- the DiscountStrategy classes I mention above are the "domain/business classes", not service classes.
May be I can keep the product class simple and it just has a list of discounts, but then the service class(which gets this product) needs to somehow have a knowledge of the concrete discount values so that it can make an appropriate decision
OR
I should not insert the discounts in the product in the first place, the service gets the product as an argument finds all the applicable discounts (thus it will naturally know the concrete discount classes) and then add only the appropriate discounts to the product....) If I do this I can completely get rid of instanceOf.
Hey! Wanna see my flashlight? It looks like this tiny ad:
a bit of art, as a gift, the permaculture playing cards
https://gardener-gift.com
|