I’ve been learning C# over the past while, and as a result, I’ve been learning a lot about Object Oriented Programming concepts. I have a rather good understanding of classes and inheritance and am about to learn about polymorphism, but one concept I currently can’t wrap my head around is encapsulation. I just can’t understand what it does or why it’s even used in any sense. Any help would be appreciated, because I’d rather move forward having a good understanding of every c# concept I’ve touched on so far before moving on to new things.
In: Other
Encapsulation — literally “putting something in a capsule”. The concept of putting all sorts of complicated and messy innards into a pretty box with easy controls on the exterior.
Think of say, a car. Driving it may cause all sorts of complicated interactions, down to very subtle adjustments to engine timing or other engine management. But you don’t have to be concerned about that because you have a simple interface to interact with, such as a gas pedal. What the pedal does behind the scenes isn’t something you should worry about.
So encapsulation is simply the idea that `car.accelerate()` can internally be 30000 lines of code, and none of that concerns the user of the Car class. It’s all hidden from them.
Encapsulation means designing a simple interface to hide the underlying complexity of a system. Think of encapsulation like a post on this subreddit. You take something complex and make it more simple so it’s easier to understand, and digest.
The main reason we bother with it is so that you can do 3 things.
* More easily understand (or control) the system you have encapsulated
* Build interesting stuff on top of that system without much effort
* Replace encapsulated components with different components as long as they use the same simple interface or encapsulation.
A city has a water and sewer system that winds its way through that city under the ground. It has inflows of water, reservoirs, pressure controls. There is a billing system and customers and people who control the quality and everything. But at your home there is simply a main water line (input), a water meter, and a main sewer line (output). All that complexity is simplified and standardized so that every plumber can think of a house in those simpler terms. A plumber does not need to know the full workings of one particular city’s water system in depth to work on a house. That leaves more room in their heads to think about the best way to lay out pipes in a home and it also allows their skills to work across the country in different cities.
So then the plumber lays the pipes for a house and builds it all to code. He does this on top of the simple encapsulation of the water main, the water meter, and the sewer line. But the plumber also uses encapsulation for all the pipes he has laid in the home. The faucets and showers and toilets are the simple interface for the home’s plumbing network. And the residents of the home use this simple interface.
But some houses are in cities that don’t have sewer systems. In that case, you can install a septic tank and connect it to the main sewer line of a home. They both use the same simple interface and therefore thanks to encapsulation you can interchange them. Same goes for the water main. If you had a well, a water pump and some filters/purifiers, you could hook that into your water main line for water input.
Wow I really learned encapsulation differently. Encapsulation is actually a very simple principle: limit access to data from the outside world and gather together related parts of a program together in one place, a class.
The first principle makes you think about the data a class will need to operate. The immediate data you need should be closed off from the outside world modifying it at will but allow access to it through the proper use of things like constructors, getters, and setters. Data fields in a class should generally be private as well and access to them are through the 3 methods mentioned above. You really don’t have many global variables in a in an OOP program. If you find the need for globals, they get encapsulated in a class instead of floating around the entire program.
The second principle speaks to the methods a class implements. A User class might implement methods to log a user in, fetch the parts of a system they can interact with, log a user out and so on. These methods are gathered together in one place because they will operate on the same data and placing them in the same class is a logical solution to organize your code.
To me, encapsulation doesn’t necessarily state that methods are there to abstract away implementation details of complex systems. You could write a .cpp with a myriad of complex functions and claim encapsulation because the user just has to call a function to perform a complex operation. There are patterns you can follow that help to abstract away complexity if that’s your aim.
Think of an object as a black box with a clearly defined interface on the outside. You don’t need to know what’s in the box to use it. For a large program, fitting together many black boxes is much less confusing than trying to build one enormous box.
Less confusing and also easier to make changes. If you open up a box and start changing the contents, you can be confident that you won’t break the program so long as you don’t change the interface. And adding new functionality is just a matter of figuring out what kind of box you’ll need and where to put it.
Latest Answers