Java OOP - Object-Oriented Programming Tutorials

What OOP Is (in Plain Terms)

Before learning the syntax, you need to understand the idea. Here's the core shift in thinking:

Without OOP: "What should the program do next?"

You write a sequence of instructions. "Read this file, parse each line, put it in a list, sort the list, write it out." The data and the logic that operates on it live in separate, disconnected pieces. The program is a recipe.

With OOP: "What things exist, and what can they do?"

You define types of things — Employee, Order, Account — each with their own data (fields) and their own behavior (methods). An Employee knows how to calculate its salary and update its department. The program is a world of interacting objects.

The practical difference: when your program has 50,000 lines of code, the OOP approach means you can find "all the code related to employees" in one place (the Employee class) instead of scattered across 30 different methods. That's the entire point.

4

Core OOP
principles

2

Tutorials in
this section

~40m

Total reading
time (approx.)

The Four Pillars (and Where We Cover Them)

Principle	What It Means	Where It's Covered
Encapsulation	Hide internal details behind a public interface. Objects manage their own state — outside code can't directly modify their fields.	Classes and Objects — `private` fields with `public` getters/setters
Abstraction	Show only what's needed, hide implementation details. Call `employee.calculateBonus()` without knowing the formula.	Classes and Objects — methods as the public interface; Inheritance — overriding methods to change behavior
Inheritance	Create new types that specialize existing ones. `Manager` extends `Employee` and adds its own behavior.	Inheritance — the full tutorial
Polymorphism	Treat different types of objects the same way. Call `shape.draw()` and each shape (circle, square) draws itself differently.	Introduced implicitly in Inheritance (method overriding). Fully developed when you reach Collections (lists of different types via interfaces) and Spring (dependency injection).

Don't Overthink the Pillars

The four principles are useful vocabulary for talking about design decisions, but they're not four separate things you "learn" one at a time. They emerge naturally from writing classes well. If your fields are private and your methods do one clear thing, you're already practicing encapsulation and abstraction. The tutorials focus on the mechanics (how to write a class, how to use extends) because that's what you need to get started.

Before You Start

You should complete the Java Basics section first — specifically:

Variables — You'll use fields (which are variables) inside classes. You need to understand types, final, and scope.
Methods — Classes are primarily containers for methods. You need to understand parameters, return values, and overloading.
Exception Handling — The Spring Boot tutorial and real applications use exceptions heavily. You should understand try-catch and throws.

You do not need to have memorized every detail of those tutorials. If you can write a method that takes parameters, returns a value, and throws an exception when something goes wrong, you're ready for OOP.

Tutorials — Study in This Order

Tutorial 1 of 2 Beginner · ~20 min

Classes and Objects

How to define a class with fields and methods, create objects from that class using new, use constructors to initialize objects, understand the this keyword, and apply encapsulation with private fields and public getters/setters. This is the single most important tutorial in the entire site — everything after it assumes you understand classes.

Why first: Every subsequent tutorial defines classes. The Collections tutorials use class types (ArrayList, HashMap). JDBC uses entity classes. Spring Boot is built entirely around classes and annotations. You need this foundation before anything else makes sense.

Start tutorial →

Tutorial 2 of 2 Intermediate · ~20 min

Inheritance

How to create class hierarchies with extends, override methods from a parent class, call the parent's version with super, and understand when inheritance is the right tool versus when composition or interfaces would be better. Includes a candid discussion of inheritance's limitations.

Why second: Inheritance depends on understanding classes thoroughly. You also need to have seen method overloading (from the Methods tutorial) to distinguish it from method overriding, which is a common point of confusion.

Start tutorial →

After Completing These Tutorials

Design classes from scratch

Identify what fields and methods a class needs, write the class definition, and create working objects.

Encapsulate state safely

Make fields private, expose only what's needed through methods, and prevent invalid object states.

Create class hierarchies

Use inheritance to share common code between related types and override behavior where it differs.

Read real Java codebases

Understand class definitions you'll encounter in every Java library, framework, and codebase you work with.

What's Not Covered Here (and Where to Find It)

OOP is a large topic. These tutorials cover the mechanics thoroughly but intentionally defer some concepts to where they're most useful in practice:

Interfaces and abstract classes

Interfaces and abstract classes are how Java achieves polymorphism without inheritance. They're important, but they only make sense after you've written concrete classes and seen inheritance's limitations. You'll encounter them naturally in the Collections tutorials (every collection type is an interface) and the Spring Boot tutorial (dependency injection uses interfaces extensively). A standalone "interfaces tutorial" that doesn't connect to a real use case would be abstract and forgettable.

Composition over inheritance

The Inheritance tutorial explicitly discusses this principle and shows an example of refactoring an inheritance hierarchy to use composition instead. But the full treatment — when to prefer an interface, when to use a class, how to design with composition from the start — is a design skill that develops with experience, not from reading about it. The tutorial gives you the mental model; practice in projects gives you the judgment.

Access modifiers (public, protected, private, package-private)

private and public are covered in the Classes tutorial because they're needed for encapsulation. protected is explained in the Inheritance tutorial in the context of parent-child class relationships. Package-private (no modifier) is not given its own section because it's the default — you're already using it in every tutorial without knowing the name. All four are summarized in the Java Keywords reference page.

Design patterns (Singleton, Factory, Observer, etc.)

Design patterns are solutions to recurring design problems. Before you've encountered the problems, the patterns are meaningless names. Learn to write classes and use inheritance first. When you find yourself writing the same structural solution for the third time, that's when the pattern clicks. The patterns you'll use most in Java (Strategy, Builder, Dependency Injection) are introduced naturally in the Spring tutorials, not in isolation.

Object-oriented analysis and design (UML diagrams, use cases)

UML diagrams and formal design documents belong to team projects with specific processes. For learning, they add overhead without adding understanding. You'll learn more by writing and refactoring a class in code than by drawing boxes and arrows for it. When you join a team that uses these tools, you'll pick them up in an afternoon — the underlying OOP concepts are what take time to learn.

Common Misconceptions About OOP in Java

"Everything should be an object"

Java has primitive types (int, double, boolean) that are not objects. This is a deliberate design choice for performance — wrapping every number in an object would make Java unusably slow for numerical computing. Use primitives for simple values, objects for complex state. The Variables tutorial covers when to use each.

"Inheritance means 'is-a' — always"

The classic textbook example says "a Car is-a Vehicle, so Car extends Vehicle." This works for shallow examples but breaks down in real systems. A SortedArrayList is-a ArrayList in Java, but inheriting from ArrayList to add sorting is a well-known anti-pattern (it breaks the List contract). The Inheritance tutorial covers this pitfall and shows when composition is the better choice.

"More classes = better design"

Creating a separate class for every concept leads to over-engineering: a FirstNameValidator class, a EmailFormatter class, a SalaryCalculator class, each with one method. If a class has only one method and no state, it should probably just be a method on a related class. Good OOP means grouping related state and behavior, not splitting everything into its own file.

Java Object-Oriented Programming