What Is Class What Is Object - Learning Module

Loading content...

0/246

Class as a Blueprint

The Foundation of Object-Oriented Programming

Before we can design complex software systems, before we can apply design patterns, before we can reason about inheritance hierarchies or polymorphic behavior—we must first understand the most fundamental concept in object-oriented programming: the class.

A class is not merely a syntactic construct. It is a conceptual abstraction that allows us to model real-world entities, define shared behaviors, and create reusable templates for objects. Understanding what a class truly represents—and what it does not—is the first step toward mastering low-level design.

What You Will Learn

By the end of this page, you will understand what a class fundamentally represents, how it serves as a blueprint for objects, and why this distinction is crucial for every design decision you will ever make in object-oriented programming.

The Blueprint Metaphor

The most common and effective way to understand a class is through the blueprint metaphor. Consider an architect's blueprint for a house:

The blueprint specifies the structure: how many rooms, where the doors are, how the plumbing is laid out
The blueprint defines dimensions: room sizes, ceiling heights, window placements
The blueprint describes materials: what kind of flooring, wall finishes, fixtures

But here's the crucial insight: the blueprint is not a house. You cannot live in a blueprint. You cannot walk through its doors or look out its windows. The blueprint is a specification—a template from which actual houses are constructed.

The Class-Blueprint Parallel

A class, like a blueprint, defines what something will be without being that thing itself. It specifies structure (attributes), behavior (methods), and relationships (associations)—but a class alone consumes no memory for instance data and performs no actions at runtime.

Why this metaphor works:

The blueprint metaphor captures the essential nature of a class:

Separation of Definition from Existence — A blueprint exists in the abstract; houses exist in reality. A class exists at compile-time; objects exist at runtime.
One-to-Many Relationship — One blueprint can produce many houses. One class can instantiate many objects.
Consistency Through Template — All houses built from the same blueprint share the same structural characteristics. All objects created from the same class share the same attributes and methods.
Variation Within Constraints — Houses built from the same blueprint can have different paint colors, furniture, and inhabitants. Objects of the same class can have different attribute values while sharing the same structure.

Blueprint vs House — Class vs Object
Blueprint (Class)	House (Object)
Abstract specification	Concrete reality
Exists on paper/in code	Exists in the world/in memory
Defines what can exist	Represents what does exist
One blueprint	Many houses
Created by the architect (developer)	Built by the constructor (runtime)
No physical resources consumed	Consumes physical resources (memory)

What a Class Defines

A class is a formal specification that defines three fundamental aspects of the entities it represents:

1. Structure (Attributes/Fields)

Attributes define the data that each object will hold. They answer the question: What information does this type of entity need to remember?

For a BankAccount class:

accountNumber: a unique identifier
balance: the current amount of money
ownerName: who owns the account
createdAt: when the account was opened

2. Behavior (Methods)

Methods define the actions that objects can perform or have performed upon them. They answer: What can this type of entity do?

For a BankAccount class:

deposit(amount): add money to the account
withdraw(amount): remove money from the account
getBalance(): report the current balance
transfer(toAccount, amount): move money to another account

3. Invariants (Rules/Constraints)

Though not always explicit in code, classes implicitly or explicitly define rules that must always hold. They answer: What must always be true about this entity?

For a BankAccount class:

Balance must never be negative (for a checking account)
Account number must be unique
Only the owner can authorize withdrawals

BankAccount.java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
/**
 * A class definition for a bank account.
 * This is a BLUEPRINT — it defines structure and behavior,
 * but no account exists until we instantiate it.
 */
public class BankAccount {
    // STRUCTURE: Attributes define the data each account holds
    private String accountNumber;
    private double balance;
    private String ownerName;
    private LocalDateTime createdAt;
    
    // BEHAVIOR: Methods define what an account can do
    public void deposit(double amount) {
        if (amount <= 0) {
            throw new IllegalArgumentException("Deposit must be positive");
        }
        this.balance += amount;
    }
    
    public void withdraw(double amount) {
        // INVARIANT: Balance must never go negative
        if (amount > this.balance) {
            throw new InsufficientFundsException();
        }
        this.balance -= amount;
    }
    
    public double getBalance() {
        return this.balance;
    }
    
