How a cafe owner’s data class got a little too “hands-on”
Imagine you’re running a cafe. Your business is bustling, your code is… well, it’s code. It gets the job done. You’ve got a data class to hold all the important details about an order, let’s call it CafeMetaData. It’s a neat, little data bucket for things like the cafeId, the customer’s contactPhone, and the orderType. Clean, simple, and exactly what a data class is for.
But then, the owner has an idea. “Let’s enable delivery and pickup!” they say. “We’ll add some feature flags to turn them on and off.”
So, you, being the clever developer you are, add the feature flag logic right into the data class. It looks something like this:
data class CafeMetaData(
    // ... other fields
    @SerializedName("orderType") val orderType: String,
    @SerializedName("isDeliveryEnabled") var isDeliveryEnabled: Boolean = FlagProvider().retrieveFeatureFlag(IS_DELIVERY_ENABLED),
    @SerializedName("isPickupEnabled") var isPickupEnabled: Boolean = FlagProvider().retrieveFeatureFlag(IS_PICKUP_ENABLED)
)
At first, everything seems fine. The app runs, the orders come in, and the flags are all there. But soon, things start to get weird.
The problems in the…
Learn more about Tale of Code Review and Refactoring : Episode 2
