Also, "rewrite this RGB color to be a class" is a poor choice of assignment because it doesn't exercise any of the strengths of OOP.
Instead, try "rewrite this as a color class that can handle RGB, CMYK, or HSV representations." Now the value (and challenges) of a good abstraction is made apparent!
type Color
= RGB of int * int * int
| HSV of int * int * int
| CMYK of int * int * int * int
let toHsv =
function
| HSV(h, s, v) -> HSV(h, s, v)
| RGB(r, g, b) -> ...
| CMYK(c, m, y, k) -> ...
That's very elegant. I don't recognise the language from the syntax. From what I understand it makes a new type called Color and defines a function that can do something with that type.
Is that much different from making a class called Color and defining some methods for that class?
I don't see how one is better than the other. An OO example would perhaps be slightly more verbose, but accomplishes the same result.
1) Creates a type which is a discriminated union called Color, that can have three different values (RGB, HSV or CMYK).
2) Defines a function which converts a color of any value (RGB, HSV or CMYK) to HSV.
The argument, although implicit, from me was that even though this can be easily represented using OO, this approach is far cleaner and easier to read (once you know the syntax and concepts obviously - but that can be said for any language), and that the poster above me saying that the benefits of a "good abstraction" becomes apparent implying that this good abstraction can only be supplied by OO, which is not true.
The OO representation would either be one class called Color which always stores it values in one format (say RGB), and then have get/set:ers for manipulating it as CMYK, RGB or HSV. The other way would be an abstract base class called Color which subclasses ColorRGB, ColorHSV, ColorCMYK, etc.
Instead, try "rewrite this as a color class that can handle RGB, CMYK, or HSV representations." Now the value (and challenges) of a good abstraction is made apparent!