DEV Community

Discussion on: The Fallacy of DRY

 
jeroendedauw profile image
Jeroen De Dauw

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

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).

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.

Thread Thread
 
courier10pt profile image
Bob van Hoove

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.