Are non real world object classes valid?

[Bogeyman]

While it is logical and reasonable to create classes that serve to instantiate interactable objects, such as a Dog class, is it also valid to create classes that serve to group related variables and functions together, but which would not make logical sense to create an object from? One example of such a thing may be a class designed to handle keyboard input, called KeyboardHandler. This class may just have a set of static members to call on, and creating an object of such would be, at least to me, illogical.

Are these types of utility classes valid and reasonable, even though they do not represent a blueprint for real world objects?

[Duthomhas]

Everything in a programmer's purview is imaginary and fantastic.

The point is to manipulate data (an imaginary thing, coming in many different and fantastic ways) which can then, if desired, be used to affect physical things.


Don't confuse levels of abstraction with propriety towards accomplishing a task.

[Cubbi]

A good guideline for creating a class in C++, is to maintain an invariant (see for example Core Guidelines rule C.2 "C.2: Use class if the class has an invariant" https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#Rc-struct )

If those functions in KeyboardHandler have a common precondition that they all rely on (say, "keyboard driver is loaded and functioning"), then they should be non-static member functions of a class that determines that keyboard driver is loaded and functioning in its constructor, throws an exception if that is not true, and closes whatever communication channel it established with the driver in its destructor.

This class may just have a set of static members to call on

If there is no common precondition, a class is meaningless, put those functions in a namespace.

[Bogeyman]

Thanks for the replies.

The reason I ask what makes an appropriate class is because when I was being taught about classes and what they represent, they were explained through real world objects, such as Dog and Cat. Yet often I will come across classes that represent things that are intangible, such as Menu, State, Handler and from the link Cubbi provided, Date. I wondered how correct it was to make such classes, since they did not represent real objects.

However, since these types of classes are so widely encountered, and indeed in the case of Date used as an example by Bjarne Stroustrup, they must be correct. Therefore, it seems the logical scope for what makes an acceptable class is quite broad.

EDIT:
To clarify, are those types of classes listed above and other intangible classes like them perfectly natural and appropriate to use? I'm pretty sure the answer is yes, but I'd like definite confirmation all the same. It's just a strange idea to me to use classes in such a way, but of course in Java it's pretty much a requirement as everything is a class.

[Bogeyman]

Bump.

[Duthomhas]

A 'Date' is as real as a 'Dog'.

[Bogeyman]

Sure, but what about a State? That is not as real as a Dog. I'm trying to understand just how abstract we can make classes. Where do we draw the line between what is and is not a valid class, before it just becomes related functionality with no logical use for object instantiation?

The tone of your reply it seems is one of impatience, which is fine, I understand. My questions are genuine though.

[Moschops]

Classes are just a way to help you think and help you organise your code. You can make them infinitely abstract with zero match to anything you can imagine, and if it helps you think about the code and write the code, it's good. The only class that isn't a "valid" class is one that doesn't compile.

Draw the line wherever is helpful for you, given your circumstances.

[Bogeyman]

Thanks everyone, I now have a better understanding of what can be made a class. Pretty much anything.

[TheIdeasMan]

@Cubbi

IMO There is a better format of the guideline here:

https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines.html

The links work, and there is a link to the original from which the html was made. :+)