1

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.

Konrad Viltersten
  • 205
  • 1
  • 13
  • 2
    Possible duplicate of [Why do we need private variables?](http://programmers.stackexchange.com/questions/143736/why-do-we-need-private-variables) – gnat Apr 01 '16 at 12:04
  • 1
    see also: [Why is Encapsulation considered a primary principle in OOP?](http://programmers.stackexchange.com/questions/230515/why-is-encapsulation-considered-a-primary-principle-in-oop) – gnat Apr 01 '16 at 12:05
  • @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. – Konrad Viltersten Apr 01 '16 at 12:16
  • 4
    advantageous point laid out in [top answer in the duplicate](http://programmers.stackexchange.com/a/143739/31260) 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?](http://programmers.stackexchange.com/questions/148108/why-is-global-state-so-evil) and multiple questions linked to it – gnat Apr 01 '16 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. – Frank Hileman Apr 01 '16 at 13:38
  • Some developers still reason about code as if it's poured in concrete. If some private method needs public access, just open it up and change it. There really is no need to just open everything up just in case.. as if you couldn't do so case by case later on. – Joppe Apr 03 '16 at 14:59

1 Answers1

7

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.

JacquesB
  • 57,310
  • 21
  • 127
  • 176
  • 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.) – Konrad Viltersten Apr 01 '16 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 01 '16 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. – Konrad Viltersten Apr 01 '16 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 01 '16 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. – Frank Hileman Apr 01 '16 at 13:36