Instead of writing a class, an alternative would be writing a type (but on paper). A subtle distinction but consider this. For some problems it is helpful to think about your data and view the problem as a series of data transformations: data-oriented programming. In such cases you don't have a single dog that you want to invoke a member function on, and then call another one, but a thousand dogs that you want to perform the same function on all at once.
Also instead of having a large granular Dog type you could split it into different aspects, possibly using composition or AoS/SoA style held in completely separate collections, that together act as if they were a dog. This has the potential to scale better, not in just better design but performance as well. So think about the types, and think about functions using those types, but the former and latter don't necessarily need to be joined together (via a class).
Instead of writing a class, an alternative would be writing a type (but on paper). A subtle distinction but consider this. For some problems it is helpful to think about your data and view the problem as a series of data transformations: data-oriented programming. In such cases you don't have a single dog that you want to invoke a member function on, and then call another one, but a thousand dogs that you want to perform the same function on all at once.
Also instead of having a large granular Dog type you could split it into different aspects, possibly using composition or AoS/SoA style held in completely separate collections, that together act as if they were a dog. This has the potential to scale better, not in just better design but performance as well. So think about the types, and think about functions using those types, but the former and latter don't necessarily need to be joined together (via a class).
Thank you, very elaborately put.