Abstraction: Hiding Detail Behind an Interface

You drive a car by using the wheel, the pedals, and the gear shift. You never need to know how fuel ignites inside the engine. That's abstraction: a simple interface sits between you and a complicated mechanism, and the interface is all you need. In code, abstraction works the same way. A class decides what the outside world is allowed to touch, and it hides everything else.

Mechanically, this happens in two places. First, a class hides its data: fields marked private cannot be read or changed directly by outside code. Instead, the class exposes methods, like getters and setters, that control access on its own terms. Second, procedural abstraction hides steps behind a method name. When you call Math.√x, you are not thinking about the algorithm that estimates square roots. The method signature, what it takes in and what it returns, is the whole deal you need to know to use it correctly. The twenty lines of logic that compute the answer stay out of sight, inside the method body.

Abstraction is not just shorter code. A long method called once is not abstraction just because it is tucked away; the point is that the caller does not need to know how it works, and the implementation could change completely without breaking anything that calls it. This is exactly the relationship you will build next with your own classes: private fields protect data, a constructor sets up an object's state once, and public methods form the only interface the outside world gets. String already does this for you. It stores characters internally, in a form you never see, but exposes charAt and length so you can read them one by one through a stable interface.