Programming frameworks such as .Net have access modifiers for a reason..yes this is coding 101, but more often than I'd care to admit I've worked with developers who only seem to know 2 of them: public and private; they seem to forget that the protected and internal modifiers exist (as well as the ability to combine both the protected and internal modifiers together).  The rationale behind this is usually flawed, something along the lines of "well someone might need to use it at some point."  This is a bad mentality to have.  If you aren't sure if you should mark it as public, mark it as protected and limit access through derived classes...it's easier to promote this to a public member in a future release than it is to revoke public status.

By minimizing your public API, you A) increase the usability of your library B) decrease your support costs and C) decrease the surface attack area exposed to calling code.  You should also be doing rigorous safety/security checks on all parameters exposed by either public or protected members, but also bear in mind that if someone really does want to use a private or internal member, they can do so by using the .Net reflection API's so don't assume that a private method called DestroyCompanyDirectory can't ever be utilized by calling code.

So in short:

• Keep your public surface area small and simple.
• Expose the least level of access as possible, and remember that the protected and internal keywords can be combined.
• Rigorously check parameters on public/protected API's at the very least, on all members if at all possible.  Don't be afraid to ask calling code to identify itself.
• Just because you need to access the member from calling code doesn't mean your users will.

Share this post: | | | | |