3 ms·
It'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 enti
by SPBS 3y ago
It'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 giant mess.
Write! That! Code! Twice! Then once you have more experience in the domain, you can refactor out the parts that are actually semantically identical. Code reuse should be proven, not a given.
- trealira 3y agoAren'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-Virtual_Interface https://en.wikibooks.org/wiki/More_C%2B%2B_Idioms/Non-Virtua...