SOLID Problems

Question

Hello 🙂
I am trying to write a program that counts the number of odd and even numbers. I want to implement different ways to do that.
I want a user to be able to select how the counting is done. No matter how I twist and turn the problem, I seem to violate the OCP! 😔
I could use a list of possible strategy names, but I was scolded last time for that approach - it having been called "a recipe for disaster".
I could use an enum for possible strategies, but that would violate the OCP.
I am really at a loss 😔 How do I create such a program, adhering to all the recommended principles of object oriented programming?
Thank you 😇💕

Answer 1

Your instructor might expect you to use the strategy pattern... same what you discovered in a previous topic.
The point is you don't store the possible ways of counting the numbers, in a hardcoded list, but provide a flexible way to extend the code, adding more counting strategies by inheritance...

Answer 2

In my opinion, we can separate the problem in two parts: a service (library) that provides the specific functionality, and the client application that's using the library's features.
The library can implement the strategy pattern, adhering the open-closed principle, to ensure that any change to its code will remain backwards compatible, basically the only change allowed is adding new methods of calculation (new strategies).
On the other hand you may or may not want to change the client application, when a new strategy becomes available. I think that modification of the client code should be treated more liberally. There can be good reasons to keep the cient code unchanged even when the library evolves.

Answer 3

Not 100% sure, but looks like a coupling problem.
Keep in mind that SOLID are not mandatory; are rules to enforce<good practices and avoid problems later as the code grows, but try to apply it always perfectly can become a handycap.
Better use when can and its convenient, but only experience will say when , even how ; ]

Answer 4

Thank you 🤗💕 Yes, I guess I am trying too much 😰 I think of it this way now: as a library and a program that uses it 🙂 The different strategies are like services that the library provides, and the program declares which services it makes available to the user, and the user can then choose one.
This way, new services can be added in the library without changing any existing objects. But if the program wants to offer new services, it needs to change of course! 🤷 But changes in the library do not break the program, and changes in the kind of strategies only affect the program, not the library 🙂 Does that make sense? Well, I will try 🍀🙂
Thanks again! You have been most helpful 🤗

Answer 5

This is how I have done it now 🙂
https://code.sololearn.com/cY41iM6cZVQC
Any feedback would be appreciated 💕😇

Answer 6

Thank you 🤗💕
Yes, this is related to my previous question 🙂 The problem I have is, that input here comes as string. If this contains a user choice, then at some point I have to translate a string to a chosen object, don't I? 🤔 Maybe I took the remark too strictly? 🤔
I have read a pdf on OCP, and the further the changes went, in the end they arrived at an array of object names of the objects that were possible. They call it "data driven approach to achieve closure" or "table driven".
It is obvious that extending the capabilities of a program does require changing the source. The point I guess is to have changes at as few locations as possible 🤔 I could use an XML to describe these 🤔 Then add new classes and update the XML config file.
But I cannot get past the problem that I have to translate an input string to an object, and using some form of switch, or an enum, that needs to be changed if new capabilities are added 🤔😐
I am now reading about the built-in DI container - maybe that will help 🙂🍀