PR ReviewEncapsulation stops at the assembly boundary

time to read 2 min | 247 words

The following set of issues all fall into code that is used within the scope of a single assembly, and that is important. I’m writing this blog post before I got the chance to talk to the dev in question, so I’m guessing about intent.

image

This change is likely motivated by the fact that callers are not expected to make a modification to the resulting dictionary.

That said, this is used between different components in the same assembly, and is never exposed outside. That means that we have a much higher trust between the components, and reading IReadOnlyDictionary means that we need to spend more cycles trying to figure out who you are trying to protect from.

Equally important, in this case, the Dictionary methods can be called without any virtual call overhead, while the IReadOnlyDictionary needs interface dispatch to work.

image

This is a case that is a bit more subtle. The existingData is a variable that is passed to a method. The problem is that in this case, no one is ever going to send null, and sending a null is actually an error.

In this case, if we did get a null, I would rather that the code would immediately crash with “what just happened?” rather than limp along with bad data.

More posts in "PR Review" series:

  1. (24 Nov 2017) The simple stuff will trip you
  2. (08 Nov 2017) Encapsulation stops at the assembly boundary
  3. (25 Oct 2017) It’s the error handling, again
  4. (23 Oct 2017) Beware the things you can’t see
  5. (20 Oct 2017) Code has cost, justify it
  6. (10 Aug 2017) Errors, errors and more errors
  7. (21 Jul 2017) Is your error handling required?
  8. (23 Jun 2017) avoid too many parameters
  9. (21 Jun 2017) the errors should be nurtured