OOPS is just a method, Not having advantages

[Ketan022]

I feel that following is the conclusion in C++ coding related to Class and access specifiers.
We know that we are hiding the data by making private or protected. But there are ways to access it.
The one who does not know how to access it will be confused but that really does not mean that we are restricting user to access it accidently.
The one who knows it will be accessing it and modify it.
So, OOPS is advantages in coding itself that beginner can’t modify the data.
So, is it not like that programmer has prepared logic in detail thinking that unknown user can’t access it?
But what if unknown coder is smart enough to change hidden data of class? Please take into consider that Smart coder I am referring to is the coder who does not willing to change unnecessary data willingly but he may feel to change it and as he is able, he is change it.
I am not sure how OOPs helps in this scenario. To conclude with, is not OOPs a simple agreed process we are following which may or may not help to protect data? 

[ddanbe]

Private or protected in OOP has nothing to do with security and hiding secret data.
Read this thoroughly.

[deceptikon]

But what if unknown coder is smart enough to change hidden data of class?

Then unknown coder will be breaking the contract and if the hidden data of the class ever changes, will suffer the consequences of not strictly using the public interface provided by the class author. I see no issue here. It's like saying that people who know how to pick locks will be able to break into your house, and because of that, locks have no advantages.

To conclude with, is not OOPs a simple agreed process we are following which may or may not help to protect data?

As ddanbe said, data hiding is not data security. It's a strategy for hiding things the user of the class doesn't need to use the class, or for hiding implementation details that may change in future revisions of the class.

[Ketan022]

Thanks for help.

I understand this but would appreciate if someone could give real time OOP example which helped a lot during programming...

[mike_2000_17]

The one who does not know how to access it will be confused but that really does not mean that we are restricting user to access it accidently.

That's not exactly true. Private or protected data will restrict the user from accessing the data accidently. It is true that in many cases there are hack-ish ways to access private / protected data, but most of these techniques are, by nature, very deliberate. The likelihood that a careless programmer just happens to access / modify the data by accident is generally very low, and that's the point of those access rights, it's to put access to the data (or functions) outside the realm of "normal" uses of the class or objects. That's what "hiding" means, not to be confused with "protecting".

So, is it not like that programmer has prepared logic in detail thinking that unknown user can’t access it?

When we are talking about normal programming, i.e., not in the context where you are trying to implement security measures, the relationship between the library programmer (e.g., writes the class) and the library user (e.g., uses the class) is one of cooperation, not of antigonism. In other words, the library programmer wants to help the user be able to do his work as easily and safely as possible (safely, as in, without unintentional bugs). And in that context, hiding away certain details can help make it easier for the user to know what he can use safely, and what not to use. It also allows the library programmer to create an area of code that is not subject to long-term support, i.e., that is not part of the interface, and can therefore be changed in the future. It's the user's responsibility in that cooperative relationship to not rely on hidden or undocumented parts of the library, and if he does so, it is at his own risk.

You are thinking in terms of an antigonistic relationship, where the user is aiming to undermine the library. That is a completely different scenario, because normally a user is interested in using the library to his benefit, not undermine it. And if this is the case, as it might be in some malicious cases (e.g., man-in-the-middle attacks, spoofing, hooking, etc.), then the access rights or other forms of encapsulation (stronger or weaker) will not be very helpful in general, because that's not what they are designed for. In those cases, you have to use other techniques, usually involving checksums on the binaries, "signing" the binaries, and general controls on the distribution of the source code or binaries.

But what if unknown coder is smart enough to change hidden data of class?

Unless the coder is an antigonist (malicious), then a smart coder would certainly be smart enough to know that he is not supposed to change hidden data in ways that by-pass the public and documented interface of the library. In general, if a smart coder has some reasons for wanting more control on some library components, he will petition the library developers to add that functionality to the public interface (e.g., issue a "feature request"). Or select another library that provides better "control" on the implementation details. That's how many libraries develop and become better, as smart users discover things that they would like to be able to do with the library and cooperate with the library developers to add those features.

I think you have to revise your concept of "smart".

And btw, it doesn't take a particularly smart coder to be able to find ways to access private / protected data. For example, this quick and dirty trick:

#define private public
#define protected public

#include "some_class_header.h"

#undef private
#undef protected

I am not sure how OOPs helps in this scenario.

I does not.

To conclude with, is not OOPs a simple agreed process we are following which may or may not help to protect data?

Yes, it is a simple agreed process that we follow. Also, private / protected access rights is just one of many different techniques for encapsulation, which also include PImpl (Cheshire Cat / Compilation Firewall), functions and variables with internal linkage or no-linkage, un-named namespaces or "detail" namespaces, selective documentation, limiting specified behavior, etc..

And overall, the objective is not "protection" from an antigonist, but rather a cooperation between the library implementer and library user to protect the user from the dangers of using external code without full knowledge and understanding of its implementation details. So, really, encapsulation protects the user, not the data, and the user would be a fool not to take advantage that protection, i.e., not smart.