    // Transfer combines behavior with collaboration
    public void transfer(BankAccount toAccount, double amount) {
        this.withdraw(amount);
        toAccount.deposit(amount);
    }
}

The Class as Contract

Notice that the class definition is a contract. It promises that every BankAccount object will have these attributes and will respond to these methods. Code that uses a BankAccount can rely on this contract without knowing the internal implementation details.

Classes Are Compile-Time Entities

A crucial distinction that separates seasoned engineers from beginners is understanding when classes exist versus when objects exist.

Classes exist at compile-time (or definition-time):

When you write a class, you are writing instructions for the compiler/interpreter
The class is checked for syntactic and (often) semantic correctness before any program runs
The class is metadata: it describes the shape of data, not the data itself
In compiled languages, classes are typically stored in the compiled binary as type information

Objects exist at runtime:

Objects are created when the program executes
Each object occupies actual memory
Objects have real state that changes over time
Objects can be created, used, and destroyed while the program runs

Class (Compile-Time)

•Exists in source code
•Checked by the compiler
•Describes structure and behavior
•Cannot store actual values
•No memory footprint for instances
•One per type
•Static definition
•Created by the developer

Object (Runtime)

•Exists in memory
•Created by the runtime
•Holds actual data
•Stores concrete values
•Consumes heap memory
•Many per class
•Dynamic instance
•Created by the constructor

Why this distinction matters:

Understanding the compile-time vs runtime distinction is essential for:

Debugging — Many bugs arise from confusing class-level (static) behavior with instance-level behavior
Memory Management — Classes don't consume per-instance memory; objects do. Creating millions of objects from one class consumes millions of times the memory.
Performance Reasoning — Class definitions are free at runtime; object instantiation has real costs
Design Decisions — Whether something should be a class attribute (shared across all instances) or an instance attribute (unique to each object) has profound implications

Common Confusion

Beginners often conflate 'defining a class' with 'creating something.' Defining a class creates nothing but a template. Until you explicitly instantiate an object with new (or equivalent), no object exists. Writing class Dog { } does not create a dog—it defines what a dog would be if one were created.

Real-World Class Modeling

Let's see how the blueprint concept applies to modeling real-world entities. When we identify something in the problem domain, we ask:

What type of thing is it? → This suggests a class
What properties does it have? → These become attributes
What actions can it perform or receive? → These become methods

Example: Modeling a Library System

Consider a library management system. We might identify:

Book — A type of entity in the library

Properties: title, author, ISBN, publication year, availability status
Actions: borrow, return, reserve, get details

Member — A library patron

Properties: member ID, name, email, borrowed books, membership date
Actions: borrow book, return book, pay fines, update profile

Librarian — Staff who manages the library

Properties: employee ID, name, department, shift schedule
Actions: add book, remove book, process returns, manage members

LibraryEntities.java
Java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
/**
 * Blueprint for a Book in the library system.
 * Each book in the library will be an instance of this class.
 */
public class Book {
    private String isbn;
    private String title;
    private String author;
    private int publicationYear;
    private boolean isAvailable;
    private Member currentBorrower;
    
    public Book(String isbn, String title, String author, int year) {
        this.isbn = isbn;
        this.title = title;
        this.author = author;
        this.publicationYear = year;
        this.isAvailable = true;
        this.currentBorrower = null;
    }
    
    public boolean borrow(Member member) {
        if (!isAvailable) {
            return false;
        }
        this.isAvailable = false;
        this.currentBorrower = member;
        return true;
    }
    
    public void returnBook() {
        this.isAvailable = true;
        this.currentBorrower = null;
    }
    
    public String getDetails() {
        return String.format("%s by %s (ISBN: %s)", 
            title, author, isbn);
    }
}
 
/**
 * Blueprint for a Library Member.
 * Each patron of the library will be an instance of this class.
 */
public class Member {
    private String memberId;
    private String name;
    private String email;
    private List<Book> borrowedBooks;
    private LocalDate membershipDate;
    private static final int MAX_BOOKS = 5;
    
    public Member(String memberId, String name, String email) {
        this.memberId = memberId;
        this.name = name;
        this.email = email;
        this.borrowedBooks = new ArrayList<>();
        this.membershipDate = LocalDate.now();
    }
    
