Solid design principle

Question

Hi

I am aware about solid design principle but have few doubts as below :

1. Open close
We have open for extension but close for modification. Does this mean that use always inheritance to modify or other mean is there ? Also it's standard practice not to modify class or something need to be done to prevent modifications?

2. Single responsibility

Examine below class :
class employee
{
void performJob();
void setvacation();
void findDirectReportee();

};

This class is not following single responsibility as it sets vacation as well as gives idea about direct reportee as well... How to design in this requirement as class private member may have list of direct reporting employee id and should not go into different class... Right ?

Many thanks in advance. And appreciate your patience and help

Answer 1

For 1, you should make it so you add but don't change existing functionality to perfectly follow the Open Close principle. If you had a class with inheritance, you could do this by adding a new class without modifying an existing one. You could also do this by adding a method that no existing code calls. In other words, you add new things without modifying existing things.

The main purpose of Open Close is to prevent unintentional changes to existing code's behaviour. It is more useful for public API's than a closed source software project.

If you control all the code that uses the code you're updating, the Open Close principle is virtually useless. If you can thoroughly test your changes and fix any new problems, you can maintain the code with higher quality by modifying existing functionality and ignoring the Open Close principle.

Open Close principle has drawbacks. If you had a method spelled wrong that just might be called by third party code, you can't fix that without violating Open Close principle. At best, you indicate the incorrect spelling is deprecated for a while, possibly years, and add a correctly spelled method and encourage every developer to use that instead.

If you control all the code that uses it, you could fix the spelling error and update all references so the fix doesn't break anything. If you can remove all references to the misspelled method, you can remove the misspelled method. This would violate the open close principle but would clean up your code better too.

I'll leave question 2 for someone else.

Answer 2

Ketan Lalcheta Thanks for the follow-up. Apologies for losing track of this.

Talking about SRP in a vacuum or using contrite examples can be tough as the design decisions would depend on context.

The Employee class presented contains methods that seem to lack cohesion and imply being part of what is referred to as a God object. In some contexts, these may be more cohesive than in other contexts.

Alternatively, these could be further abstracted into more targeted entities as seen below:

Entities:
- Employee
- ScheduleManager
- TeamManager

The object instances could be injected in a number of ways or all of these could be placed in an Aggregate class.

It really depends on the context for the domain.

But all of this is related to cohesion more than SRP. That's because the example presented really suffers more from lack of cohesion than anything else.

Answer 3

Josh Greig I was agreeing with your explanation up to the point the context shifted to interface versioning and code refactoring scenarios. This seems to be a common misunderstanding about OCP.

OCP is more fundamentally rooted in how one approaches the implementation of some logic, such that the logic isn't tightly couple to some function or class that needs to be updated as the logic is extended.

Consider the following:

class Order {
bool GetTaxRate (string state) {
switch(state) {
case "OR":
case "WA":
case "CA"
return .09;
case "NY":
case "VA":
return .07;
default:
throw new Exception(
"State not supported.");
}
}
}

This method is designed to return the tax rate based on the states supported at the time the code was written.

However, later, when new states are supported, the current design requires updating the switch cases in the method. This is what violates OCP.

(continued...)

Answer 4

"Open for extension, closed for modification" refers to any patterns and techniques that would support delegating this logic to new classes rather than being coupled in the existing code.

Therefore, the entire switch case would need to be abstracted to... say... for example, a class that could polymorphically be implemented via interface bindings or what ever.

Implementing such an abstraction is what is meant by satisfying OCP.

That said... let's imagine a scenario where we decide to refactor the code or fix some invalid logic. OCP doesn't restrict refactoring code that needs to change due to some discovered issues or gaps. If you have to change it, change it. But, abstract the code that is about extending the logic over time.

Hopefully, this makes sense.

Answer 5

Ketan Lalcheta I'll try to answer #2 when I get a moment. It's 4am EDT here... so... it's time to sleep. 😴

Answer 6

David Carroll , thank you so much for detailed explanation... In your example about tax rate, I could thought of adding factory pattern. Like for each state passed as enum as argument, it would return tax rate. Is this correct understanding ?

Also please share your valuable suggestions for point #2 ...

Many thanks for your help and effort

Answer 7

Thank you Josh Greig for clarifying point 1. It's too good and covering almost many cases

Answer 8

The answer is 7.