Jan Mikoláš
Glossary
Class and object
A class describes rules and capabilities. An object is a concrete instance in a running application—for example, one order, a monetary amount, or a shipment creation service.
Short definition
A class is a blueprint; an object is a specific instance.
A class groups properties, methods, constants, and visibility rules. The constructor establishes a valid initial state, while methods describe what can be done with the object. Using the new keyword creates an object, or instance of the class.
An object does not have to be a database row or ORM entity. It can represent a value, application service, request to an external API, or order state. It is useful when it keeps together data and behaviour that genuinely belong together.
Use cases
Where classes and objects give code structure
An object model helps name responsibilities and keep important rules close to the data they concern.
- an order that enforces permitted changes to its state
- a value object for money, currency, or a date interval
- an application service for importing orders or reserving inventory
- a data object for safely typed API input
- an infrastructure adapter such as a shipping provider client or repository
Practical example
An order protects its own rule
Cancelling a shipment is not merely setting a public property to true. A method can first check the order state and reject an operation that no longer makes business sense. Coordinating inventory, payment, or email, by contrast, would often belong in another application service.
PHP
final class Order
{
private bool $cancelled = false;
public function __construct(
private readonly string $number,
private readonly bool $shipped,
) {
}
public function cancel(): void
{
if ($this->shipped) {
throw new DomainException('Expedovanou objednávku nelze zrušit.');
}
$this->cancelled = true;
}
}How it works
From a definition to using an object
This simplified flow shows where responsibility for state lies and where the surrounding application begins.
- Class definition A class names its state, behaviour, and public interface.
- Instance creation The constructor receives the required data and verifies the initial conditions.
- Method call A consumer asks the object to perform an operation with a specific meaning.
- Protecting invariants The object rejects a change that would put it into an invalid state.
- Surrounding collaboration The appropriate surrounding layer handles persistence, an HTTP response, or a service call.
Important concepts
State, behaviour, and visibility have different roles.
The terms class, object, and instance are often confused, but each denotes a different part of the object model.
Class, object, and instance
Instance is another term for a specific object created from a class. The class itself is not a running order or service.
Properties and methods
Properties hold state. Methods provide behaviour and can verify or reject a state change.
Constructor and types
The constructor establishes required values. Declared parameter, property, and return types make what the object works with more precise.
Encapsulation
Private state and narrow public methods prevent arbitrary parts of the application from changing it without checks.
Inheritance and composition
Inheritance expresses a parent–child relationship. Object composition is often clearer for combining independent capabilities.
Benefits and limitations
A class should make a concrete change easier, not merely increase the file count.
Benefits
- rules are close to the state they concern
- types and public methods make the contract more precise
- an object can be tested without running the entire application
- responsibilities can be composed and named
Common mistakes
- public properties that anyone can change
- one “god class” with unrelated tasks
- mistaking a database table for the entire domain model
- a class, interface, and factory for every minor value without a reason
When it makes sense
An object is appropriate for behaviour, state, and a clear responsibility.
A class is worthwhile when data has rules, a lifecycle, or related operations. A monetary amount, order, and shipping provider client have different responsibilities, but all can be separate objects.
For a simple one-time data conversion, several layers of objects may provide no benefit. The degree of object-oriented design should match the problem’s complexity and expected changes, not the idea that everything must be a class.
What to consider
A good class has a clear reason to exist.
During design and code review, it helps to verify whether the object genuinely protects and names one related responsibility.
- keep required state and dependencies in the constructor
- name methods by meaning, not by a technical detail
- do not expose unchecked state changes through public properties
- separate the coordination of multiple systems from an object’s local rules
- test observable results and prohibited state transitions
Common questions
Classes and objects in PHP
What is the difference between a class and an object?
A class is a definition of properties and methods. An object, or instance, is a specific value created from that definition that exists in the running application.
Is a class the same as a database table?
No. An ORM can map a class to a table, but a class can also be a service, value object, DTO, or external API adapter.
Should every class be final?
Not automatically. final is useful when a class is not meant to be safely extended through inheritance. What matters more is choosing composition, inheritance, and the public contract deliberately.
Should properties be public?
This can be readable for simple immutable data objects. For mutable business state, it is usually safer to route changes through methods that verify the rules.
How I use PHP in practice
I compose classes and responsibilities according to application complexity.
In long-lived PHP applications, I combine straightforward objects with clear boundaries where they protect business rules or infrastructure.