After learning OOP design then I got to know my programming way was not correct. One should convert physical entities or logically separable components into classes which are reusable and have their own behavior and properties. One must not simply convert all the entities into objects because that would be really cumbersome.
If I am developing a filter system in console that checks if my program wants an integer from user then it must be an integer, it should not be a corrupted value by user’s typing error or wrong input. For such purpose I should create a separate class to manage all its working and behaviors, distinguished from the console working so that if later I want to use that system into GUI then I can.
But creating objects for such class does not makes sense, so I ended up creating everything static from data members to functions which rather seemed like creating somewhat a procedural design with classes. With only one benefit that all the data was bound into units by classes known as encapsulation.
My Question is , Is it fine to have such interfaces with classes or one needs to move back to procedural for them? I often face such problems with designing when applying OOP design to the working mechanisms of my code.
Edit-1
Let me explain the question more precisely suppose you want create a filter system. So you take input in strings from the user and then perform checks if the data contains numerics or alphas or if the data is really pure, not a mixture of alpha and numerics making the code more robust and bug free. For that I created a class in which one needs to pass string and it will check it out what kind of data it is, based on it’s internal working while working with such mechanism creating multiple objects of the filter system class does not make sense because if one does so then all the objects would be identical in functionality and usage. Which clearly means that there would be no benefit if the class has multiple instances. So I ended up creating everything static because I did not wanted to create objects
1
The thing you asked about is called utility function.
There are lots of information, opinions, and mis-information about the role and propriety of utility functions in object-oriented world.
In your example, the utility function is very simple, so I would have preferred to keep it as a non-member#1 utility function. Your utility function has a very simple signature:
#1: Not a member of a class. However, it could still be placed into a namespace.
bool ValidateNumber(const std::string& str);
When the utility function is used in the context of user I/O (specifically console-based user I/O), the following logic is typically involved:
- Subroutine “ask user for number and repeat until success”
- Print prompt
- Accept one line of text from user
- Validate input (by calling the utility function above)
- If validation fails,
- Print an error message explaining what is wrong
- Loop back to “Print prompt”, etc.
- If validation succeeds, the converted number is returned from this subroutine.
Notice that this subroutine has plenty of states and logic. It has sufficient complexity that it can be made into a class and instantiated into an object. It could also be made customizable, e.g. allowing an application to instantiate two objects, each with a different prompt.
In graphical user interface (GUI), it is more often to see that a number-asking subroutine being wrapped into an object. This is because in the GUI world, a GUI element that asks for a number will have some unique designs, most notably a “spinbox” (a pair of up/down arrows which allow user to increment/decrement the number when clicked). This strongly favors converting the subroutine into an object.
It is perfectly fine to avoid making classes and use static functions. The fact that you only need one instance is effectively an indication that you don’t really need to define a class. This is especially true in C++ which is a multi-paradigm language.
If you need to group different filtering functions together, define a namespace.
2