I have an entity called History which is tied to an Order entity. History has a property called Operation. All possible values for this property comes from an enum that goes like this:

public enum Operations {   ItemAdded,   ItemRemoved,   SupplierChanged   // and so on... } 

These are the operations through which that history record was generated.

Now, I have to output history information through a REST API for an Android/iOS app to display it.

From the app perspective, every history item is displayed as a list item. For every item, an icon will be displayed and that icon kinda represents the history record’s operation.

And I say “kinda” because there’s a catch. The app will display two pieces of information that it’s not an operation but need to be displayed as if it were one. The DTO I was going to tranfer through the REST API was going to have an Operation property but since I can’t add the app specific items there, I felt like I needed to abstract that into something else.

Now my DTO has a property that I’m gonna call it AppHistoryItemType (not the final name, to be honest I have no idea how I’m gonna call it yet). This property also take its values from an enum:

public enum AppHistoryItemTypes {   ItemAdded,   ItemRemoved,   SupplierChanged,    ItemThatIsNotAnOperation1,   ItemThatIsNotAnOperation2 } 

Not using real enum values here because it would be harder to explain.

I’m using strategy pattern to generate an AppHistoryItem from a History instance. I need that because the item will also contain text based on the operation. I’d have one strategy implementation for every history operation plus the two extras needed by the app.

The biggest confusion in my mind is how to tie the strategy implementation to the enum. What I did was this:

public enum Operations {   [AppHistoryItemForItemAdded]   ItemAdded,    [AppHistoryItemForItemRemoved]   ItemRemoved,    [AppHistoryItemForSupplierChanged]   SupplierChanged   // and so on... } 

Every attribute above each enum value is the implementation responsible for creating the DTO. This way I can use c# Reflection and get the implementation from the enum value.

The two items that are not operations would be generated in a different step, where they are actually needed.

I also can default to some other implementation if someone forgets to add the attribute later if another operation is added.

Now, I feel like I’m adding business rules to an enum which is not very nice. But I ran out of ideas on how else to build. The other option obviously would be to let the Service (which is called internally by the API) to get the strategy implementation based on the enum value in a switch statement. But that also seems bad.

So, would you use strategy here? How would you tie the strategy to enum values? Am I over-worrying about having a “correct” code?

Ps.: As I was about to post, found a similar question suggesting a factory to create the strategy. I guess that would be the way, but should strategy really be the go to solution for this?

Thanks for helping.