Why does OOP make little sense to me?

Question

So we have objects like a person who has attributes like: Hair Colour, Eye Colour, Height etc.
They have methods like Walk, Eat, Sleep etc. Of course this makes sense.

Now lets take a dice object. It has attributes like Current Face, Number Of Roles etc

Now this is the part that gets me, it would seem logical to have a method of Role() in a dice class that returns an int wouldn't it? But how does a dice roll itself? A cat can walk, sleep, eat, meow. But a dice cannot roll itself, so why does it seem so logical to put it there? When really it should just be GetValue() or something like that.

I don't need an explanation of OOP, I understand the programmatic and design patterns side. Just the logic of class methods seem to contradict themselves.

Answer 1

You seem to be taking a literal approach to this, which is incorrect. Programming requires the mind of someone who can think outside the box.



Roll is an action of the dice, not an attribute. Kind of like walking/running is the an attribute of say a human. With that said, programming a roll method is just a matter of assigning the dice a random number between 1 and 6 (for a standard dice).



Objects have attributes to them, and actions associated with them. Think outside the box!

Answer 2

I agree that you're taking things too literally :P However, it can be argued that this is a poor implementation of a die, unless you're taking about a low level object (like a random number generator).



A die isn't an object that actually does something. It's a class that "knows" something. People are going to ask it what it knows and then make a decision based on that information. Instead the die should be making the decision.



For example, a die might be used in a board game to decide which path to take. It's the die that should be choosing the path. A procedural implementation might be:



    int value = die.roll();



    switch (value)

    {

        // Logic to pick the path. The result is a variable named path.

    }



    player1.follow(path);



A high level object oriented implementation would be to place the decision logic in the die and the location logic in the path. You let the object that knows things make the decisions that results that logic. This is called the Tell Don't Ask principle. A Tell Don't Ask implementation would look like this:



    die .chooseFrom(paths) .lead(player1);



Rather than:

- Asking the die for a value, using that value to choose a path, and having the player follow that path,

- The die chooses a path which leads the player.



The game can be written as a loop that makes this call until something happens.



This makes a little less sense if you take it literally. A die can't roll itself, much less pick a path, but you have to think outside the box. It's not exactly easy to think this way. A more programming specific version of this pattern is the internal iterator.



You may be used to doing this:



    for (IIterator it = col.iterator(); it.hasNext(); )

    {

        accumulate(it.next());

    }

    out.append(accumulate.result());



However, it's arguable that .hasNext() and .next() should be a single state since they can't be inconsistent from each other. An internal iterator lets you do this:



    col.apply(accumulate).appendTo(out);

Answer 3

Well, then give it whatever name you want.

You could name it GonnaMakeSomeSandwichesAndThenGoToBed().

Of course, a dice can't do that, right? But you can name this way that Roll() or GetValue() method. It would make no sense, though.



The point is that it doesn't matter what the name of your methods are. Of course it is quite important to have suggestive names. It's easy for you to code, it's easy for someone else to read, understand and even develop some more your code or just to use your classes/methods (for example if you work in a software development company, where you don't do the job all by yourself). But, apart from this, it really doesn't matter what name you assign to your methods, as long as they do what they are supposed to.