Encapsulation and unauthorized access

I have just read an article on encapsulation on wikipedia:

It says:

"Encapsulation is to hide the variables or something inside a class, preventing unauthorized parties to use."

What it meant by unauthorized..? I assume this does not mean hackers!!
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

evilrixSenior Software Engineer (Avast)Commented:
It means, if you as the programmer don't want anything external to your class modifying the internals of your class you make it private. In this way, anything you've not given explicit access (for example, by making it a friend of your class) will be denied access -- since you've not authorised that access.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
Mr_ShawAuthor Commented:
sorry.. can you define externals?
evilrixSenior Software Engineer (Avast)Commented:
Anything that is not part of your class. ie. another class.
Amazon Web Services

Are you thinking about creating an Amazon Web Services account for your business? Not sure where to start? In this course you’ll get an overview of the history of AWS and take a tour of their user interface.

kaufmed 👽Commented:
Disregarding safety deposit boxes, think of a bank. Does a bank just let you waltz in and change the amount of money it has in the vault at any time that pleases you? No. In order to have an effect on the amount of money a bank has in its vault you must either make a withdrawal or deposit via one of the bank's tellers. The teller is the interface between you and the bank's vault. The bank's vault is private to the bank; the tellers are public. You and I aren't permitted to interface with the vault directly, but those people who work for the bank are. In this way, the bank's vault is encapsulated by the bank--only those people authorized by the bank (employees) can interact directly with the vault.
kaufmed 👽Commented:

In my example the vault is encapsulated because only those entities which are a part of the bank itself (the employees) are permitted to access the vault. If we had, say, a security company who was given direct access to the vault and which transported some of the bank's assets to the main branch, then the vault would no longer have encapsulation because an external entity (the security company) would have direct access to a private member (the vault). If instead the bank manager was tasked with carrying the assets from the vault to the security company who was waiting at the front door, then you would again have encapsulation because the bank manager (a member of the bank) is the entity who is interfacing with the vault directly.
Here is excellent link, explanation

reason for encapsulation is to protect your class against accidental or willful stupidity. A class often contains a number of interdependent fields that must be in a consistent state. If you allow a programmer (including yourself) to manipulate those fields directly, he may change one field without changing important related fields, thus leaving the class in an inconsistent state. If, instead, he has to call a method to change the field, that method can be sure to do everything necessary to keep the state consistent. Similarly, if a class defines certain methods for internal use only, hiding these methods prevents users of the class from calling them.

Here's another way to think about encapsulation: when all the data for a class is hidden, the methods define the only possible operations that can be performed on objects of that class. Once you have carefully tested and debugged your methods, you can be confident that the class will work as expected. On the other hand, if all the fields of the class can be directly manipulated, the number of possibilities you have to test becomes unmanageable.

There are other reasons to hide fields and methods of a class, as well:

    Internal fields and methods that are visible outside the class just clutter up the API. Keeping visible fields to a minimum keeps your class tidy and therefore easier to use and understand.

    If a field or method is visible to the users of your class, you have to document it. Save yourself time and effort by hiding it instead.

3.5.1. Access Control

All the fields and methods of a class can always be used within the body of the class itself. Java defines access control rules that restrict members of a class from being used outside the class. In an number of examples in this chapter, you've seen the public modifier used in field and method declarations. This public keyword, along with protected and private, are accesscontrolmodifiers ; they specify the access rules for the field or method.

Sharon SethCommented:
Externals is simply something that is not part of the class . It would mean the clients of that class . Clients of a class can be code that initializes the class , or subclasses that extend the class , or any code that uses this class.

When you say security , the direction of our mind always goes towards something like hackers . But , security does not always mean this . Why do we need security for a class - obviously so that no outsider can modify the state . The other main reason is , you do not want an outsider to depend on the internals of your class. If he does that , your freedom to modify the internals of your class later on becomes impossible , and if possible it would break tens of hundereds of outsiders using your class. That's why it is said , always use inheritance with discretion
evilrixSenior Software Engineer (Avast)Commented:
>> Externals is simply something that is not part of the class
Did I not already say that?
encapsulation is not a technical means to prevent from access but is a major principle of object-oriented design. i also don't think that the designer's will is the main criteria behind encapsulation but that simply all parts of the class that are not necessary to be known for use of the class are a matter of encapsulation. as better encapsulation was done as better you could gain advantage of the main goal of encapsulation, that is to make implementation independent of the interface. take a string class as sample. it is not necessary to know whether the class has one internal char buffer or two or has a pointer to a reference count object instead of a buffer. it also doesn't matter whether the internal string is zero terminated or not, so all that stuff could be encapsulated.

