Open Closed Principle confusion
In the case of some logic involving a class. Eg. There maybe an Account class and we calculate the interest differently depending on the type of account with if else. ( eg. if Regular calc this way, else Saving calc that way) . This is undesirable.
With Open Closed Principle, we were taught to turn the original class ( Account ) into an interface, and then introduce derived classes which have their own versions of calcInterest . Now that calcInterest method is implemented in derived classes, we don't need to update existing code logic to accomodate for any new Account type everytime we introduce a new derived Account class.
However, my question is that, when we create the derived class. Wouldn't there still be if else loop to determine which type of derived class we consturct, doesn't that go against open closed principle?
9 Replies
Open Closed Principle in SOLID
In this article, we will learn about the Open Closed Principle. The Open Closed Principle (OCP) in SOLID, coined by Robert C. Martin, asserts that software entities should be open for extension but closed for modification, fostering adaptability without altering existing logic.
I need to figure out which type of account to create, that would depend on AccountType, so there's still if else going on, everytime we introduce a new Account we still have to modify existing code to account for it.
If the account created depends on the account type then each type should provide a way to create an appropriate account for itself
You can apply the same principle as you did when introducing the account interface
Assuming the account types available should also be flexible
@exokem Right now the account type is passed into the constructor, and we have if else loop to create the appropriate account. Not sure how I can create the account dynamically
At some point in your code you will have to write out some kind of mapping to determine which derived Account to create under which circumstances.
This could be centralised using a factory pattern.
I guess you could use reflection or source generators to maybe build this theoretical factory instead of having to write it yourself. But is that payoff really worth the complexity?
Yes, you are right Joschi. I was thinking of using the factory pattern. Like you said using reflection is not really worth the complexity in my opnion.
@Joschi When using the factory pattern. Should all the class properties be of { get; set; }, such that the factory class method can call upon either the base class or the derived class to create the appropriate object? Is there a way better way of handling it? I feel like the class properties should be immutable like { get; private set; }
If immutability is what you want you could use {get; init;}.
I never really used factories myself, but from the top of my head I would have assumed that the factory needs to have all the properties passed into it that are required for creation.
Then you can instantiate all those private set properties from your constructor, or some static creation method.
Thanks. I considered making set public so I can use object initializer to create the classes. Upon some more thought, I can it's better to mark setter as private and create new instance by calling the constructor, as all the properties are required.
If you just wanna use a public initializer you can use init and a backing field.
That's then basically a public init; private set.