How do interactions between objects work?

Question

I am getting confused when objects interact using OOP. Here i'm trying to model the interaction between a vending machine and a coin. The coin is inserted into the vending machine. The interaction is represented by the functions InsertCoin() and Insert().

The resulting main() is very confusing, how are we to know which function to call first?

class Coin;

class VendingMachine
{
public:
    /*
     * Inserts a coin into the the vending machine.
     */
    void InsertCoin(Coin* coin)
    {
        number_of_coins++;
    }
    
private:
    int number_of_coins;
};

class Coin
{
public:
    /*
     * Inserts the coin into the vending machine.
     */
    void Insert(VendingMachine* vending_machine)
    {
        vending_machine->InsertCoin(this);
        
        this->in_vending_machine = true;
    }
    
private:
    bool in_vending_machine;
};

int main()
{
    VendingMachine* vending_machine;
    Coin* coin;
    
    vending_machine = new VendingMachine();
    coin = new Coin();
    
    coin->Insert(vending_machine);               // which function goes first? this one?
    vending_machine->InsertCoin(coin);           // or this one?
    
    delete vending_machine;
    delete coin;
    
    return 0;
}

Answer 1

I'm not going to criticize your design because I see that it's not the point. Indeed coins shouldn't know about vending machines, and the related arguments, are valid. Let's assume that these classes are just dummies like Foo and Bar.

The crux of your question seems to be in these code comments:

coin->Insert(vending_machine);               // which function goes first? this one?
vending_machine->InsertCoin(coin);           // or this one?

At the highest level of abstraction, there should only be one function call here. There is a single operation. The verb is insert, and the nouns are vending machine and coin.

