Case: a library that includes components foo and bar. Both these use an indentical filter in their code.
option 1: create this filter in the filter component (or somewhere else, doesn't matter) and let both use it.
option 2: duplicate code in both components.
Which one would you choose and why?
redundancy vs coupling: which is worse?
Moderator: General Moderators
- Chris Corbyn
- Breakbeat Nuttzer
- Posts: 13098
- Joined: Wed Mar 24, 2004 7:57 am
- Location: Melbourne, Australia
Re: redundancy vs coupling: which is worse?
2.
Code re-use makes life easier all round. So you need to change the functionality a "filter" offers, if you are using the same filter in each component at least you only need to change the code in one place. I can't see many scenarios where code duplication is a preferred option.
Code re-use makes life easier all round. So you need to change the functionality a "filter" offers, if you are using the same filter in each component at least you only need to change the code in one place. I can't see many scenarios where code duplication is a preferred option.
Re: redundancy vs coupling: which is worse?
Code duplication can be an option in a library where each component needs to be able to be used seperately.Chris Corbyn wrote:2.
Code re-use makes life easier all round. So you need to change the functionality a "filter" offers, if you are using the same filter in each component at least you only need to change the code in one place. I can't see many scenarios where code duplication is a preferred option.
This article favors redundance:
http://www.yosefk.com/blog/redundancy-v ... worse.html
Re: redundancy vs coupling: which is worse?
Very good article from yosefk. My reading of his argument is that redundancy may be better than coupling when redundancy permits self-sufficiency and coupling means relying on the code of another developer, and having to coordinate with that developer and other users whenever you need something different from the module.
Motivated by a similar line of thought: a stuntwork - a minimal framework that users modify internally in whatever way suits them, instead of keeping it as a black box and having to rely on configuration settings.
I don't know if this is a stretch, but I think this is a similar line of thought to the end-to-end principle: the idea that if you put clever features in infrastructure that try to anticipate the needs of the layers above, what ends up happening is that the features have to be duplicated anyway, because the infrastructure didn't anticipate some specific, subtle requirement.
Self-containment seems like a good reason as well, where you want to be able to release components without having to pull in too many dependencies.
Any other good reasons?
Motivated by a similar line of thought: a stuntwork - a minimal framework that users modify internally in whatever way suits them, instead of keeping it as a black box and having to rely on configuration settings.
I don't know if this is a stretch, but I think this is a similar line of thought to the end-to-end principle: the idea that if you put clever features in infrastructure that try to anticipate the needs of the layers above, what ends up happening is that the features have to be duplicated anyway, because the infrastructure didn't anticipate some specific, subtle requirement.
Self-containment seems like a good reason as well, where you want to be able to release components without having to pull in too many dependencies.
Any other good reasons?
-
alex.barylski
- DevNet Evangelist
- Posts: 6267
- Joined: Tue Dec 21, 2004 5:00 pm
- Location: Winnipeg
Re: redundancy vs coupling: which is worse?
Interesting question.
Personally code duplication drives me NUTTS so I would settle for coupling over duplication.
Personally code duplication drives me NUTTS so I would settle for coupling over duplication.