-
I guess that the example suffers from the triviality of the problem.
The problem is just so easy that nobody would be inclined to try a solution that is spread out over several classes and files (is this a requirement in Java?).
What I found actually quite interesting is that Java is so noisy. An equivalent Python programm would need
considerably less space and (therefore) would be better readable as well.
A final note: I'm not too sure if this kind of dispatching is at the heart of OO programming at all. A little dictonary had done the job equally well.
-
This is a great example of solving a problem that you don't have. An agile developer would start with the 'Hacker' version and maybe evolve into the OO version as the requirements evolve.
A helpful way to approach a problem like this is to start with 'the simplest thing that could possibly work'. The Hacker version seems to accomplish this. If the simple solution works, you are done.
If the requirements change and you have to change the code for example to add a new conditional, then you should consider abstracting out that kind of change so future changes of the same type can be made without modifying existing classes - maybe by adding a new class and changing a configuration file, for example.
In this way an OO design is created as needed, as a response to real requirements.
To write the OO solution upfront is just wasting time. Adding MacOS to the mix in the absence of a customer requirement is also wasting time and adding to the maintanance of the code for no customer benefit.
Robert Martin's book Agile Software Development is a great place to learn about this style of development.
-
i believe this would be called Ravioli Code