Jeroen is a Software Craftsmanship advocate with over 15 years of experience. He is CEO of https://pro.wiki. Previously Jeroen created Wikidata.org and was Software Architect at Wikimedia Deutschland.
Even with all this description I do not understand the situation well enough to say much about it, which makes me think this does not work as an illustration of how to decide if unification is desired or not.
One thing I'm wondering about is why not do something like
public class Thing
{
int Id { get; set; }
string Type { get; set; }
string Name { get; set; }
bool Active { get; set; }
}
In other words, having a field that indicated the type, and then naming the class to something meaningful in your domain. Presumably also without the mutability part, so you have a nice Value Object (assuming no domain logic belongs on the thing itself).
I think this is a fine example where unification makes sense. The abstraction saved me a lot of work, outweighing coupling or complexity issues, whereas with only 2 OptionTypes it would've been silly to go that route.
The Thing class wouldn't help our code much. Even though they're small sets, they have discrete types and tables. And overtime some of these types did change and get extra properties. Also I prefer to have meaningful names, both in the database and the code. This also helps the guy that makes the occasional report using the database.
But that is another discussion really. Just like the I-prefix.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Thanks for the more verbose example.
Even with all this description I do not understand the situation well enough to say much about it, which makes me think this does not work as an illustration of how to decide if unification is desired or not.
One thing I'm wondering about is why not do something like
In other words, having a field that indicated the type, and then naming the class to something meaningful in your domain. Presumably also without the mutability part, so you have a nice Value Object (assuming no domain logic belongs on the thing itself).
Generally I find it odd to have objects that just contain data have an interface for them, such objects being mutable, or interfaces containing an interface prefix or suffix.
Anyway, I will keep the lack of examples for this post in the back of my mind and hopefully come back in some time to mitigate it.
I think this is a fine example where unification makes sense. The abstraction saved me a lot of work, outweighing coupling or complexity issues, whereas with only 2
OptionTypes
it would've been silly to go that route.The
Thing
class wouldn't help our code much. Even though they're small sets, they have discrete types and tables. And overtime some of these types did change and get extra properties. Also I prefer to have meaningful names, both in the database and the code. This also helps the guy that makes the occasional report using the database.But that is another discussion really. Just like the I-prefix.