Suggestions to design this class.

[Prasma Kankut]

Currently we have a class in which there are 2 attributes among the others - discountType, discountValue.
As per the business rules,
If the discountType = "Fixed", the value of the discountValue attribute denotes the actual value to be discounted.
If the discountType = "Percentage", the discountValue denotes the percentage to be discounted.
Now, due to requirement changes, we need to consider about the currency also. The business rule is
If the discountType = "Fixed", the discountValue attribute is the value to be discounted in that particular currency.
If the discountType = "Percentage", no need to worry about the currency.
How to go about this? Should I just add another attribute (currency) to the existing class?
Is it okay to have an attribute which will be meaningful for some objects and not meaningful for some other objects?
If I do this, then in my code I have to always check the discountType before dealing with the currency field, which looks ugly to me.
Probably there is a better way to design this. Can somebody comment on this?
Thanks.
[ October 21, 2003: Message edited by: Prasma Kankut ]

[Kyle Brown]

Why not make two classes? Replace the "if-then" conditional logic with polymorphism. Then only the FixedPercentage type will need to do any currency manipulation.
You've not given us the details of your class, so I can't judge whether you need to make your original class into two classes with a shared parent, or apply the Strategy pattern (from GOF) in this case.
Kyle

[Ilja Preuss]

I agree with Kyle.
Take a look at
http://www.refactoring.com/catalog/replaceConditionalWithPolymorphism.html
http://www.refactoring.com/catalog/replaceTypeCodeWithSubclasses.html
http://www.refactoring.com/catalog/replaceTypeCodeWithStateStrategy.html

[Prasma Kankut]

Thanks Kyle and Ilja (how to pronounce it - Ilja or Ilya?)
See, how many times I have read about polymorphism, but couldn't realize that I can use it here. When will I grow-up? Shame on me
Just to make sure that I have understood the things properly, you are suggesting some thing like this.

class Discount {
  DiscountType type;
}
 
abstract class DiscountType {
  float discountValue;
  abstract doSomething();
  
}
class PercentageDiscount extends DiscountType {
  doSomeThing() {
    //Use the discountValue variable
    //Do whatever you want
  }
}
class FixedDiscount extends DiscountType {
  String currency;
  doSomeThing() {
    //Use the currency variable and discountValue variable
    //Do whatever you want
  }
}

Is my understaning right or wrong?
Few more questions:
#1. Is it okay to create more and more number of classes? Won't it make things complex? (sorry if this sounds silly, but I'm pretty new to OO)
#2. In the initial example, I talked about a single attribute. What if there are many such attributes in a same class?
For example, say there is another attribute validationPeriod.
If validationPeriod is "UNLIMITED",
don't use the endDate.
Else, use both startDate and endDate
Should I follow same suggestion and create another class ValidationType? (See #1 again)
#3. Kyle suggested something about the Strategy pattern. I tried to understand it by searching in Google, but all the examples given there uses Swings. Since I'm not familiar with Swings, I couldn't understand what they are talking about
Could you please explain how to use that pattern in the above example. Feel free to make your assumptions regarding the complete details of the class, if required.
Thanks again.

[Ilja Preuss]

Originally posted by Prasma Kankut:
Thanks Kyle and Ilja (how to pronounce it - Ilja or Ilya?)

I am not sure - how do you pronounce Ilya?

See, how many times I have read about polymorphism, but couldn't realize that I can use it here. When will I grow-up? Shame on me

Don't be ashamed - you just grow a little bit again. "The fact that today we know more than yesterday is good news about today, not bad news about yesterday."

Is my understaning right or wrong?

Right, I think.

#1. Is it okay to create more and more number of classes? Won't it make things complex? (sorry if this sounds silly, but I'm pretty new to OO)

Not necessarily. In fact, if done right it is a very powerfull technique to decouple your design, and thereby reduce complexity. See http://c2.com/cgi/wiki?FearOfAddingClasses

#2. In the initial example, I talked about a single attribute. What if there are many such attributes in a same class?
For example, say there is another attribute validationPeriod.
If validationPeriod is "UNLIMITED",
don't use the endDate.
Else, use both startDate and endDate
Should I follow same suggestion and create another class ValidationType? (See #1 again)

I think it would be a good starting point. I had to see the resulting code to have further suggestions.

#3. Kyle suggested something about the Strategy pattern. I tried to understand it by searching in Google, but all the examples given there uses Swings. Since I'm not familiar with Swings, I couldn't understand what they are talking about
Could you please explain how to use that pattern in the above example. Feel free to make your assumptions regarding the complete details of the class, if required.

The above *is* using the Strategy pattern: You vary the behaviour of the Discount class by giving it different strategies for handling the discount type. The Discount doesn't know or care about the specific type, it just polymorphicly calls a method on it.
See http://c2.com/cgi/wiki?StrategyPattern

[Prasma Kankut]

Ilja Preuss: I am not sure - how do you pronounce Ilya?
In German, Ja is pronounced as Ya, Joern as Yoern and so on. So, I thought your name should be pronounced with the 'J' sounding as 'Y'.
Ilya - Il as in ill and ya as in Yard :roll:
Ilja Preuss: Don't be ashamed - you just grow a little bit again. "The fact that today we know more than yesterday is good news about today, not bad news about yesterday."
Thanks. I got a signature
Ilja Preuss: Right, I think.
You think? :roll:
Does it mean
a) There are many ways to do this. To you it looks ok, but others might think otherwise.
b) You are not sure whether this is the right way to do
c) You can tell for sure, only when you get the overall picture (meaning, there isn't much info to come to a conclusion)?
Ilja Preuss: Not necessarily. In fact, if done right it is a very powerfull technique to decouple your design, and thereby reduce complexity.
Okay. This mis-understaning looks a common problem with many novice. I'm not alone.
Ilja Preuss: I think it would be a good starting point. I had to see the resulting code to have further suggestions.
Ok got it. Actually there is no attribute like that, just guessed what should I do if I come across such situations.
And thanks for the links. My Favorites list keeps growing!

[Ilja Preuss]

Originally posted by Prasma Kankut:
Ilja Preuss: I am not sure - how do you pronounce Ilya?
In German, Ja is pronounced as Ya, Joern as Yoern and so on. So, I thought your name should be pronounced with the 'J' sounding as 'Y'.
Ilya - Il as in ill and ya as in Yard :roll:

Then your thought was correct!

Ilja Preuss: Don't be ashamed - you just grow a little bit again. "The fact that today we know more than yesterday is good news about today, not bad news about yesterday."
Thanks. I got a signature

Actually, I stole this quote from Ronald E. Jeffries, a well known XP advocate. Originally he said (in the context of refactoring): "The fact that you know more today, and are more capable today, is good news about today, not bad news about yesterday."

Ilja Preuss: Right, I think.
You think? :roll:
Does it mean
a) There are many ways to do this. To you it looks ok, but others might think otherwise.
b) You are not sure whether this is the right way to do
c) You can tell for sure, only when you get the overall picture (meaning, there isn't much info to come to a conclusion)?

What I meant was both
- it looks like something I would probably do, or at least start with. Depending on the surrounding code, it could well evolve into a different direction, though,
and
- the code looks like you understood the suggestion, but it's not enough information to be totally sure.

Ilja Preuss: Not necessarily. In fact, if done right it is a very powerfull technique to decouple your design, and thereby reduce complexity.
Okay. This mis-understaning looks a common problem with many novice. I'm not alone.

Definitively!

And thanks for the links. My Favorites list keeps growing!

Do you already know our wiki? You would be welcome to contribute!