This kinda sound a little bit like trying to figure out your domain modelling.
Donkey code
61–64 of 64 posts
Re: Donkey code
#62Earlier quoted context omitted.
I once inherited a codebase that did this, and it was a nightmare to learn. All the classes were named after types of alcohol for some reason. Naming things clearly is really hard, but this approach is just giving up completely.
It needs the right balance. 95%+ of classes absolutely should not do this, but it's great for the handful of times when a class is complex, nuanced, and used prolifically. Assuming good documentation, it just means a few extra minutes learning what some terms mean, and that's worth it in the long run in my experience.
> the handful of times when a class is complex, nuanced, and used prolifically
Is there a way to describe an example of such a class? That sounds like it could have a proper descriptive name, it'd just be a bit harder to come up with.
Re: Donkey code
#63It's not enough to have separate names, implicitly you must also treat them like separate entities and duplicate the code for horses into a separate donkey entity. While the code may be similar at first, changing business requirements means that donkey code and horse code will eventually have to be evolved separately and your future self will be thanking you for duplicating code rather than tangling everything into g…
Aren't there other ways to solve this that are easy to refactor? For example, writing a standalone function for just the common parts of the horse and donkey neigh implementations, and if suddenly some things stop being common to both, move it into the horse or donkey implementations specifically.
Or, maybe this idiom (it's C++ but should apply to other languages with inheritance and virtual method equivalents, e.g. Java, C#). Why not something like this?
https://en.wikibooks.org/wiki/More_C%2B%2B_Idioms/Non-Virtua...
Re: Donkey code
#64Earlier quoted context omitted.
>"name it Steve" philosophy I think of these kinds of names as being like primary key fields in a database: Their main purpose is to distinguish the identities of various things, so it's better not to incorporate any functional/behavioural description into them because that way there's never a need to change the name in the future if the behaviour changes. The downside is that the names become arbitrary lumps of data…
Primary keys in DBs should be natural keys in the first place. You use surrogate keys only to optimize things. So the whole analogy now points in the exact opposite direction as stated.
What's an example of a natural key for a person, that never changes?