    public boolean borrowBook(Book book) {
        if (borrowedBooks.size() >= MAX_BOOKS) {
            return false; // Limit reached
        }
        if (book.borrow(this)) {
            borrowedBooks.add(book);
            return true;
        }
        return false;
    }
    
    public void returnBook(Book book) {
        if (borrowedBooks.remove(book)) {
            book.returnBook();
        }
    }
}

The modeling process in practice:

Identify nouns in the problem description → These are candidate classes
Identify adjectives and properties → These suggest attributes
Identify verbs → These suggest methods
Identify relationships → These suggest associations between classes

This is not a mechanical process. Good modeling requires judgment about:

What level of detail is appropriate?
What behaviors belong to which class?
What are the essential properties vs implementation details?

We will explore these questions in depth throughout this curriculum. For now, understand that a class is your tool for capturing the essence of a type of entity in your problem domain.

Classes Enable Abstraction

One of the most powerful aspects of classes is their role in abstraction—hiding complexity behind a simpler interface.

Consider the String class:

When you use a String in any programming language, you don't think about:

How characters are stored in memory (UTF-8? UTF-16? Null-terminated?)
How substring operations are implemented
Whether strings are mutable or immutable under the hood
How concatenation manages memory allocation

You simply use the String's public interface: create strings, concatenate them, search within them, extract substrings. The class abstracts away all the implementation complexity.

This is the power of the blueprint:

A class defines what something can do without requiring users to understand how it does it. This separation of interface from implementation is fundamental to managing complexity in software systems.

Benefits of Class-Based Abstraction

•Reduced Cognitive Load — Users of a class need only understand its public interface, not its internals. A developer using ArrayList doesn't need to know about dynamic array resizing.
•Implementation Freedom — The class author can change internal implementation without affecting users. You can optimize a class's internals while maintaining the same public methods.
•Reusability — Well-designed classes can be reused across different projects because they encapsulate coherent functionality behind a stable interface.
•Testability — Classes with clear interfaces are easier to test. You test the public contract, not the private implementation.
•Collaboration — Teams can work in parallel. One team implements a class while another team writes code that uses it, agreeing only on the interface.

Think in Contracts

When designing a class, think of it as writing a contract. The public methods are promises you make to users of the class. The private implementation is how you choose to fulfill those promises. Users trust the contract; they don't care about your internal strategies.

The Mental Model Shift

Understanding classes as blueprints requires a shift in how you think about code. Let's contrast procedural thinking with object-oriented thinking:

Procedural Thinking:

"I have data (variables) and I have functions that operate on that data. The functions transform inputs to outputs."

Object-Oriented Thinking:

"I have entities (objects) that bundle data and behavior together. Each entity knows how to manage its own state and respond to requests."

The class is the vehicle for this shift. When you define a class, you're saying: "There exists a type of entity with these characteristics and these capabilities."

Procedural Approach:

// Data is separate from functions
struct AccountData {
    string number;
    double balance;
}

// Functions operate on data externally
function deposit(account, amount) {
    account.balance += amount;
}

function withdraw(account, amount) {
    account.balance -= amount;
}

The data is passive. Functions act upon it from outside. Anyone can modify balance directly.

Object-Oriented Approach:

class BankAccount {
    private balance;
    
    deposit(amount) {
        this.balance += amount;
    }
    
    withdraw(amount) {
        if (this.balance >= amount)
            this.balance -= amount;
    }
}

The object is active. It manages its own state. External code must use the provided methods.

Why this shift matters for design:

When you think in classes:

