In the example you've posted, the overtime factor should be a variable or a constant. *(Java example)

class PaycheckCalculator { float overtimeFactor; protected float getOvertimeFactor(float overtimeFactor) { this.overtimeFactor = overtimeFactor; } protected float setOvertimeFactor() { return overtimeFactor; } } 

OR

class PaycheckCalculator { public static final float OVERTIME_FACTOR = 1.5f; } 

Then when you extend the class, set or override the factor. "Magic numbers" should only appear once. This is much more in the style of OCP and DRY(Don't Repeat Yourself), because it is not necessary to make a whole new class for a different factor if using the first method, and only having to change the constant in one idiomatic place in the second.

I would use the first in cases where there would be multiple types of calculator, each needing different constant values. An example would be the Chain of Responsibility pattern, which is is usually implemented using inherited types. An object that can only see the interface (i.e. getOvertimeFactor()) uses it to get all the information it needs, while the subtypes worry about the actual information to provide.

The second is useful in cases where the constant is not likely to be changed, but is used in multiple locations. Having one constant to change (in the unlikely event that it does) is much easier than setting it all over the place or getting it from a property file.

The Open-closed principle is less a call to not modify existing object than a caution to leave the interface to them unchanged. If you need some slightly different behavior from a class, or added functionality for a specific case, extend and override. But if the requirements for the class itself change (like changing the factor), you need to change the class. There is no point in a huge class hierarchy, most of which is never used.

In the example you've posted, the overtime factor should be a variable or a constant. *(Java example)

class PaycheckCalculator { float overtimeFactor; protected float setOvertimeFactor(float overtimeFactor) { this.overtimeFactor = overtimeFactor; } protected float getOvertimeFactor() { return overtimeFactor; } } 

OR

class PaycheckCalculator { public static final float OVERTIME_FACTOR = 1.5f; } 

Then when you extend the class, set or override the factor. "Magic numbers" should only appear once. This is much more in the style of OCP and DRY(Don't Repeat Yourself), because it is not necessary to make a whole new class for a different factor if using the first method, and only having to change the constant in one idiomatic place in the second.

I would use the first in cases where there would be multiple types of calculator, each needing different constant values. An example would be the Chain of Responsibility pattern, which is is usually implemented using inherited types. An object that can only see the interface (i.e. getOvertimeFactor()) uses it to get all the information it needs, while the subtypes worry about the actual information to provide.

The second is useful in cases where the constant is not likely to be changed, but is used in multiple locations. Having one constant to change (in the unlikely event that it does) is much easier than setting it all over the place or getting it from a property file.

The Open-closed principle is less a call to not modify existing object than a caution to leave the interface to them unchanged. If you need some slightly different behavior from a class, or added functionality for a specific case, extend and override. But if the requirements for the class itself change (like changing the factor), you need to change the class. There is no point in a huge class hierarchy, most of which is never used.

In the example you've posted, the overtime factor should be a variable or a constant. *(Java example)

class PaycheckCalculator { float overtimeFactor; protected float getOvertimeFactor(float overtimeFactor) { this.overtimeFactor = overtimeFactor; } protected float setOvertimeFactor() { return overtimeFactor; } } 

OR

class PaycheckCalculator { public static final float OVERTIME_FACTOR = 1.5f; } 

Then when you extend the class, set or override the factor. "Magic numbers" should only appear once. This is much more in the style of OCP and DRY(Don't Repeat Yourself), because it is not necessary to make a whole new class for a different factor if using the first method, and only having to change the constant in one idiomatic place in the second.

I would use the first in cases where there would be multiple types of calculator, each needing different constant values. An example would be the Chain of Responsibility pattern, which is is usually implemented using inherited types. An object that can only see the interface (i.e. getOvertimeFactor()) uses it to get all the information it needs, while the subtypes worry about the actual information to provide.

The second is useful in cases where the constant is not likely to be changed, but is used in multiple locations. Having one constant to change (in the unlikely event that it does) is much easier than setting it all over the place or getting it from a property file.

The Open-closed principle is less a call to not modify existing object than a caution to leave the interface to them unchanged. If you need some slightly different behavior from a class, or added functionality for a specific case, extend and override. But if the requirements for the class itself change, you need to change the class. There is no point in a huge hierarchy, most of which is never used.

In the example you've posted, the overtime factor should be a variable or a constant. *(Java example)

class PaycheckCalculator { float overtimeFactor; protected float getOvertimeFactor(float overtimeFactor) { this.overtimeFactor = overtimeFactor; } protected float setOvertimeFactor() { return overtimeFactor; } } 

OR

class PaycheckCalculator { public static final float OVERTIME_FACTOR = 1.5f; } 

Then when you extend the class, set or override the factor. "Magic numbers" should only appear once. This is much more in the style of OCP and DRY(Don't Repeat Yourself), because it is not necessary to make a whole new class for a different factor if using the first method, and only having to change the constant in one idiomatic place in the second.

I would use the first in cases where there would be multiple types of calculator, each needing different constant values. An example would be the Chain of Responsibility pattern, which is is usually implemented using inherited types. An object that can only see the interface (i.e. getOvertimeFactor()) uses it to get all the information it needs, while the subtypes worry about the actual information to provide.

The second is useful in cases where the constant is not likely to be changed, but is used in multiple locations. Having one constant to change (in the unlikely event that it does) is much easier than setting it all over the place or getting it from a property file.

The Open-closed principle is less a call to not modify existing object than a caution to leave the interface to them unchanged. If you need some slightly different behavior from a class, or added functionality for a specific case, extend and override. But if the requirements for the class itself change (like changing the factor), you need to change the class. There is no point in a huge class hierarchy, most of which is never used.