How to decouple two classes elegantly in the following example?

Suppose we take the case of building a Vending machine using OOP principles.

Let us suppose we have an abstraction called VendingMachine.

class VendingMachine {
    List<Slot> slots;
}

The VM class has a list of slots and each slot may have some capacity (to model 5 items one behind the other).

Now how do I associate a Value ($) to a slot. Clearly each slot will have the same item so each slot should be associated with same value or item.

But in terms of responsibility, the VendingMachine class should only think ejecting an item, or throwing an exception when trying to eject an item from an empty slot. I think that it is not the responsibility of VendingMachine class to know what is the value of a particular slot.

How do I design this elegantly? Is there some design pattern that comes to your mind.

My solution is to create a class MoneyManager.

class MoneyManager {
    MoneyManager(VendingMachine vm);
    Pair<Slot, Item> mapping;
}
class Item {
    int itemCode;
    BigDecimal value;
}

Even if you think that the modelling is wrong, what I am more interested in knowing is how do you decouple 2 classes like that.

For example if you design a car parking lot, a class Vehicles should have information on how much space it takes (number of spots). A ParkingLot has information how much spots it has.

But I don't want the car to know in which ParkingLot it is parked and in which spot. Similarly I don't the ParkingLot to maintain the state of what cars are parked where. Should there be an intermediate class ParkingManager which maintains this state for a clean design?