Hacker News Reader

Comment by ww520 | Hacker News Reader

> in the next assignment the simple three-element tuple representing an RGB color is replaced by a class with getters and setters and multiple constructors and--most critically--a lot more code.

This is in the classroom setting, during the learning process. It's good to reuse the same example to explore different concepts, from map to class, so that the students don't have to build up a different mental model with another example. It's like writing Hello World in different languages to illustrate the language mechanics. It has nothing to be with whether the requirement (RGB) is too simple for an OOP implementation.

You are using trivial examples to prove "OOP Isn't a Fundamental Particle of Computing." This is the classic straw man fallacy.

View on HN

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!

You mean like this? :)

    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.

The language is F#, basically the code does this:

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.

Reply on news.ycombinator.com