Please ensure that: Your code is properly formatted as code block - see the sidebar (About on mobile) for instructions You include any and all error messages in full You ask clear questions You demonstrate effort in solving your question/problem - plain posting your assignments is forbidden (and such posts will be removed) as is asking for or giving solutions. Trying to solve problems on your own is a very important skill. Also, see Learn to help yourself in the sidebar If any of the above points is not met, your post can and will be removed without further warning. Code is to be formatted as code block (old reddit: empty line before the code, each code line indented by 4 spaces, new reddit: https://i.imgur.com/EJ7tqek.png ) or linked via an external code hoster, like pastebin.com, github gist, github, bitbucket, gitlab, etc. Please, do not use triple backticks (```) as they will only render properly on new reddit, not on old reddit. Code blocks look like this: public class HelloWorld { public static void main(String[] args) { System.out.println("Hello World!"); } } You do not need to repost unless your post has been removed by a moderator. Just use the edit function of reddit to make sure your post complies with the above. If your post has remained in violation of these rules for a prolonged period of time (at least an hour), a moderator may remove it at their discretion. In this case, they will comment with an explanation on why it has been removed, and you will be required to resubmit the entire post following the proper procedures. To potential helpers Please, do not help if any of the above points are not met, rather report the post. We are trying to improve the quality of posts here. In helping people who can't be bothered to comply with the above points, you are doing the community a disservice. I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns. More on reddit.com

Encapsulation is when you make some parts of your program unable to access other parts of your program. The purpose of encapsulation is to help you (or others) safely make changes to one part of your program without damaging other parts. Programs that use encapsulation are also easier to understand. In Java, one of the main ways to use encapsulation is to create classes with private member variables. Suppose you want to make a class that represents a circle. Let's pretend that for some reason it's really important to you that the area of the circle does not need to be computed using pi*r2 each time you want to find it. You might write the Circle class like this: public class Circle { public double radius; public double area; } And then when you want to create a circle you just call new Circle() and then set circle.radius to r and circle.area to pi*r2. One problem with this is that you are forcing anyone who uses the Circle class to understand the formula for finding the area of a circle. It would be better if only Circle needed to know how to find the area. So you might change your code to this: public class Circle { public double radius; public double area; public Circle(double radius) { this.radius = radius; this.area = computeArea(radius); } public double computeArea(double radius) { return Math.PI * radius * radius; } } Now you can create a circle without worrying how to find its area. But there is still a problem: what if you want to change the radius of the circle? When you change the radius, you also need to change the area. This is something that anyone who uses the Circle class needs to remember. It would be better if they didn't have to remember this. Here is how to fix this problem: public class Circle { private double radius; private double area; public Circle(double radius) { setRadius(radius); } public double getRadius() { return this.radius; } public void setRadius(double radius) { this.radius = radius; this.area = Math.PI * radius * radius; } public double getArea() { return this.area; } } Now whenever someone wants to change the radius of the circle they call setRadius, and the area is automatically updated to match the new radius. People using Circle don't need to understand how to find the area of a circle and don't need to worry about messing anything up if they set the radius. Finally, suppose you decide that you don't want to store the area of the circle inside Circle anymore, and you just want to compute it when someone asks for the area. Then you can change the class to this: public class Circle { private double radius; public Circle(double radius) { this.radius = radius; } public double getRadius() { return this.radius; } public void setRadius(double radius) { this.radius = radius; } public double getArea() { return Math.PI * radius * radius; } } Even though you've changed the way Circle works on the inside, anyone who looks at it from the outside sees the exact same thing. So if somebody has some code that uses Circle, you can make this change and their code will still work. I hope this helps! More on reddit.com

Encapsulation in code is useful for the same reason encapsulation is useful in real life. For example, consider your microwave. Do you know how exactly your microwave works or how to modify and fix it? Unless you happen to have the related background in electric engineering and mechanical design or whatever, the answer is no, probably not. However, even though the internal workings of your microwave might be a complete mystery to you, you can still use it in a useful and meaningful way via its interface: the buttons, doors, and other features that are designed to be used by external users. Same thing for your oven, your toaster, your dishwasher, your fridge, the electrical wiring in your house... All of these things have relatively complex inner workings that are all encapsulated away to the point where somebody who's completely unfamiliar with them can still effectively use them via their interface. This is really convenient: if you just want to cook a meal, you don't need to sit down and understand how every single chunk of your kitchen works first! We run into a similar issue in large codebases. If I need to add some feature, I really don't want to have to sit down and understand everything in my codebase first -- that might involve reading hundreds of thousands of lines of code! If my collaborators were good at their job though, I wouldn't need to. In an ideal world, the codebase would consist of many components having 1) carefully hidden internal parts and 2) a carefully crafted external interface. You then would only need to understand the external interfaces, which greatly cuts down on the amount of code you need to read and understand. Of course, none of this is technically necessary, in the same way that it's not strictly speaking necessary to encapsulate stuff in your kitchen. After all, there's technically nothing stopping you from designing a kitchen which requires the chef to have an intimate understanding of every piece of machinery before they can cook anything. The reason why people actually don't do this is hopefully obvious: it'd absolutely kill productivity. (It also, incidentally, makes it hard to upgrade your kitchen. If we swap out a gas stove for an electric stove, for example, normally the chef would need to do very little re-training: the stoves have nearly identical interfaces. But if the chef needs to understand everything first, making even very tiny changes could mean the chef would need to spend a lot of time re-training. Similarly, in code, if we encapsulate components and give them clearly defined interfaces, it becomes much easier to swap one component out for another.) where should i exactly need to encapsulate the programs? You should first sit down and identify exactly what the core "components" of your program are. Normally, most smaller beginner programs start with two: one part of your program handles all input and output and another part of your program handles all of the "processing". You can then start the separating those two steps out. Have your code handle all inputs in a clear and defined way, then hand all the relevant info over to the processing code. The processing code returns the final result, again in a clear and defined way, back over to the output-handling code. Usually, you can do this by having your processing code live in a separate function or object. (And heyo, if you decide to ever change how you get user input/display results, it's easy to make that swap now without disturbing the processing code.) As the core of your code gets more and more complex, you start creating more and more distinct "components". You realize "hey, this chunk of code is mostly responsible for doing X, and this one is mostly responsible for doing Y. Maybe I should split those two things up so that the code responsible for doing X and the code responsible for doing Y aren't intermingling in a messy way". You make that split, figure out how to make the two parts communicate in a clean and sane way, and bam, you have two objects or functions or whatever that encapsulate responsibility X and Y respectively with an interface that supports just the bare minimum to let the two communicate/transfer info. More on reddit.com

You can find examples of it even in Android designs, it's just the apps tend to be simpler so class encapsulation is less emphasized. Most of the design principals are less "required" in smaller applications. The principles don't lose their importance per se, you just don't suffer the same degree of consequences if you skip them. The larger a system gets the more important it is that you followed the fundamentals from the beginning.

Encapsulation is a set of implementation specifics over a broader concept.

The main concept is this: don't give outside users of a "thing" (class, method, whatever) access to, control of, or knowledge of the internals of said thing. They should know or have the minimum they need to do their job and find the "thing" useful. (In security the phrase is "principal of least privilege" and while it is different, it follows pretty close logically.)

If I am designing a class, I don't want the outside world (consumer of the class in this context) to know about or have access to my internals, such as:

• memory -> I can't control my data if I give them access to it

• adherence to SRP -> (Single Responsibility Principal) - By exposing as little as possible, a small "contract", the object can more easily adhere to SRP. This one is a bit off topic but valuable in class design.

• implementation details -> I want the abstraction that the class represents to not "leak" its internal implementation details - if I use an array versus some kind of list for storage I don't want the consumer of the class to know about it, instead I expose to them a generic "collection", preferably through an interface. How I store and access the data is my business, how you use what I expose to you is yours.

These design principals are important for a lot of reasons, but to me the most important is the simple fact that things change. The requirements of the system as a whole will change over time and as a result refactoring, extension, and/or modification will be required. The better design a system has, the easier it will be to change and adapt the software to the new conditions. If my abstractions are leaky then when I change the internals of that class I'll also have to go and change all of the consumers of that class. (Not ideal and sometimes that choice will land outside of your control and therefore make it impractical or even impossible to change.)

With respect to security, it follows along the same logic. By not giving them access to my internals I am in control of the changes in state. If I am in control then they can't "hurt" me. Basic GIGO (garbage in, garbage out) -> never trust your user, even when your user may be another developer, even when that other developer may be you.

More on reddit.com