Why are you going about this backwards?

You can't figure out how to do an OO design. But you already know what you want to have in classes, how many classes you need, and so on. Where are you pulling these things from? Thin air?

Lesson 1. OO programming works differently than procedural does. It is a different way of decomposing your problem space. Think of a machine. Procedural programming is like describing the sequence of actions that take place in a machine resulting in the action. OO programming is like describing what a screw is. Building on that to describe a hinge. And so on until you have a description of a machine that does useful stuff.

So what components would be useful for you? What kinds of things would they do? Don't jump to how they might do them! Just focus on the components and their interfaces. Each type of component is a class, and the interface is its methods. The methods need not include accessors. Would you ask a door how it is made? Then why would you expect an object in an OO system to need to do so?