Reading a book I have found the following statement:
(Object) Behaviors answer either of two questions: What does this object do (for me)? or What can I do to this object? In the case of an orange, it doesn’t do a whole lot, but we can do things to it. One behavior is that it can be eaten.
In my understanding of object behaviour the statement above is correct regarding the first question and is incorrect in case of the second. However, I often see classes with methods like Orange::eat(), and this makes me uncertain about my design skills. So I would like to ask is it a design mistake to give oranges a behaviour eat? (oranges and eat are used just for example)
I think there’s nothing wrong with your way of thinking about objects and their responsibilities.
Orange::eat()would make sense if oranges had mouths. Otherwise, it’s anAnimalwho is doing the eating.The thing of the matter is, SVO (Subject-Verb-Object) sentences aren’t always the best way to describe something, but OOP seems to be heavily biased towards that kind of statement so we frequently run into strange, unnatural and abstract sentence constructions in code.