Which design pattern will be most appropriate to be used to separate model from behavior?

I have class Elevator which contains base informations about Elevator itself. Like here:

@Builder
@Getter
@Setter
public class Elevator {

private final int id;
private final float maxSpeed;
private final float maxLiftingCapacity;
private float currentSpeed;
private float currentConditionFactor;
private Dimensions dimensions;
private Localization localization;

}

Now I want to separate behaviour of elevator from model, I want to create another class, maybe it will be implementing Runnable or Callable (doesn't matter now, it should be universal). It will have methods like these (prototype):

public class ElevatorRunnable implements Sleepable {

    private final Elevator elevator;

    public ElevatorRunnable(Elevator elevator) {
        this.elevator = elevator;
    }

    private void moveUp() {
        float posY = elevator.getLocalization().getY();
        if (posY >= elevator.getBuilding().getGroundHeight()) {
            elevator.getLocalization().setY(posY - elevator.getCurrentSpeed());
        }
    }

    private void moveDown() {
        float posY = elevator.getLocalization().getY();
        if (posY <= elevator.getBuilding().getHeight()) {
            elevator.getLocalization().setY(elevator.getLocalization().getY() + elevator.getCurrentSpeed());
        }
    }

I really don't think that is correct like it is now, so my question is, which pattern should I use to separate information of object from run() methods etc. Should it be Decorator?

Thank you in advance!

I think your code looks fine. The whole point is to not have state in the behavioral classes. And you don't need a design pattern for that. Well, actually, you already used one: composition.

This specific case can be overly extended since "the elevator itself moves up/down" (this means the logic will go in Elevator) or "the controller handles the movement of the elevator" in which case a Controller class can have the behavior.

Also the localization field can be discussed since the position is not actually an elevator attribute, instead it can be a controller attribute.