# Object-oriented programming

Perl has two object systems living side by side: the **modern
`class`/`field`/`method`** syntax introduced in 5.38 (codename
*Corinna*), and the **classical `bless`/`@ISA`** model that predates
it by three decades. pperl supports both, and both appear in real
code you will read and maintain.

The short version:

- For **new code**, use [`class`](../../p5/core/perlfunc/class). The
  syntax is first-class, the constructor is generated for you,
  fields are genuinely private, and single inheritance has a clean
  declarative form.
- For **legacy code**, understand `bless`, `@ISA`, and the
  `$self = shift` convention. You will meet them in every
  pre-5.38 codebase, every mainline CPAN distribution, and much of
  core Perl itself.
- **Moose, Moo, Class::Accessor, Object::Pad** are the CPAN
  ecosystems that papered over the classical model's rough edges
  while the core feature was still being designed. They are a
  historical chapter; new code reaches for core `class` instead.

This how-to tree covers both systems end-to-end. Read the chapters
in order on a first pass, or jump to the one that matches the code
in front of you.

## Which chapter you want

- [Modern classes](classes) — `class`, `field`, `method`, `ADJUST`,
  `:param`, `:reader`. The recommended way to write OO in pperl.
- [Classical OO](classical) — `bless`, `@ISA`, `sub new`, accessors
  by hand, `SUPER::`. The model you will maintain in existing code.
- [Inheritance and method resolution](inheritance) — how method
  lookup works, `isa`, `can`, `DOES`, MRO, and the pitfalls of
  multiple inheritance.
- [Roles and delegation](roles-and-delegation) — composition
  patterns for behaviour shared across unrelated classes.
- [Migrating from classical to modern](migrating) — a mechanical
  recipe for converting a `bless`-based class to the `class`
  feature, and the places where the translation is not mechanical.

## When to use OO at all

OO is a tool, not a style. Reach for it when:

- The problem has a small vocabulary of nouns (user, session,
  request, record) and a larger vocabulary of verbs acting on each.
- A piece of data carries invariants that should be enforced at
  one point in the code, not at every call site.
- You expect the implementation behind a set of operations to
  change while the operations themselves stay stable.
- You are modelling a category with variants and want polymorphism
  to pick the right behaviour.

Do not reach for OO when:

- The program is small, linear, and has no reusable nouns.
- A plain hash of hashes or a closure is enough.
- The only reason to write a class is "it felt more professional."
  A twelve-line script does not need a class.

## A note on scope

This tree is a tutorial, not a reference. The exhaustive syntax
tables live in the per-keyword reference pages:

- [`class`](../../p5/core/perlfunc/class)
- [`field`](../../p5/core/perlfunc/field)
- [`method`](../../p5/core/perlfunc/method)
- [`bless`](../../p5/core/perlfunc/bless)
- [`ref`](../../p5/core/perlfunc/ref)
- [`isa`](../../p5/core/perlfunc/isa)

Link into them whenever you need the full signature surface; this
tree gives you the working-programmer overview.

```{toctree}
:maxdepth: 1
:hidden:

classes
classical
inheritance
roles-and-delegation
migrating
```