You assign responsibility. Each class is responsible for managing its own data correctly. The BankAccount class is responsible for never having a negative balance, not every function that touches accounts.
You create boundaries. Classes define what's inside (private implementation) and what's outside (public interface). These boundaries contain complexity.
You model the domain. Classes let you mirror real-world concepts in code. A Customer class represents customers. An Order class represents orders. The code reflects the business domain.
You enable polymorphism. Because classes define types, you can write code that works with any object of a particular type, enabling powerful flexibility (we'll explore this in later chapters).

Summary: Understanding Classes as Blueprints

We've established the foundational understanding of what a class represents. Let's consolidate the key insights:

Key Takeaways

•A class is a blueprint, not an entity — It defines structure and behavior but does not itself hold data or perform actions.
•Classes exist at compile-time; objects exist at runtime — This distinction is fundamental to understanding OOP semantics.
•Classes define three things — Structure (attributes), behavior (methods), and invariants (rules that must always hold).
•Classes enable abstraction — They hide implementation details behind public interfaces, reducing complexity for users of the class.
•One class, many objects — The power of the blueprint is that it can be instantiated many times, each instance with its own state.
•Classes assign responsibility — Each class is responsible for managing its own data correctly, creating clear boundaries in your codebase.

What's next:

Now that we understand classes as blueprints, the next page explores the other half of the equation: objects as instances. We'll see how the abstract template of a class becomes a concrete, living entity in memory, and understand the crucial concept of instantiation.

Foundation Established

You now understand the fundamental concept of a class as a blueprint. This is the foundation upon which all object-oriented design is built. Every design pattern, every architecture, every well-designed system rests on understanding this simple but profound idea: classes define; objects exist.

Class as a Blueprint

The Foundation of Object-Oriented Programming

What You Will Learn

The Blueprint Metaphor

The most common and effective way to understand a class is through the blueprint metaphor. Consider an architect's blueprint for a house:

The blueprint specifies the structure: how many rooms, where the doors are, how the plumbing is laid out
The blueprint defines dimensions: room sizes, ceiling heights, window placements
The blueprint describes materials: what kind of flooring, wall finishes, fixtures

The Class-Blueprint Parallel

Why this metaphor works:

The blueprint metaphor captures the essential nature of a class:

Separation of Definition from Existence — A blueprint exists in the abstract; houses exist in reality. A class exists at compile-time; objects exist at runtime.
One-to-Many Relationship — One blueprint can produce many houses. One class can instantiate many objects.
Consistency Through Template — All houses built from the same blueprint share the same structural characteristics. All objects created from the same class share the same attributes and methods.
Variation Within Constraints — Houses built from the same blueprint can have different paint colors, furniture, and inhabitants. Objects of the same class can have different attribute values while sharing the same structure.

Blueprint vs House — Class vs Object
Blueprint (Class)	House (Object)
Abstract specification	Concrete reality
Exists on paper/in code	Exists in the world/in memory
Defines what can exist	Represents what does exist
One blueprint	Many houses
Created by the architect (developer)	Built by the constructor (runtime)
No physical resources consumed	Consumes physical resources (memory)

What a Class Defines

A class is a formal specification that defines three fundamental aspects of the entities it represents:

1. Structure (Attributes/Fields)

Attributes define the data that each object will hold. They answer the question: What information does this type of entity need to remember?

For a BankAccount class:

accountNumber: a unique identifier
balance: the current amount of money
ownerName: who owns the account
createdAt: when the account was opened

2. Behavior (Methods)

Methods define the actions that objects can perform or have performed upon them. They answer: What can this type of entity do?

For a BankAccount class:

deposit(amount): add money to the account
withdraw(amount): remove money from the account
getBalance(): report the current balance
transfer(toAccount, amount): move money to another account

3. Invariants (Rules/Constraints)

Though not always explicit in code, classes implicitly or explicitly define rules that must always hold. They answer: What must always be true about this entity?

For a BankAccount class:

Balance must never be negative (for a checking account)
Account number must be unique
Only the owner can authorize withdrawals

BankAccount.java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
/**
 * A class definition for a bank account.
 * This is a BLUEPRINT — it defines structure and behavior,
 * but no account exists until we instantiate it.
 */
public class BankAccount {
    // STRUCTURE: Attributes define the data each account holds
    private String accountNumber;
    private double balance;
    private String ownerName;
    private LocalDateTime createdAt;
    
    // BEHAVIOR: Methods define what an account can do
    public void deposit(double amount) {
        if (amount <= 0) {
            throw new IllegalArgumentException("Deposit must be positive");
        }
        this.balance += amount;
    }
    
    public void withdraw(double amount) {
        // INVARIANT: Balance must never go negative
        if (amount > this.balance) {
            throw new InsufficientFundsException();
        }
        this.balance -= amount;
    }
    
    public double getBalance() {
        return this.balance;
    }
    
    // Transfer combines behavior with collaboration
    public void transfer(BankAccount toAccount, double amount) {
        this.withdraw(amount);
        toAccount.deposit(amount);
    }
}

The Class as Contract

Classes Are Compile-Time Entities

A crucial distinction that separates seasoned engineers from beginners is understanding when classes exist versus when objects exist.

Classes exist at compile-time (or definition-time):

When you write a class, you are writing instructions for the compiler/interpreter
The class is checked for syntactic and (often) semantic correctness before any program runs
The class is metadata: it describes the shape of data, not the data itself
In compiled languages, classes are typically stored in the compiled binary as type information

Objects exist at runtime:

Objects are created when the program executes
Each object occupies actual memory
Objects have real state that changes over time
Objects can be created, used, and destroyed while the program runs

Class (Compile-Time)

•Exists in source code
•Checked by the compiler
•Describes structure and behavior
•Cannot store actual values
•No memory footprint for instances
•One per type
•Static definition
•Created by the developer

Object (Runtime)

•Exists in memory
•Created by the runtime
•Holds actual data
•Stores concrete values
•Consumes heap memory
•Many per class
•Dynamic instance
•Created by the constructor

Why this distinction matters:

Understanding the compile-time vs runtime distinction is essential for:

Debugging — Many bugs arise from confusing class-level (static) behavior with instance-level behavior
Memory Management — Classes don't consume per-instance memory; objects do. Creating millions of objects from one class consumes millions of times the memory.
Performance Reasoning — Class definitions are free at runtime; object instantiation has real costs
Design Decisions — Whether something should be a class attribute (shared across all instances) or an instance attribute (unique to each object) has profound implications

Common Confusion

Real-World Class Modeling

Let's see how the blueprint concept applies to modeling real-world entities. When we identify something in the problem domain, we ask:

What type of thing is it? → This suggests a class
What properties does it have? → These become attributes
What actions can it perform or receive? → These become methods

Example: Modeling a Library System

Consider a library management system. We might identify:

Book — A type of entity in the library

Properties: title, author, ISBN, publication year, availability status
Actions: borrow, return, reserve, get details

Member — A library patron

Properties: member ID, name, email, borrowed books, membership date
Actions: borrow book, return book, pay fines, update profile

Librarian — Staff who manages the library

Properties: employee ID, name, department, shift schedule
Actions: add book, remove book, process returns, manage members

LibraryEntities.java
Java
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
/**
 * Blueprint for a Book in the library system.
 * Each book in the library will be an instance of this class.
 */
public class Book {
    private String isbn;
    private String title;
    private String author;
    private int publicationYear;
    private boolean isAvailable;
    private Member currentBorrower;
    
    public Book(String isbn, String title, String author, int year) {
        this.isbn = isbn;
        this.title = title;
        this.author = author;
        this.publicationYear = year;
        this.isAvailable = true;
        this.currentBorrower = null;
    }
    
    public boolean borrow(Member member) {
        if (!isAvailable) {
            return false;
        }
        this.isAvailable = false;
        this.currentBorrower = member;
        return true;
    }
    
    public void returnBook() {
        this.isAvailable = true;
        this.currentBorrower = null;
    }
    
    public String getDetails() {
        return String.format("%s by %s (ISBN: %s)", 
            title, author, isbn);
    }
}
 
/**
 * Blueprint for a Library Member.
 * Each patron of the library will be an instance of this class.
 */
public class Member {
    private String memberId;
    private String name;
    private String email;
    private List<Book> borrowedBooks;
    private LocalDate membershipDate;
    private static final int MAX_BOOKS = 5;
    
    public Member(String memberId, String name, String email) {
        this.memberId = memberId;
        this.name = name;
        this.email = email;
        this.borrowedBooks = new ArrayList<>();
        this.membershipDate = LocalDate.now();
    }
    
    public boolean borrowBook(Book book) {
        if (borrowedBooks.size() >= MAX_BOOKS) {
            return false; // Limit reached
        }
        if (book.borrow(this)) {
            borrowedBooks.add(book);
            return true;
        }
        return false;
    }
    
    public void returnBook(Book book) {
        if (borrowedBooks.remove(book)) {
            book.returnBook();
        }
    }
}

The modeling process in practice:

Identify nouns in the problem description → These are candidate classes
Identify adjectives and properties → These suggest attributes
Identify verbs → These suggest methods
Identify relationships → These suggest associations between classes

This is not a mechanical process. Good modeling requires judgment about:

What level of detail is appropriate?
What behaviors belong to which class?
What are the essential properties vs implementation details?

We will explore these questions in depth throughout this curriculum. For now, understand that a class is your tool for capturing the essence of a type of entity in your problem domain.

Classes Enable Abstraction

One of the most powerful aspects of classes is their role in abstraction—hiding complexity behind a simpler interface.

Consider the String class:

When you use a String in any programming language, you don't think about:

How characters are stored in memory (UTF-8? UTF-16? Null-terminated?)
How substring operations are implemented
Whether strings are mutable or immutable under the hood
How concatenation manages memory allocation

You simply use the String's public interface: create strings, concatenate them, search within them, extract substrings. The class abstracts away all the implementation complexity.

This is the power of the blueprint:

Benefits of Class-Based Abstraction

•Reduced Cognitive Load — Users of a class need only understand its public interface, not its internals. A developer using ArrayList doesn't need to know about dynamic array resizing.
•Implementation Freedom — The class author can change internal implementation without affecting users. You can optimize a class's internals while maintaining the same public methods.
•Reusability — Well-designed classes can be reused across different projects because they encapsulate coherent functionality behind a stable interface.
•Testability — Classes with clear interfaces are easier to test. You test the public contract, not the private implementation.
•Collaboration — Teams can work in parallel. One team implements a class while another team writes code that uses it, agreeing only on the interface.

Think in Contracts

The Mental Model Shift

Understanding classes as blueprints requires a shift in how you think about code. Let's contrast procedural thinking with object-oriented thinking:

Procedural Thinking:

"I have data (variables) and I have functions that operate on that data. The functions transform inputs to outputs."

Object-Oriented Thinking:

"I have entities (objects) that bundle data and behavior together. Each entity knows how to manage its own state and respond to requests."

The class is the vehicle for this shift. When you define a class, you're saying: "There exists a type of entity with these characteristics and these capabilities."

Procedural Approach:

// Data is separate from functions
struct AccountData {
    string number;
    double balance;
}

// Functions operate on data externally
function deposit(account, amount) {
    account.balance += amount;
}

function withdraw(account, amount) {
    account.balance -= amount;
}

The data is passive. Functions act upon it from outside. Anyone can modify balance directly.

Object-Oriented Approach:

class BankAccount {
    private balance;
    
    deposit(amount) {
        this.balance += amount;
    }
    
    withdraw(amount) {
        if (this.balance >= amount)
            this.balance -= amount;
    }
}

The object is active. It manages its own state. External code must use the provided methods.

Why this shift matters for design:

When you think in classes:

You assign responsibility. Each class is responsible for managing its own data correctly. The BankAccount class is responsible for never having a negative balance, not every function that touches accounts.
You create boundaries. Classes define what's inside (private implementation) and what's outside (public interface). These boundaries contain complexity.
You model the domain. Classes let you mirror real-world concepts in code. A Customer class represents customers. An Order class represents orders. The code reflects the business domain.
You enable polymorphism. Because classes define types, you can write code that works with any object of a particular type, enabling powerful flexibility (we'll explore this in later chapters).

Summary: Understanding Classes as Blueprints

We've established the foundational understanding of what a class represents. Let's consolidate the key insights:

Key Takeaways

•A class is a blueprint, not an entity — It defines structure and behavior but does not itself hold data or perform actions.
•Classes exist at compile-time; objects exist at runtime — This distinction is fundamental to understanding OOP semantics.
•Classes define three things — Structure (attributes), behavior (methods), and invariants (rules that must always hold).
•Classes enable abstraction — They hide implementation details behind public interfaces, reducing complexity for users of the class.
•One class, many objects — The power of the blueprint is that it can be instantiated many times, each instance with its own state.
•Classes assign responsibility — Each class is responsible for managing its own data correctly, creating clear boundaries in your codebase.

What's next:

Foundation Established