note, encapsulation not necessarily requires to hide the details. in c/c++ you have header files which do reveal all members including private members of a class. when using template classes all implementation must be available at compile time for instantiation purposes. even if full sourcecode to such a class was available, it neverthelss could be well encapsulated if the interface of the class was fully independent from those private things.

>> preventing unauthorized parties to use

is misleading IMHO, it makes more sense to say "preventing un-intended access."

Authorization gives a different taste to the principle and confuses a lot hence the question regarding hackers.

Un-intended means that in order to make sure that your code/class is used the way you ** intend ** it to be, you hide (when possible) everything other than the intended methods/data/interface.

This is a best intention effort and does not prevent people from trying to use your class in unintended ways.

The concept of public interface and encapsulation are so related (even though slightly different) that sometimes you encapsulate not just for the sake of hiding but also because you want to keep a consistent public interface while planning ahead for future modifications. In other words, also hiding a potential change. The best example is

private: int m_Id;
public: void setId(int id) {
     m_Id = id;

One can argue whether that is really hiding anything, because m_Id had better be public and it wouldn't have made much difference - other than syntactic beauty.

But, still, this is better than a public variable because:

- the intention is clearly communicated.
- in future

public: void setId(int id) {
     if(id < 100)
          m_Id = id;

would be possible without having to modify all callsites.
Mr_ShawAuthor Commented:
evilrixSenior Software Engineer (Avast)Commented:
My recommendation would be:


As I think each of these comments brings a new way of looking at what encapsulation means.

Whilst additional comments were most definitely useful I believe my original comment addressed the askers initial question directly whilst the other 2 comments provided reasonable abstract ways of understanding why one might make members private/protected vs. public.
i think the original comment of evilrix http:#a37709616 is not a correct answer cause it tells the developer could decide whether to use it or not while actually it is a principle.
kaufmed 👽Commented:
A person can choose whether or not to follow either her own or other people's principles  = )

There's nothing in the language (or any language, AFAIK) which enforces the idea that one must use encapsulation. I can create getters and setters all day, but in addition I can also mark all of my member variables as public, thereby defeating encapsulation.
evilrixSenior Software Engineer (Avast)Commented:

The question was: "What it meant by unauthorized..?".

And I answered: "It means, if you as the programmer don't want anything external to your class modifying the internals of your class you make it private. In this way, anything you've not given explicit access (for example, by making it a friend of your class) will be denied access -- since you've not authorised that access".

Whether you believe encapsulation to be a language feature or a principle is really neither here not there. Firstly, that's just your opinion and secondly it's largely irrelevant to the question because the asker just wanted to know what was meant by "unauthorized" access. The question was not about the specific details of what encapsulation means or how it is implemented at a language level.

Further, Sara, you seem to be confusing encapsulation with information hiding. They are not the same thing. Encapsulation is a mechanism to define an access boundary whereas information hiding is a mechanism to hide the implementation details. Whilst encapsulation might be used as a mechanism to facilitate information hiding it is not the same thing. A good example of information hiding is the pimpl idiom.

For this reason I stand by my original recommendation and would further like to suggest that Sara actually read the question and understand the question before posting unrelated and unnecessary commentary and then criticizing the responses of those who actually did bother to take the time to read the question and answer it directly.
i read the whole article of encapsulation at wikipedia following the link the questioner gave and the word 'unauthorized' didn't occur in the article (anymore). if it was used before the term was questionable in my opinion and any speculation what could have been meant therefore is questionable as well.
evilrixSenior Software Engineer (Avast)Commented:
That doesn't really matter. The fact is the asker wanted an interpretation of what it meant and that is what was given. At no point was there a request to explain whether that was a language feature or a principle. As I said before, other comments were most likely helpful but the comments I've recommended directly address the original question (or add some value to previous comments that do). That is the only criteria for which a recommendation should be made and so that is what I've done. This is the same criteria used by Cleanup Voluneteers, Zone Advisors and Moderators and it is the only one that really matters.
kaufmed 👽Commented:
I'm probably just trolling now, but...

Under General Definition
Encapsulation is to hide the variables or something inside a class, preventing unauthorized parties to use.
evilrixSenior Software Engineer (Avast)Commented:
>> the word 'unauthorized' didn't occur in the article


"In general, Encapsulation is one of the 4 fundamentals of OOP (Object Oriented Programming). Encapsulation is to hide the variables or something inside a class, preventing unauthorized parties to use. So the public methods like getter and setter access it and the other classes call these methods for accessing."
evilrixSenior Software Engineer (Avast)Commented:
Heh :)
evilrixSenior Software Engineer (Avast)Commented:
FWIW: I don't agree with that definition either but as I said before, that isn't what the question was about so it's a moot point.
thanks kaufmed for finding the text. i don't know why my own search failed.

if we don't agree with that definition it probably would be better to explain why rather than adding right to wrong.
evilrixSenior Software Engineer (Avast)Commented:
Like I said, it's a moot point because that is not what the question asked about. I'm quite happy to elaborate on my thoughts regarding why I don't like the wording used in Wikipedia but that is irrespective of my recommendation for closure and as such my original recommendation still stands.
Paul Rogers - one of the authors listed in the reference list of the wikipedia article - made the following definitions:

Encapsulation is a language construct that facilitates the bundling of data with the methods operating on that data. Information hiding is a design principle that strives to shield client classes from the internal workings of a class. Encapsulation facilitates, but does not guarantee, information hiding. Smearing the two into one concept prevents a clear understanding of either.

there is nothing about authorized access when Rogers was talking about encapsulation. the expression ' to shield client classes'  in the definition of 'information hiding' seems  more likely to cover the 'preventing unauthorized parties to use' though both 'unauthorized' and 'parties' are at least unexpected terms. but in the explanations Rogers made for 'information hiding', he sets the focus on not exposing internal data decisions of a class for example by consequent use of getters and setters. the goal is to be able to change the decisions later and let the (public) clients interface unchanged and not to forbid access for authorization reasons.

as conclusion, i have no idea what was meant by 'preventing unauthorized parties to use' in the general definition of OOP encapsulation. and i have doubts that they meant private, protected and public access of class members or c++ friend classes. in my opinion it is a technical point that i would put to 'information hiding' rather than to 'encapsulation'.
evilrixSenior Software Engineer (Avast)Commented:
Sara, I'm not going to argue with you about this any more. You're trying to warp this question into something that it wasn't.

The wikipedia article is a general discussion of "encapsulation" and, as such, is not using language specific phrases or descriptions. You and I both know that the only way to prevent "unauthorised access" to members of a class, in C++, is to use the protected or private access specifiers. This is the only method recognised and enforced by the compiler. If we look at the C++ specific definition of encapsulation on Wikipedia we see that it does explicitly discuss using access specifiers.


"Encapsulation is the hiding of information in order to ensure that data structures and operators are used as intended and to make the usage model more obvious to the developer. C++ provides the ability to define classes and functions as its primary encapsulation mechanisms. Within a class, members can be declared as either public, protected, or private in order to explicitly enforce encapsulation. A public member of the class is accessible to any function. A private member is accessible only to functions that are members of that class and to functions and classes explicitly granted access permission by the class ("friends"). A protected member is accessible to members of classes that inherit from the class in addition to the class itself and any friends.

The OO principle is that all of the functions (and only the functions) that access the internal representation of a type should be encapsulated within the type definition. C++ supports this (via member functions and friend functions), but does not enforce it: the programmer can declare parts or all of the representation of a type to be public, and is allowed to make public entities that are not part of the representation of the type. Therefore, C++ supports not just OO programming, but other weaker decomposition paradigms, like modular programming.

It is generally considered good practice to make all data private or protected, and to make public only those functions that are part of a minimal interface for users of the class. This can hide the details of data implementation, allowing the designer to later fundamentally change the implementation without changing the interface in any way."

I still don't fully agree with this definition from an abstract sense but I do agree that the C++ mechanism for enforcing encapsulation is via the access specifiers.

Since I am now just repeating myself (and, likewise so are you) I see little point in discussing this any further here. Feel free to ask your own question regarding this and I'll be happy to contribute.
as the question was reopened and the questioner's decision is going to get overruled, i think the discussion was necessary. now noone could say the new decision was made casually.

i like Rogers' viewpoint that encapsulation and information hiding is not the same, but i agree that this wasn't asked. i am happy that you found in your last comment a consistent reasoning to remove my doubts whether the given recommendations could serve as a solution to the original question or not.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today

From novice to tech pro — start learning today.