PS: in this thread nobody has disagreed about what OO programming is. The disagreement was about *how to apply it*. There actually seems to be quite a lot of agreement that the answer depends on what your underlying goal is: - is this throw-away code for a specific problem? - is this code to be included in a useful program? - is this just for practice in an unfamiliar language where you already understand all the concepts? - is this for learning about radically new concepts? And everyone agrees that test cases are good for all of these.
You might find it useful to join another exercism thread and solve some of these problems in a language that you are comfortable with, then solve them in Smalltalk (or Ruby). This will help to separate "how do I solve this problem?" from "how do I express this solution in language X?" Another thing you might find useful, having solved a problem, is to try to solve it a different way. For example, in a functional language, you might solve a problem first in a C-like way using mutable objects freely. Then you might solve it again using immutable values. And then you might solve it again using higher-order functions. And then you might solve it again using point-free style as much as you can. For another example, in R, or Fortran 90, or Matlab, you might solve a problem first in an element-at-a-time way, and then you might try it again using vectorisation to eliminate as many loops as you can. And in *this* example, don't suppose that there is One Right Way To Do It. Get ONE solution going. ANY solution. I would suggest my approach, because (a) of course I would, and (b) it really is a struggle with exercism to find out what the problem actually is, and you want to get to SOME solution quickly. But it doesn't matter so much, because the point is to try it MORE ways than one. This is one way to learn design. Try more than one approach and discover which ones work out better. I started out using Point. Then I tried again just using bare coordinates. I started with position and velocity as instance variables. Then I tried again with them as method temporaries. I eliminated one thing after another until I was left with obviously correct code, and I felt no shame in using #caseOf: to classify characters, even though there are books that will tell you that using "if" and "case" is anti-OO. I could do it again eliminating #caseOf: in terms of "if" if I saw any value in doing so. In this particular exercise, you are simulating ONE instance (the robot) of ONE kind of thing (Robots). That strongly suggests that your solution might have ONE class: Robot, or perhaps TWO: Robot and RobotTest. That's the one active thing. This thing has properties: where it is and which way it is going. Now from the point of view of differential geometry, points and directions are different things and live in different abstract spaces, so I would have a lot of sympathy for having two classes: Place (x,y) and Direction (dx,dy) with #turnLeft and #turnRight as operations on Direction and place plus: distance in: direction as an operation on Place returning a new Place. But a good programmer is a lazy programmer, and looks for existing code to use. And the classic Point class in Smalltalk combines Place and Direction in one "two-dimensional vector" concept, originally designed for 2D computer graphics rather than geometry. It's good enough, and Smalltalk programmers can be expected to know that Point exists (just as Java programmers can be expected to know about Java's point classes), so I'd use it. So now, from one mind, we have designs with 1 Robot 2 Robot, RobotTest 3 Robot, RobotTest, Point 4 Robot, RobotTest, Place, Direction classes. ANY of them could be defended as a good design, depending on what the ultimate aim is.
