3

So I have a function in our application's Business Edits assembly (which references the Data Access assembly) which I've found a need to use in the Data Access assembly. I like the idea of keeping the business rules together, but if I want to use the function I obviously have to move it. So what I've decided to do is move the function to our bottom-level Helpers assembly and have the current Business Edits function call the Helpers function. That way the function is still discoverable in the Business Edits assembly but usable in the DataAccess assembly.

This solution feels wrong, but is this actually a terrible thing to do? If so, why, and what's the best alternative?

1

I love following DRY (don't repeat yourself). I hate looking at the same nonsense repeated over and over. It's hard to read and hard to maintain.

But that isn't the reason I don't use 3 every where I need a three. I give it names that tell me what it means. That helps me remember and keeps me from accidentally changing two different ideas of what that 3 is with search and replace.

Just as you shouldn't use magic numbers don't let the quest to be DRY force you into making magic methods. It's ok to have two methods hold the same behavior if they don't share the same responsibility. One may end up needing to change and you don't want that causing a bug in the other.

Of course you can take that too far just the same as you can take DRY to far. It's a rare problem that only has one principle to consider. Don't fall into the trap of blindly following any of them. Always temper them by looking at your whole problem and think about what your doing to me when I have to come fix this in 6 months.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.