Java OOP Concepts

Object-oriented programming (OOP) is a way of organizing code around the things in your program rather than the steps. Instead of one long script that operates on raw variables, you describe the kinds of objects in your domain — a User, an Order, a BankAccount — and give each one the data and behavior it needs. The rest of the program then asks those objects to do things, instead of poking at their internals.

Java was built around this idea. Every line of Java code you write lives inside a class, and a class is the blueprint from which objects are made. Up to this point you've been writing mostly-procedural code inside main and a few static helpers; from this part of the book onward, you start designing classes of your own.

Classes and objects in one sentence

A class describes a kind of thing — what data it holds and what it can do. An object is one specific instance of that thing.

public class Dog {
  String name;
  int age;

  void bark() {
    System.out.println(name + " says woof");
  }
}

Dog d = new Dog();   // d is an object — one specific dog
d.name = "Rex";
d.bark();            // Rex says woof

Dog is the class. d is an object. The key shift from procedural code: an object bundles state (the name and age fields) and behavior (the bark() method) into one unit. You can make as many Dog objects as you like; each gets its own copy of name and age, and each can bark() on its own. The classes & objects chapter takes this apart in detail.

The four pillars

OOP is usually taught around four ideas. Each one gets a full chapter later in this part of the book — what follows is a thirty-second tour so you know where the road leads.

Encapsulation

Keep an object's data private; expose behavior instead. Outside code asks account.deposit(50), not account.balance += 50. The benefit is that the class controls its own invariants — nobody else can put it in a bad state.

public class Account {
  private int balance;                          // hidden

  public void deposit(int amount) {             // public behavior
    if (amount <= 0) throw new IllegalArgumentException();
    balance += amount;
  }
}

See the encapsulation chapter.

Inheritance

A class can extend another, picking up its fields and methods and adding to them. Cat extends Animal reuses everything Animal already does and only specifies what's different about cats.

public class Animal {
  void breathe() { System.out.println("inhale, exhale"); }
}
public class Cat extends Animal {
  void purr()   { System.out.println("rrr"); }
}

Cat c = new Cat();
c.breathe();   // inherited
c.purr();      // own

See the inheritance chapter.

Polymorphism

The same call can do different things depending on the actual object on the receiving end. A variable of type Animal could point to a Cat, a Dog, or a Cow — calling speak() on it picks the right behavior at runtime.

Animal a = new Cat();
a.speak();   // calls Cat's speak, even though a is typed as Animal

See the polymorphism chapter.

Abstraction

Define what something does without committing to how. An interface Shape says every shape has an area() method; each concrete shape — Circle, Square — supplies its own formula. Code that works with shapes doesn't need to know what kind it has.

public interface Shape {
  double area();
}

See the abstraction chapter.

The pillars at a glance

The pillars overlap on purpose: polymorphism leans on inheritance, abstraction is enforced through encapsulation, and so on. Treat them as four angles on one idea — model your program as cooperating objects — rather than four separate features to memorize.

Why bother?

For a 20-line script, OOP is overkill. The payoff shows up as programs grow:

• Local reasoning. A BankAccount class owns its rules. To understand or change deposits, you read the deposit method — you don't grep the codebase for balance +=.
• Reuse without copy-paste. Inheritance and composition let SavingsAccount build on Account instead of duplicating it.
• Substitutability. A function that takes a Shape works for every shape that exists today and every one you add tomorrow.
• Testability. Small objects with clear responsibilities are easy to instantiate, drive, and assert against.

Java is far from the only object-oriented language — Python, C#, Kotlin, Ruby, and many others share the same ideas with different syntax. What you learn in this part transfers.

OOP is not the only paradigm

Even within Java, you've already written code that isn't strictly OO: static utility methods, primitive math, plain control flow. Modern Java mixes paradigms — functional pipelines with streams and lambdas, immutable data with records, declarative work with annotations. OOP is the spine of the language, not a cage. Use a class when modeling a thing with state and behavior; reach for a static method when you just need a calculation.

A worked example

The full code from the snippets above, put together so you can run it:

What's next

Now that you know the shape of OOP, the next chapter pins down its fundamentals: how a class definition becomes an object in memory, what new actually does, and how object references differ from primitives. Continue to Java classes and objects.

Practice