What's the disadvantages or weakness if we don't use encapsulation (OOP)?

Question

My focus topic in here is encapsulation in Object Oriented Programming not Networking/OSI Model.
https://en.wikipedia.org/wiki/Encapsulation_(computer_programming)

Please give a weakness sample (or exploitation sample/demo),
real sample in programming/computer science not merely using assumption.

When we should use "private"?
What's the disadvantage if we don't use "private" when we should use "private"?

Also,
Is there any weakness from "computer & network security" point of view?

Additional information:
encryption and encapsulation is different.
My focus topic in here is encapsulation.

Answer 1

If a lot of different variables are all dependent on a specific variable that should have a value between 1 and 10, and are used throughout a code, but someone decides to change the variable to 11, the code will probably produce an error when it goes to check the value. Since the values are outside of the specified range, the code will probably fail during the execution.

Answer 2

@Gordie
True.

Answer 3

thanks ace

Answer 4

@Ady PRTM
"Special currency" is my term for the type of game currency (esp. for mobile games) that is harder to acquire, and is usually acquired by purchase.

I believe that private is an access modifier used to set the access restriction of a method or variable to only within the current class. If an outside method or class wanted to access it, the outer class would need to use Getters and Setters. However, it may be possible to use an object of the class to get the variable.

Answer 5

Hello, Adi.

From my understanding, Encapsulation makes a variable only accessible through a specific method or function (from a Java perspective). It is similar to the brain, in the sense that a person can't read your thoughts, but you can tell them about your thought if they ask. It can also be used if multiple methods need access to a variable, similar to Global Variables in JavaScript.

One possible disadvantage of not using Encapsulation relates to the game design field. If your game uses a hard-to-get "special" currency, it would be helpful to store the value in a different class so that if the user opens the main class's source code, they have to find the variable in a different class instead of just changing one variable (just add 10 zeroes).

Hope this helps (sorry that the response was long).

Answer 6

public class PrivateString{
private String toStore="Only available to class";
public static String getString(){
return toStore;
}
}

/* In another class, the string "a" needs to be assigned the value of the one above. However, since it is private it can only be accessed through the method getString.*/

This can be helpful if you don't want to statically reference a variable, or if you use another method in the class above that changes the variable before returning it. If the variable only applies to the current class, contains important or sensitive values, or both, using private and returning the value after using a method may be a good way to go.

Hope this helps.

*Edit: Keeping a hashed password private in a separate class would also be useful so that it wouldn't be explicitly written in the main class for all to see.*

Answer 7

@Ady PRTM
A variable that might cause a fatal error in the code's execution if tampered with should probably be kept private in a separate class.

Also, sorry for forgetting about the password example. I put an edit in my last post.

Answer 8

@Ady
Hi. If you'll give me a bit of time, I can come up with a code to represent a "fatal error."

Answer 9

@Ady
Depends. In the "fatal error" example, you would crash the program. In the "Special currency" example, you could get more of the "special" game currency. If it's a password program, you could change the password to anything that you would like. There's a lot that you could probably do.

Answer 10

@Ady
If you had a Java-based Antivirus, for example, and someone were to tamper with a variable that would cause a chain-reaction failure that would ultimately end in the Antivirus crashing, and leaving the computer/network vulnerable to intrusion. From one computer, the intruder could take another computer on the network, and so forth (called daisy-chaining).

Answer 11

@Ady
The program's finished. While it doesn't make use of a private variable, it is probably the simplest example of an execution-terminating error.

https://code.sololearn.com/c8t0BiRLip3m/?ref=app

Answer 12

@Ady
Thank you.
If you don't mind, I'm going to be woodworking, so later on, I'll give an example of a variable that should be private.

Answer 13

@Ady
Thanks.

Answer 14

@Ady
Hi. I'm back.
An example of a variable that should probably be kept private is, for say, the score of a game (such as a Black Jack program), or a password in a program to protect files.
In the Fatal Error program, the arrLength variable does not have to be private. It's simply used as an example of an error that would stop a program from running. The variable that starts the chain reaction is such a simple part of the program that it would be almost unavoidable to put it in the main class/method, so, unless it was a program of high importance, making a variable like that private and in another class might be overkill. Good question, though.

Answer 15

@Gordie
You have a point. Most bank accounts, however, run on Servers (as far as I know), so you can't simply access variables like you could on a native or local application. Plus, I don't think that ATMs are equipped to change variables, or serve as an access terminal. Native or local applications, however, are based within the computer, so the source code is there. I've seen "decompiler" applications in the Play Store (granted, I'm not sure how credible these are), so if one could find a program like this for a PC, they would be able to alter the source code of different native or local applications.
On the public/private subject, it's a lot harder to go searching for a variable in a different class than to just find it in the main class. This not only helps to improve security from malicious code insertions, or direct edits, but also works to discourage the person tampering with the native or local application, and otherwise improve program security.

Answer 16

@Gordie
No problem.

Answer 17

@Gordie
Thanks. The code was very informative
I personally would still use private over public in some cases, but, as you have proven, private on its own is not enough to secure a program.

(Sorry for the late response, I've been a little busy)

Answer 18

Just imagine if the banking algorithm does not encrypt and encapsulate the user password and other sensitive info

Answer 19

what I ment was passwords need to be encrypted as well as encapsulated.
May be a better example of not using encapsulation would allow users to change the account balance...

may be this should help
http://www.firewall.cx/networking-topics/the-osi-model/179-osi-data-encapsulation.html

Answer 20

@Ady PRTM
Was any of this helpful?