Doing it with a class is the same as doing it without a class. There are really two goals here: automatic movement of a sprite and object-oriented programming.
The first is pretty simple, but requires you to think in steps. In order for it to look like something is moving you need to incrementally change its position, orientation, or shape. Each iteration of the program loop you need to move the sprite a little bit in the direction that it is travelling. Exactly how you do this is up to you. You can hard-code it, you can develop something dynamic that figures it out at run-time, or you can develop something dynamic that uses pseudo-random numbers to "invent" the movement at run-time.
The second is pretty simple too, but it takes years to figure out how to do properly. In my opinion, it is best to ignore static members of classes entirely. They are global and sort of defeat the purpose of using a class. There are rare occasions where it is useful, but almost never necessary. Instead, think of your class as the blueprint for an object. An object is a thing. A noun. It can have attributes/properties/data and behaviors/functions.
Start by imagining what objects might be involved in automating the movement of a sprite. For starters, there is a "sprite". Whether that means a bitmap, a game object, or a character is up to you. You may want to create a class for that so that you can instantiate sprite objects. You may want a separate object to figure out the actual movement. Perhaps an object to represent points in the "world", like the current position of the sprite, where it is ultimately trying to go, and the different points along the route that it will need to go to get there. You may want to include algorithms for path finding, for example, if you want a dynamic solution. There are many possibilities for objects.
One of the best strategies that I can give you for writing OO is to use dependency injection. Pass all of your data in and out of an object. Don't just let an object magically have values. Make sure those are passed in through a constructor. When you want to do something, make sure that you're passing that data in, and returning the result. In other words, avoid void functions with void argument lists.
Also try to visualize how you would like to use the object. In the context of simulating the movement of a sprite, you are going to need to be able to move one step at a time. You might do something like this:
Sprite sprite(starting_point /*, ...other_arguments...*/);
Route route(starting_point, /*...other_points...,*/ ending_point);
Essentially defining a sprite and a route to follow. Then within your game loop, every frame, you'd figure out how to move the sprite to the next point in the route.
Location loc = sprite.getLocation();
Location nextLoc = route.getNextLocation(loc);
OO is entirely subjective. There is no defined right way. You can do it however you want. It is a tool that you can use to organize your program. It doesn't change the underlying program at all. It doesn't magically make it better or easier.
This is a fairly simple example. Depending on how big the game is, it might be worth finding path finding algorithms and using those to figure out the route dynamically. And you can use pseudo-random number generators to make up starting and ending points at run-time to simulate being "alive" and having original ideas. These things are not trivial though and will require quite a lot of effort to accomplish.
Try to focus on a tiny piece of every problem at a time. Nobody can fit an entire, non-trivial program in their head at once. You need to break the problem down into smaller pieces and focus on one piece at a time.