3 ms·

Seems to me that the whole point of OOP is programming is to encapsulate this information. An enum is basically just a degenerate class. If you're finding that

Seems to me that the whole point of OOP is programming is to encapsulate this information. An enum is basically just a degenerate class. If you're finding that you are doing a case on your enum all over the place, you should probably be defining them as objects (or possibly subclasses). The solution of creating a bunch of tuples (or structs)...well, that's just creating a bunch of objects. The language and paradigm already has a way of dealing with these that's a bit more flexible and powerful than tuples.

altcognito 12y ago
> The solution of creating a bunch of tuples (or structs)...well, that's just creating a bunch of objects. Essentially in Java that's actually what you're doing, and if you override the constructor of the enum you get a nice version of what the author is describing (but with more flexibility than a straight up Map) (oh, bthornbury covered this in his comment)
spacemanmatt 12y ago
> An enum is basically just a degenerate class My recent facebook post is, verbatim: Java enums are shitty classes.
westoncb 12y ago
That's how I thought about it when reading. I kept wondering whether I was missing something, but: the things to be modeled by programs have a continuum of complexities, but there are only a small number of language constructs to use for modeling, which are each more/less suitable based on the complexity of the thing to be modeled (for one thing). The 'language constructs' from simple to complex are something like: enum, struct, class. It sounds like the author wants something that's between struct and class, though personally, I don't see why doesn't just use a class/objects.
chipsy 12y ago
The meaning is basically different. An enumerated value doesn't always carry around additional state, neither is it expected to carry around implementation information. Applying polymorphism often creates an nasty inversion. If the situation is such that you need the algorithm to mutate "outside" data based on "inside" (the object) information, you end up calling a method on the object that "passes in the world." This is a particularly terrible form of coupling since it obscures the straight-line path and allows new code to break old code when it gets used out of context. The trick the article describes is more like what you would do if you were modeling this problem in SQL and decided to normalize the data into an additional table: Each enum now points to a static "program" containing various true-false properties - e.g. trucks are large, cars are not. Instead of checking the enum directly across all business logic, you can use it to look up an associated property. Subsequently, your test doesn't have to be updated to account for new types of vehicles. Algebraic data types (such as Haxe's enum) that can do a compile-time coverage check and allow parameterization are another way to attack this problem.

altcognito 12y ago

> The solution of creating a bunch of tuples (or structs)...well, that's just creating a bunch of objects. Essentially in Java that's actually what you're doing, and if you override the constructor of the enum you get a nice version of what the author is describing (but with more flexibility than a straight up Map) (oh, bthornbury covered this in his comment)

spacemanmatt 12y ago

> An enum is basically just a degenerate class My recent facebook post is, verbatim: Java enums are shitty classes.

westoncb 12y ago

That's how I thought about it when reading. I kept wondering whether I was missing something, but: the things to be modeled by programs have a continuum of complexities, but there are only a small number of language constructs to use for modeling, which are each more/less suitable based on the complexity of the thing to be modeled (for one thing). The 'language constructs' from simple to complex are something like: enum, struct, class. It sounds like the author wants something that's between struct and class, though personally, I don't see why doesn't just use a class/objects.

chipsy 12y ago

The meaning is basically different. An enumerated value doesn't always carry around additional state, neither is it expected to carry around implementation information. Applying polymorphism often creates an nasty inversion. If the situation is such that you need the algorithm to mutate "outside" data based on "inside" (the object) information, you end up calling a method on the object that "passes in the world." This is a particularly terrible form of coupling since it obscures the straight-line path and allows new code to break old code when it gets used out of context. The trick the article describes is more like what you would do if you were modeling this problem in SQL and decided to normalize the data into an additional table: Each enum now points to a static "program" containing various true-false properties - e.g. trucks are large, cars are not. Instead of checking the enum directly across all business logic, you can use it to look up an associated property. Subsequently, your test doesn't have to be updated to account for new types of vehicles. Algebraic data types (such as Haxe's enum) that can do a compile-time coverage check and allow parameterization are another way to attack this problem.