Classes and Objects

A class is a blueprint that defines the structure and behavior of objects. It encapsulates data (attributes) and operations (methods) into a single unit.

Anatomy of a Class

┌──────────────────────────────┐
│          ClassName            │
├──────────────────────────────┤
│  Attributes (Fields)         │
│  - id: int                   │
│  - name: String              │
│  - email: String             │
├──────────────────────────────┤
│  Methods (Functions)         │
│  + getDetails(): String      │
│  + updateEmail(e: String): void │
│  + validate(): boolean       │
└──────────────────────────────┘

Class Design Guidelines

Naming Conventions:

• Use PascalCase: UserProfile, OrderService
• Nouns for entity classes: User, Product, Order
• Verbs for service classes: PaymentService, EmailSender
• Adjectives for interfaces: Serializable, Comparable

Attribute Design:

// Good: Clear, typed, encapsulated
class User {
    private String id;
    private String name;
    private String email;
    private LocalDateTime createdAt;
}

// Bad: Unclear types, public fields
class User {
    public var data;
    public int x;
}

Method Design:

// Good: Single responsibility, clear naming
class OrderService {
    public Order createOrder(Cart cart) { ... }
    public void cancelOrder(String orderId) { ... }
    public OrderStatus getStatus(String orderId) { ... }
}

// Bad: Multiple responsibilities, unclear
public void doStuff(Object input) { ... }

Types of Classes

Type	Purpose	Example
Entity	Represent domain objects	User, Product, Order
Value Object	Represent immutable values	Money, Address, DateRange
Service	Contain business logic	PaymentService, AuthService
Repository	Data access abstraction	UserRepository, OrderRepository
DTO	Transfer data between layers	UserDTO, OrderRequest
Factory	Create objects	UserFactory, NotificationFactory

Objects are instances of classes. Understanding object creation is crucial for designing flexible and testable systems.

Object Lifecycle

Class Definition
       │
       ▼
   Construction ──▶ Initialization ──▶ Usage ──▶ Destruction
   (new keyword)   (constructor)     (methods)   (garbage collect)

Constructor Patterns

Default Constructor:

class User {
    private String id;
    private String name;
    
    // Default constructor
    public User() {
        this.id = UUID.randomUUID().toString();
        this.name = "Anonymous";
    }
}

Parameterized Constructor:

class User {
    private String id;
    private String name;
    private String email;
    
    public User(String name, String email) {
        this.id = UUID.randomUUID().toString();
        this.name = name;
        this.email = email;
    }
}

Builder Pattern (for complex objects):

User user = new User.Builder()
    .setName("John")
    .setEmail("john@example.com")
    .setRole(Role.ADMIN)
    .build();

Object Identity vs Equality

Identity (==): Same reference in memory
Equality (equals()): Same logical value

User a = new User("John");
User b = new User("John");
User c = a;

a == b  → false (different objects)
a == c  → true  (same object)
a.equals(b) → true (same values)

Object Immutability

Immutable objects cannot be modified after creation:

// Immutable class
class Money {
    private final double amount;
    private final String currency;
    
    public Money(double amount, String currency) {
        this.amount = amount;
        this.currency = currency;
    }
    
    public double getAmount() { return amount; }
    public String getCurrency() { return currency; }
    
    // Returns new object instead of modifying
    public Money add(Money other) {
        return new Money(this.amount + other.amount, this.currency);
    }
}

Factory Methods

public class UserFactory {
    public static User createRegularUser(String name, String email) {
        return new User(name, email, Role.REGULAR);
    }
    
    public static User createAdminUser(String name, String email) {
        return new User(name, email, Role.ADMIN);
    }
}

Properties (attributes) and methods define the state and behavior of objects. Proper design of these is essential for maintainable code.

Property Design

Types of Properties:

┌─────────────────────────────────────────────┐
│                 User                         │
├─────────────────────────────────────────────┤
│ Instance Properties (per object)            │
│  - id: String          (unique per user)    │
│  - name: String        (unique per user)    │
│  - email: String       (unique per user)    │
├─────────────────────────────────────────────┤
│ Static Properties (shared across all)       │
│  - totalCount: int     (all users combined) │
│  - MAX_NAME_LENGTH: 50 (constant)          │
└─────────────────────────────────────────────┘

Property Rules:

1. Keep properties private (encapsulation)
2. Use getters/setters for access control
3. Prefer immutable properties when possible
4. Validate in setters

Method Design Principles

Single Responsibility:

// Good: Each method does one thing
class Calculator {
    public int add(int a, int b) { return a + b; }
    public int subtract(int a, int b) { return a - b; }
    public double average(int[] numbers) { ... }
}

// Bad: One method does everything
public void doCalculation(String type, int a, int b) {
    if (type == "add") { ... }
    else if (type == "subtract") { ... }
}

Method Length:

• Aim for 5-20 lines per method
• If longer, break into helper methods
• Each method should be understandable in isolation

Parameter Design:

// Good: Clear, limited parameters
public Order createOrder(String userId, List<OrderItem> items, 
                        PaymentMethod payment) { ... }

// Bad: Too many parameters
public Order createOrder(String userId, String address,
                        String city, String zip, String cardNum,
                        String expiry, double total, ...) { ... }

Return Types

Pattern	Example	When to Use
Value	int getCount()	Simple computations
Object	User getUser(id)	Fetching data
Boolean	boolean validate()	Validation checks
Optional	Optional<User> find(id)	May return nothing
void	void save(user)	Side effects only
Builder	Builder setName(n)	Fluent APIs

Method Visibility Strategy

public    → API of the class (used by external code)
protected → Extension points (used by subclasses)
package   → Internal collaboration (used by same package)
private   → Implementation details (used only internally)

Rule of thumb: Start with private, increase visibility only when needed.