35
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 ...
13
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 ...
12
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 ...
6
Documenting your process for writing the code is not necessarily helpful for later readers of the code. Some of these aspects are worth preserving, some are not. For example, having multiple versions of the description is not helpful.
However, your comments are helpful because they explain the intent of some of the code. To make those comments more useful, ...
5
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);
4
You already identified the downside: Inefficiency.
Anyway, code using .at() might come to rely on the exception, which might make it even less efficient, as the compiler thereafter cannot optimize out the check for sure.
There are containers which have significantly different semantics for .at() and []:
std::string. Specifically, the terminator is not part ...
4
I agree with @ThomasOwens's anwer as far as you should comply to the companies test strategy.
I disagree with his answer as far as different test types serve different purposes, have different properties and consequences. IMHO it is important to know the differences to be able to implement them for maximum efficiency (with the development process in mind, ...
3
What you are describing seems like the difference between solitary and sociable unit tests. I would have some questions about loading a 45MB database and sending actual mail - the database is quite large and sending email often requires a lot of other pieces. Conceptually, though, it seems like the unit tests are sociable unit tests.
The concerns that I have ...
3
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 ...
3
IMHO a pretty correct statement in the question is this:
Everybody is explaining MVC differently.
The reason behind this is that today there is not 100% consensus among software engineers what exactly counts as MVC, and what not. So as long as your program has model classes, which are unaware of the views, and view classes exclusively responsible for the ...
2
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.
...
Only top voted, non community-wiki answers of a minimum length are eligible
