At the new client, we had a discussion regarding access modifiers for classes, methods, members etc. One opinion was to keep things as private as possible, only allowing for protected (internal, public) level when necessary. The opposite opinion was to "let things flow" and apply public access level throughout all (or at the very least most) of the classes.

The argument for the former is to prevent misusage by malicious and/or ignorant developers. Also, a general just-in-case precaution.

The argument for the latter is the ease of usage powered by trust for other developers skills and intentions.

The classes in this particular case will be used internally within the company (or maybe even more limitedly, within the division or the team). Still, it's interesting if that's a sufficiently strong argument to support omitting the usual approach of least necessary accessibility.

Without advocating one view or the other (although I do have a strong and clear opinion on the subject), I'd like to get feed-back from other developers in this matter. (The experience and efficiency level of the team, are left out intentionally, since I regard all our members as technically competent).

As I realize it might be unclear what situation I'm talking about, I'd like to emphasize the following. One of the team's members raised the point that under certain circumstances, such as trusted and skilled teammates, localized usage, responsible and competent use cases etc., there's no advantage to follow the convention, whereas the disadvantage is the restraint on productivity. Under the conditions the member referred to, there's no gain to fetch by following decoupling, SOLID etc. However, I wonder if that's a sufficiently strong argument to allow omission of the design principles (in such cases) or if we should respect the conventions in any circumstances, just in case.

  • 2
    Possible duplicate of Why do we need private variables?
    – gnat
    Apr 1, 2016 at 12:04
  • 1
  • @gnat I see where you come from, so perhaps I should clarify the issue. One of the team members raised the point that under certain circumstances (trusted teammates, localized usage etc.) there's no advantageous point to do that. And the disadvantage is the restraint on productivity. In the situation that member described, there's no gain to follow decoupling, SOLID etc. but the question is if that's a sufficiently strong argument to omit the design principles (in such cases) - or if we should respect the conventions in any circumstances, just in case. Apr 1, 2016 at 12:16
  • 4
    advantageous point laid out in top answer in the duplicate is universal, no matter how trusted are your coleagues. "It's not so much a matter of trust, but rather one of managing complexity..." etc. Yet another facet of this advantage is covered in Why is Global State so Evil? and multiple questions linked to it
    – gnat
    Apr 1, 2016 at 12:19
  • @KonradViltersten Decreased encapsulation decreases productivity in the long run, as it increases maintenance costs and comprehension costs. The extra exposed members increase documentation and the learning curve. Use of members that should be encapsulated limits future changes, or makes those changes harder than necessary. Apr 1, 2016 at 13:38

1 Answer 1


It is a red herring to turn it into a question of "trust" or "competency". Access modifiers are a question of encapsulation, and encapsulation is a tool to manage complexity. You want encapsulation regardless of the level of skill of the developers.

It is not like there is a certain skill level above which you don't need to use good development practices like encapsulation, separation of concerns and on. Rather it is the other way around, that skilled developers know how to use these principles, which is why they are more productive than novices.

Note: If you have malicious developers you are in big trouble, and no amount of access modifiers will help you. Access modifiers is not a security measure. In languages like Java or C# you can still call private methods through reflection, and in Python it is no more than a naming convention.

  • So, just to clarify and verify, the gain of easiness of access to the variables, properties, methods etc. should not be regarded as a sufficient (or even relevant) argument while creating the design? (Please note that I'm not opposing your view - in fact, I strongly support it - but I want to get the maximally unambiguous verification to the issue we discussed with the team.) Apr 1, 2016 at 12:36
  • 3
    There is no gain of easiness if you don't actually need access to those members. Rather it makes the interfaces more complex for no gain.
    – JacquesB
    Apr 1, 2016 at 13:01
  • I see your edition and I do agree. However, I prefer not to use the argument of seniority or experience. I prefer, whenever possible, the argument of actual rational point. Just as you made above. We're very happy and satisfied. Apr 1, 2016 at 13:14
  • @JacquesB +1 Your point about encapsulation is spot on, but regarding "needing" access to internals, that is often a matter of opinion. Just two days ago, the logic of my design would have benefited from specifying a parameter as a System.Runtime.__ComObject, but I had revert to using an Object and validating it because the __ComObject class was marked as internal. I think your reasoning is strong for class members, but less strong for the class itself.
    – Mike
    Apr 1, 2016 at 13:20
  • 1
    @Mike Your argument for decreased encapsulation is valid when the developers of a binary component are in a different organization from the users of that component. When the component is provided in source code form, and both users and developers are in the same organization, the object model can usually be modified without resorting to hacks by the user. Apr 1, 2016 at 13:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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