Quality-wise of this post; not gonna lie - Probably will be low. It's 7am and I'm low on posts. This isn't a bubbling pressing issue on my mind.
I don't need to stream my thoughts to work through something...

What I do need... is a post for this week. Soooo... I'm writing one so there's one to get posted.

I could very easily let a week slide and no post go up... and yet... I don't wanna.

Today, I've selected to pull some teeth to get out "No Enums"!

Why an Enum?

When I see enums, I need to ask "What does the enum represent?" ... which is normally met with some kinda "state".
It's a terrible question. Probably should edit it out of the post and go with the better question - "What are you going to use it for?" It's a piece of data, if it isn't going to be used, it shouldn't be in our system. What's it used for?

It will be used for a decision of what behavior to invoke. That's what enums are for, to enable decisions about how a system should behave based on the value of some state.

I hope it's clear that this is a massive violation of encapsulation. The data is extracted from the object to make a decision of how to do something with the object.

It's all about the object and it has no say!

The problem ties back to "Getters and Setters" we're getting data out.

Even if we avoid the getters and setters. We avoid any other object knowing about our data and telling us what to do. We make all the decisions about what to do based on our internal enum...
What are those methods going to look like?
...
They're going to be big. And Grow. There is clearly a set of cohesive behaviors around the enum state.

Extract these into objects.

Then make them the object that gets created.

I'm not a fan of factories unless it's only to enable the strategy pattern, then... I'm not gonna complain too loudly.

The enum is no longer required; shouldn't be used; and the system is simpler.

No Getters

Enums are my favorite things to remove from having getters because they show the massive simplifcation better than other types. All those "decisions" go away, consumers simply make the call, the object simply does it's thing.

Trust Your Code.

I could have really written this post with a single line "Each enum value is a missing object". That's what it ends up as, enums are missing conceptual representations.

Closing

A short post, not much to it. It's probably why no Enums has lagged a bit as an addressed technical practice. It may not even need it's own rule in the end; what we get when we remove enums is addressed by other rules.

I think it's good to have though. It's a reminder. Enums are everywhere, we should remember we're not supposed to use them.