Access modifiers need reviewing

[bentorkington]

Generally, the public access modifier is overused in this project, which makes it difficult to determine which modifications will be safe and which will be breaking, as well as indicating which audience should be considered when documenting members.

Anything not expected to be exposed to end users should use the more restrictive modifiers internal, protected and private as appropriate.

The System.Runtime.CompilerServices.InternalsVisibleTo assembly attribute makes it possible for unit tests to access members that otherwise would be private-ish in a production library.

[maetl]

The System.Runtime.CompilerServices.InternalsVisibleTo assembly attribute makes it possible for unit tests to access members that otherwise would be private-ish in a production library.

Okay, that is a feature I haven’t had access to in other languages before and is something I can definitely see myself going too far with, but it offers some interesting opportunities to be much more tightly constrained and intentional about what is exposed and callable publicly.

I am fairly sure I have a solid mental model of which methods are supposed to be private and not part of the surface area of the library, so I can probably give quite direct advice here. The registry is a bit of a ‘god’ class so may be somewhat of an exception, but most things should have a clear audience and purpose and therefore a well-defined visibility level.