There are two main schools of thought in the world of OOP about this: one which is mainstream (C++'s object system being in this category), and one that is a little off the beaten path.

Mainstream OOP is primarily about creating service abstractions. Specifically, in such a way that the service abstractions can be implemented in multiple different ways, but used the same way. Under this view, in a given object collaboration scenario, we identify which object or objects are the service providers. In this situation, that is probably the vending machine. So what we want is just this:

vending_machine->InsertCoin(coin);

The user of these two objects should ideally not be required to initiate any more steps in order to get the vending machine and the coin to interact.

Now, it may be a fact in the implementation that the coin needs to know that it has been inserted into the vending machine. That aspect has been criticized in some of the other answers and comments. Those criticisms are valid when they are literally about vending machines and coins. In general, there are situations where one object is added to another (that one being the main service abstraction) and yet has to know.

Here is where the non-mainstream OOP makes a valuable contribution. There are object-oriented systems that have multiple dispatch. Instead of methods, there are generic functions. Generic functions are specialized into numerous methods which are dispatched on the run-time type of all of the arguments. Under multiple dispatch OOP, we have this:

insert(machine, coin);

insert is a generic function. The generic function looks at the type of the machine object and the coin object, and then selects a method which best matches the combination. That method then contains logic that is specific to both the type of the machine and the type of coin; it does whatever is necessary without the concern of "which class has this responsibility".

Back under the mainstream OOP, when the responsibility cannot be entirely pinned to one class, we introduce some object collaboration protocols to make up for this.

The collaboration for the insert operation might start with:

vending_machine->InsertCoin(coin);

We make coin itself contain a little service. Anything receiving the coin must follow the protocol of announcing itself to the coin. Thus the vending machine's InsertCoin method does this:

void VendingMachine::InsertCoin(CoinBase *coin)
{
    // notify coin of insertion
    coin->Inserted(this); 

    // ..
}

This is almost like a multiple dispatch. First we dispatch the method InsertCoin based on the run-time type of the vending machine. Then, a second dispatch takes place to complete the operation by doing the coin-side handling: a specific method is chosen based on the type of coin.

Side note: thanks to C++ overloading, the base class CoinBase can have multiple overloads for different kinds of vending machines, which are (statically) resolved by the this argument in the Inserted call.

One of the most useful documentation/design methods for this kind of programming is the sequence diagram:

main                   machine               coin

 |---- Insert(coin) --> |
                        |
                        |---Inserted(machine)->|
                                               |

If you're confused, try drawing sequence diagrams.

These diagrams capture very specific scenarios, often related to use cases; no single sequence diagram gives you the complete picture.

For instance, we would have a dedicated sequence diagram for some use case of inserting a coin into the machine, and successfully obtaining a product, as well as change.

Answer 2

In your design, coins need to know about vending machines. This unnecessary coupling seems to be a wrong start:

• The vending machine’s responsibility is to provide a product if the price is paid. The latter is achieved by inserting coins. So the vending machine needs to know about coins and inserting coins to achieve its purpose. Moreover it probably needs to manage a state depending on the coins inserted.

• But whatever coin’s responsibility is in your scenario (e.g representing a financial value? representing a 3d physical object for a physical simulation?) it is probably not to insert itself in the machine.

  The coin does not even need to know who owns it. Does it change something for the coin if it is in somebody’s purse or within the stomach of a vending machine? It still has the same shape, and still has the same value.

Such a proper separation of concerns is one of the first thing you need to think of in your design. In your case, the interaction would probably involve an object that “owns” the coin, that invokes the inserting feature of the vending machine, providing it a coin as parameter. That’s all.

Answer 3

The code is being too literal in attempting to model the real world. Object oriented programming does not need to model the real world. Instead, it should model the business process of purchasing something from a vending machine.

Instead of a Coin class, consider using an integral type representing the number of cents (if using USD) or another small unit of currency. Within the realm of vending machines, a 32-bit integer giving you a max price of around 4 billion units of currency should be more than sufficient, unless your target audience is ultra rich people purchasing something extravagant from the machine (hey, it could happen).

You do not need to model "inserting money" either. Just model the actual transaction. A transaction with a vending machine requires little more than an amount of money and a choice:

vending_machine->purchase(75, "D1")

I'm not sure you even need to model the product that was dispensed unless the calling code can make use of it. Internally, the vending_machine would decrement the item number if the currency amount was sufficient or throw an exception if the current amount was not sufficient. Or the purchase method could return an integer amount of the difference:

difference = vending_machine->purchase(75, "D1")

The difference would be zero for exact amount, positive if change is required to be dispensed, or negative if the user still requires more money to complete the purchase.

Answer 4

• Coin should have only getters about their value and no insert method since it doesn't have any responsability other that being a legit coin.
• VendingMachine should have an Accept(Coin* coin) method.

Hence:

vending_machine->Accept(coin); 

Answer 5

Not to be too overly literal here... but

"How do interactions between objects work?"

has one answer:

Exactly as you define them to.

Other answers go into more detail and more specifically address your detailed question... definitely see those. But I think you're missing a core point, just by the way this question is asked. Don't get so lost in jargon and "best practices" that change constantly anyway. Understand what you're doing instead, and you can adapt to the changing landscape as technology evolves.

Side note, OOP isn't always the best solution. Again, it goes back to understanding vs regurgitating what you've been told/read.

Answer 6

I would argue that the vendingMachine should be responsible for setting the status of the coin.

You want to minimize the risk that someone does something incorrectly like calling coin->Insert but not vending_machine->InsertCoin. Requiring sequences of calls like this to be done for correct functioning makes the system very difficult to use correctly.

• Present only one alternative, like vending_machine->InsertCoin, and ensure this does everything needed.
• Allow both alternatives, and ensure that vending_machine->InsertCoin and coin->Insert does the same thing, and that either or both can be called, in arbitrary order, with the same result.

It might be helpful to think of classes like APIs, you would want a class, or a set of classes, to work as the user would expect them to. How a set of classes distribute responsibilities between themselves is less important as long as it is consistent and correct (and tested). Another good suggestion is to make it easy to do do common things correctly, and difficult to do unusual or incorrect things, sometimes referred to the pit of success.

An example could be a point and a transform. I want to apply the transform to the point to produce a new point, and there are various ways to write this:

• myPoint.Transform(myTransform)
• myTransform.Transform(myPoint)
• Transform(myPoint, myTransform)

I do not think it really matters what you pick, as long as it is consistent. In each case the it is clear what the method does, and it is not clear that a majority of the users would prefer any single option.

Answer 7

One important aspect that all other answers have not touched upon is ownership.

Your coin represents a resource. Ideally, the same coin cannot be spent twice in a row without having been recovered in the mean time. I think that this is what your in_vending_machine boolean attempts to model.

It is indeed possible to use such a boolean, but this doesn't hold up very well. At some point the coin is retrieved from the vending machine and deposited to the bank, should it have a in_bank boolean too?

Instead, you can leverage the language (move constructors!) to physical move the resource:

class Coin {
public:
    //  Coins can be created and destructed.
    Coin() = default;

    explicit Coin(int cents): cents(cents) {
        assert(cents > 0);
    }

    ~Coin() = default; // if cents != 0, the equivalent of 
                       // your change rolling into a grate.

    //  Coins can be transferred.
    Coin(Coin&& other): cents(std::exchange(other.cents, 0)) {}

    Coin& operator=(Coin&& other) {
        assert(this != &other);
        cents = std::exchange(other.cents, 0);
        return 0;
    }

    //  Coins do not duplicate themselves.
    Coin(Coin const&) = delete;
    Coin& operator=(Coin const&) = delete;

    //  The value of the coin, in cents.
    //  FIXME: use better type to represent money, also... currency!
    int value() const { return cents; }

private:
    int cents{ 0 };
};

Now, we can move our coin into the vending machine, and then the previous owner doesn't have the coin any longer, but only a shell of a coin worth 0.

Note: unfortunately, C++ forces any move-only class to have a "default" state; it's sad, but it's the reality we have to live with.

And thus:

class VendingMachine {
public:
    //  Inserts the coin in the vending machine, increasing the amount
    //  available to buy from it.
    void insert_coin(Coin coin) {
        assert(coin.value() > 0);

        current[coin.value()] += 1;
    }

    //  Returns the coins inserted since the last purchase.
    std::vector<Coin> cancel() {
        std::vector<Coin> coins;

        for (auto const [value, number] : current) {
            for (std::size_t i = 0; i < number; ++i) {
                 coins.push_back(Coin(value));
            }
        }

        return coins;
     }

     //  Purchase...
private:
    //  If you only care about the total, could just be "cents",
    //  but this would not represent non-fungible resources well.
    std::map<int, std::size_t> current;
    std::map<int, std::size_t> coins;
};

int main() {
    VendingMachine vending_machine;

    vending_machine.insert_coin(Coin(10));
    vending_machine.insert_coin(Coin(10));

    auto coins = vending_machine.cancel();
    assert(coins.size() == 2);
    assert(coins[0].value() == 10);
    assert(coins[1].value() == 10);
}