Never say never. Unless it’s impossible.

I could very easily imagine that your system with Shop an Customer, may one day manage Purchase of those customers in that shops. It would then make sense to have PurchaseTag. But while you could chose to have an own transaction related tag (yet another tag entered by the user), you could also decide to automatically add some tags belonging to the most expensive product chosen, to the most used shop tag searched by the user online in the month preceding the purchase, etc.

This example shows that a never-assumption very often appears to be a not-now-statement. When you make important design decisions you should therefore carefully ask “what if”, just to be sure you don’t make decisions that you’ll regret later. Keep your design open and future friendly: Don’t close doors if you don’t have to.

  Your abstract class is in this regard a wise choice:

• in the end, a tag is a tag (this is not likely to change)
• at the same time, it allows some differences/specialization (open for extension)
• and generic code written for the tag parent will (at least if LSP is ensured) work with all future kind of tags not yet invented.

But what about behavior and separation of concerns?

The only thing that bothers me in this design is that we did not mention at all any behaviors. The question is therefore to know if the shop and customer tags only differ by the values they can take (value space) or also by their behavior.

If it’s only about the value-space (we don’t really care but the business yes), I’d consider another approach:

• Use Martin’s approach to implement a qualified tag: each tag is associated with an identifier telling what the tag is about.
• And specialize the context where the tag is used and in particular its containers (for example using dependency injection for the factory and selection of the right subset of tags in the tag repository).

In my view, this approach would implement a better separation of concerns: the tag class is focused on the tags themselves, and the responsibility for using the right tags is moved to another class

This would allow you a higher degree of freedom to innovate by specializing tags according to their own nature (e.g. single language tags as now, multilingual tags, graphical tags, voice tags, ...) and at the same time ensure through the tag container or a tag policy that no mistakes can be made in assignments.

Never say never. Unless it’s impossible.

I could very easily imagine that your system, may one day manage Purchase of those customers in those shops. What bout the new PurchaseTag? Should it be yet another independent transaction related tag entered by the user? Or could it be automatically assigned by the system for example based on the most expensive product chosen, or the most used shop tag searched by the user online in the month preceding the purchase? In the latter case some overlaps would be needed, without putting in question the overall design

A never-assumption very often appears to be a not-now-statement. When you make important design decisions you should therefore carefully ask “what if”, just to be sure that you won’t regret that decision later. 

Keep your design open and future friendly: Don’t close doors if you don’t have to. Your abstract class is in this regard a wise choice:

• in the end, a tag is a tag (this is not likely to change)
• at the same time, it allows some differences/specialization (open for extension)
• and generic code written for the tag parent will (at least if LSP is ensured) work with all future kind of tags not yet invented.

But what about behavior and separation of concerns?

The only thing that bothers me is that we did not mention at all any behaviors. A class is not just a wild aggregation of values.

The question is therefore to know if the shop and customer tags only differ by the values they can take (value space) or also by their behavior.

If it’s only about the value-space, I’d consider another approach:

• Keep the tags general: Use Martin’s approach to implement a qualified tag: each tag is associated with an identifier telling what the tag is about.
• specialize the context where the tag is used and in particular its containers.

In my view, this approach would implement a better separation of concerns: the tag class is focused on the tags themselves, and the responsibility for using the right tags is moved to another class.

This would allow you a higher degree of freedom to innovate by specializing tags according to their own nature (e.g. single language tags as now, multilingual tags, graphical tags, voice tags, ...) and at the same time ensure through the tag context (for example using dependency injection for the factory and selection of the right subset of tags in the tag repository) and the tag containers, or a tag policy, that no mistakes can be made in assignments.

Never say never. Unless it’s impossible.

I could very easily imagine that your system with Shop an Customer, may one day manage Purchase of those customers in that shops. It would then make sense to have PurchaseTag. But while you could chose to have an own transaction related tag (yet another tag entered by the user), you could also decide to automatically add some tags belonging to the most expensive product chosen, to the most used shop tag searched by the user online in the month preceding the purchase, etc.

This example shows that a never-assumption very often appears to be a not-now-statement. When you make important design decisions you should therefore carefully ask “what if”, just to be sure you don’t make decisions that you’ll regret later. Keep your design open and future friendly: Don’t close doors if you don’t have to.

Your abstract class is in this regard a wise choice:

• in the end, a tag is a tag (this is not likely to change)
• at the same time, it allows some differences/specialization (open for extension)
• and generic code written for the tag parent will (at least if LSP is ensured) work with all future kind of tags not yet invented.

The only thing that bothers me in this design is that we did not mention at all any behaviors. The question is therefore to know if the shop and customer tags only differ by the values they can take (value space) or also by their behavior. If it’s only about the value-space, I’d consider another approach:

• Use Martin’s approach to implement a qualified tag.
• And specialize the tag container (for example using dependency injection for the factory and selection of the right subset of tags in the tag repository).

This would allow you a degree of freedom to innovate by specializing tags according to their own nature (e.g. single language tags as now, multilingual tags, graphical tags, voice tags, ...) and at the same time ensure through the tag container or a tag policy that no mistakes can be made in assignments.

Never say never. Unless it’s impossible.

I could very easily imagine that your system with Shop an Customer, may one day manage Purchase of those customers in that shops. It would then make sense to have PurchaseTag. But while you could chose to have an own transaction related tag (yet another tag entered by the user), you could also decide to automatically add some tags belonging to the most expensive product chosen, to the most used shop tag searched by the user online in the month preceding the purchase, etc.

This example shows that a never-assumption very often appears to be a not-now-statement. When you make important design decisions you should therefore carefully ask “what if”, just to be sure you don’t make decisions that you’ll regret later. Keep your design open and future friendly: Don’t close doors if you don’t have to.

Your abstract class is in this regard a wise choice:

• in the end, a tag is a tag (this is not likely to change)
• at the same time, it allows some differences/specialization (open for extension)
• and generic code written for the tag parent will (at least if LSP is ensured) work with all future kind of tags not yet invented.

But what about behavior and separation of concerns?

The only thing that bothers me in this design is that we did not mention at all any behaviors. The question is therefore to know if the shop and customer tags only differ by the values they can take (value space) or also by their behavior.

If it’s only about the value-space (we don’t really care but the business yes), I’d consider another approach:

• Use Martin’s approach to implement a qualified tag: each tag is associated with an identifier telling what the tag is about.
• And specialize the context where the tag is used and in particular its containers (for example using dependency injection for the factory and selection of the right subset of tags in the tag repository).

In my view, this approach would implement a better separation of concerns: the tag class is focused on the tags themselves, and the responsibility for using the right tags is moved to another class

This would allow you a higher degree of freedom to innovate by specializing tags according to their own nature (e.g. single language tags as now, multilingual tags, graphical tags, voice tags, ...) and at the same time ensure through the tag container or a tag policy that no mistakes can be made in assignments.