问题
Is there a reason why I should not be marking everything as public in our intranet reporting app?
No one outside out co will ever have access to this code - we have about 20 projects - mostly small and specific.
Is there really a reason why we should be marking things anything other than public?
I have my own thoughts on this which I'm trying to omit as I want this to be unbiased.
(I have sexed up the title slightly)
回答1:
Look up Encapsulation and/or "Information Hiding":
In object-oriented programming, information hiding (by way of nesting of types) reduces software development risk by shifting the code's dependency on an uncertain implementation (design decision) onto a well-defined interface. Clients of the interface perform operations purely through it so if the implementation changes, the clients do not have to change.
If you mark the members of every class as public, you're making for a maintenance nightmare where future developers (including yourself) will be unsure on which parts of the class are meant to be permanent (the contract) and which are purely implementation details.
回答2:
Assuming you mean marking class members/methods as public/private: It is not about security in the sense of someone from outside your organization gaining access to "private" information. It is about teaching the compiler how to detect problems.
For example, say I have a class Account with a member double balance. and member methods Deposit() , Withdraw() and GetBalance() . Calling Deposit() and Withdraw() each does two things: update a table, modify balance
If I leave balance public, a developer (maybe even me) may directly modify the value of balance Now the instance of my class is out of sync with the table. This is a bug. Oh, I'll find the bug eventually - but if balance was private, the compiler would tell me long before run-time.
回答3:
Using access modifiers correctly really aids the simplicity of your codebase - and its upkeep - as much as code security, which seems to be your concern.
回答4:
The main reason I can think of would be if you need to perform some checking or other logic when you access variables. This code which you'd normally put into a get or set method would then be by-passable by any developers who make use of the code in the future, but who don't necessarily know the code as well as you?
Also you are making assumptions about the use of the code for which you may not be able to guarantee.
Making the code modular and reusable is always a good goal to aim for, and making everything public could restrict where this code is used?
回答5:
The word you should look up is "encapsulation". You want to keep the innards of your code private so that other code doesn't depend on how you implemented it.
回答6:
I assume you are talking about public members in object-oriented programming.
If your apps are small and self-contained, then this probably won't pose much problem. Keep in mind that some things that start small balloon into huge monsters.
For anything of substantial size, the reason to avoid it is that it breaks the object-oriented principles of encapsulation and information hiding. These are important for future maintainability. It is best to keep the interfaces between modules clean and limited. That way you can change the internal implementation without also affecting dozens of dependent modules.
来源：https://stackoverflow.com/questions/9115266/internal-applications-why-not-make-everything-public