Chapter 5 — Objects

Understanding the idea
Objects are a way to represent things from the real world inside a computer program. Each object groups two parts: state (the data that describes it) and behaviour (the operations it can perform). For example, a Bicycle object may have state like colour and gearCount and behaviour like pedal() and applyBrake().

Classes as blueprints
A class is the template that defines what attributes and methods objects of that type will have. Think of a class as the plan for a house and objects as the houses built from that plan. The class defines the layout and components; each object uses that layout but can have different values for its attributes.

Why objects help
When building larger programs, grouping related data and functions inside classes keeps code organised. Instead of writing separate functions and loose data, classes provide a consistent way to bundle everything related to a concept. This improves readability and reduces repeated code because behaviour common to many objects can be placed in one class definition.

Instances and identity
Creating an object from a class is called instantiation. Each instance has its own identity and attribute values. Two Bicycle objects may both be of class Bicycle but have different colours and gear settings. The language runtime keeps track of each object separately.

Classes and modelling
When designing a program, choose classes that represent clear entities in the problem domain: Student, BankAccount, Book, Sensor, etc. For each class, decide which attributes should be stored and which actions should be provided as methods. Keeping classes focused helps later changes and testing.

Code organisation and reuse
Classes promote reuse: once a class is written and tested, it can be used in many places or by many programs. Libraries are collections of classes designed to solve common tasks. By learning to think in terms of objects and classes, you prepare for larger projects and industry-standard programming patterns.

Attributes: what objects hold
Attributes (also called fields or properties) are the values that describe an object. They represent the object's state. Attributes may be simple types such as numbers or text, or they may be references to other objects. When you design a class, list the essential attributes required to describe each instance. For example, a Rectangle class needs length and breadth to describe its shape.

Methods: what objects do
Methods are functions defined inside a class that describe how an object behaves. Methods can read or change attributes and perform tasks. A method could compute a result (like area()), change internal state (like deposit()), or coordinate actions across multiple objects (like transfer()). Methods form the public interface through which other parts of the program interact with the object.

Instance vs class members
Instance attributes belong to each object separately: every object has its own copy. Class-level (static) attributes are shared across all objects of the class: changing a static attribute affects every instance. Decide whether a value should be shared (like a global constant) or unique to each instance when designing attributes.

Parameters and return types
Methods can accept parameters to receive input and can return values. When writing a method, specify what it needs from the caller and what it will produce. Keep method responsibilities focused: a method should do one clear task and have a simple contract (inputs and outputs).

Visibility and access
Good design keeps attributes private and offers public methods (getters and setters) when outside access is necessary. This prevents external code from putting the object into an invalid state. Methods that expose behaviour can validate inputs and maintain invariants.

Design considerations
Avoid exposing internal details unnecessarily. Use methods to provide controlled access. When an attribute can be computed from others, consider providing a method instead of storing redundant data. Keep methods small and testable so their effects are clear and predictable.

What encapsulation means
Encapsulation bundles an object's data and the methods that operate on that data into a single unit — the class. Data hiding is the practice of preventing external code from accessing or modifying the internal state directly. Together, these ideas protect the object’s integrity and define clear interfaces for interaction.

Why hide data?
Allowing outside code to change attributes directly leads to fragile programs. Without control, attributes may get invalid values or inconsistent combinations. By exposing only methods that enforce validation rules, the class maintains its invariants. For example, an Account class should ensure balance never becomes negative unless allowed by overdraft rules; the withdraw() method enforces this.

Getters and setters
Getters and setters are public methods used to read and write private attributes. Setters validate input before assignment and can trigger side effects (such as updating derived values). Getters can format or compute values on demand rather than exposing raw internal data. Use them when external access is necessary, but do not create them reflexively for every attribute—only expose what must be accessed externally.

Encapsulation helps change without breaking
If internal representation needs to change (for example, storing temperature in Kelvin instead of Celsius), encapsulation allows the change to be local to the class. External code calling getTemperature() and setTemperature() can remain unchanged because the class translates internally. This reduces coupling and helps in refactoring.

Practical patterns
1) Keep attributes private unless there is a strong reason to make them public. 2) Provide methods that perform meaningful operations rather than exposing low-level state. 3) Use immutable objects where possible: if an object’s state is fixed after creation, many bugs are avoided. 4) Validate inputs in setters and constructors to keep objects consistent from creation.

Examples and caution
Overuse of getters and setters can still expose internal structure indirectly. Aim for behaviour-oriented interfaces: methods that do high-level tasks (transfer(), computeAverage(), render()) rather than simple read/write pairs for every attribute.

Role of constructors
Constructors are special methods invoked when an object is created to initialise its attributes and prepare it for use. They set up a valid internal state and may allocate resources needed by the object. A well-designed constructor leaves the object ready to use immediately after creation.

Default and parameterised constructors
A default constructor takes no arguments and sets attributes to standard initial values. A parameterised constructor accepts inputs so objects can start with custom state. Offering both styles increases flexibility: clients can choose simple defaults or supply precise initial values.

Overloading constructors
Many languages support multiple constructors with different parameter lists (overloading). For example, a Rectangle class may have a default constructor setting both sides to 1, another constructor accepting length and breadth, and a copy constructor that creates a new object from an existing one.

Best practices for constructors
Keep constructors simple and avoid heavy work such as long-running I/O or network calls because these can make object creation fail or slow. If object creation is complex or may fail, use factory methods that can return error values or manage creation steps. Validate constructor parameters and throw exceptions or return errors for invalid inputs to prevent creation of invalid objects.

Chaining and delegation
Constructor chaining allows one constructor to call another to reduce code duplication when several constructors share initialisation logic. This keeps initialisation centralised and easier to maintain. Inheritance requires attention: the parent class constructor usually runs before the child class constructor to initialise inherited state.

Destructors and resource cleanup
Some languages provide destructors or finalisers that run when an object is destroyed to free resources. In languages with automatic garbage collection, finalisers are not deterministic in timing, so explicit close/dispose methods are preferred for non-memory resources such as files or sockets. Use try-finally or language-specific constructs to ensure deterministic cleanup.

Purpose of access specifiers
Access specifiers control which parts of a program can see or use class members (attributes and methods). They are the language mechanism used to enforce encapsulation and limit coupling between classes. Correct use of these specifiers leads to safer and more maintainable code.

Public members
Public members (+) are visible to all code that has access to the class. Public methods form the class's interface; external code relies on these to interact with objects. Keep the public interface small and focused, exposing only the operations that clients truly need.

Private members
Private members (-) are accessible only inside the class itself. Attributes are commonly private so that only class methods can change them, ensuring that invariants and validation checks are enforced. Private methods are used for internal helper functions that should not be visible to or called by outside code.

Protected members
Protected members (#) are visible within the class and to subclasses (derived classes). Protected members allow subclasses to access or extend internal behaviour while still hiding those details from other classes. Use protected sparingly: exposing too much to subclasses can create tight coupling between parent and child implementations.

Package or internal visibility
Some languages provide additional levels like package or internal visibility that restrict access to a set of classes within the same module or package. These provide a balance between full privacy and public visibility for closely related classes within a component.

Design guidelines
1) Prefer private for attributes. 2) Expose behaviour through public methods rather than giving direct access to data. 3) Use protected only when subclasses truly require access. 4) Minimise the public surface area to allow future internal changes without breaking client code.

Example trade-offs
Making a field public may seem easier, but it ties external code to that internal representation; changing it later will break clients. Controlled access via methods gives flexibility to change internal structure while keeping the same external behaviour.

What inheritance gives you
Inheritance allows a class (subclass) to derive from another class (superclass), gaining its attributes and methods. This supports reuse of common behaviour and lets you express specialisation: the subclass is a more specific version of the superclass. For example, if Vehicle defines move() and speed, Car and Bike can inherit those features and add their own specifics.

How it reduces duplication
Without inheritance, shared code must be duplicated across classes, making maintenance harder. With inheritance, common code resides in the parent class and is inherited by children. Fixes or improvements in the parent automatically apply to subclasses, reducing chances of inconsistent behaviour. Careful design ensures the parent contains only behaviour that truly belongs to all its children.

Extending and overriding
Subclasses can add new attributes and methods or override parent methods to change behaviour. Overriding lets a subclass provide a specialised implementation while preserving the parent’s interface. Often a subclass calls the parent implementation and then extends it, rather than fully replacing it. When overriding, maintain preconditions and postconditions so that substitutability remains valid.

Multiple inheritance and alternatives
Some languages allow multiple inheritance where a class derives from several parents. This can lead to complexity such as the diamond problem where a method appears in multiple parent paths. To avoid such complexities, many languages provide interfaces or traits that supply type-based capabilities without concrete implementation inheritance. Use interfaces for behaviour contracts and single inheritance for concrete reuse.

Design principles and Liskov Substitution
Use inheritance to model true "is-a" relationships: a Car is a Vehicle, a Square is a Shape. The Liskov Substitution Principle (LSP) guides correct use: objects of a subclass must be usable wherever the parent type is expected without surprising behaviour. Violating LSP leads to bugs when code written for the parent type encounters unexpected subclass behaviour.

When not to use inheritance
Do not use inheritance merely for code reuse if there is no conceptual parent-child relationship. Prefer composition in cases where one object contains or uses another but is not a specialised form of it. Composition keeps classes loosely coupled and easier to change. Also prefer shallow hierarchies to deep ones to simplify understanding and maintenance.

Practical tips
Document the responsibilities of base classes clearly. Design base classes with stable contracts and avoid exposing too many protected members that tie subclasses to internal representations. When in doubt, start with composition and refactor to inheritance only if a true specialization relationship emerges.

Core idea of polymorphism
Polymorphism allows code to treat objects of different classes in a uniform way through a common interface. The exact method executed depends on the object's runtime type. This enables flexible and extensible programmes that require little or no change when new classes are added which follow the same interface.

Kinds of polymorphism
Two commonly discussed kinds are compile-time polymorphism and runtime polymorphism. Compile-time polymorphism includes method overloading where multiple methods share a name but differ in parameter lists. Runtime polymorphism occurs when a subclass overrides a method of its parent and a parent-type reference points to a subclass object; the runtime selects the subclass method.

Designing for polymorphism
Program to interfaces or abstract base classes rather than concrete classes. For instance, write functions that accept a parameter of type Shape rather than Circle. Any class implementing Shape can then be passed to the function, and the correct method implementations run. This reduces conditional checks and supports the Open/Closed Principle: you can add new classes without changing existing code.

Practical patterns
Interfaces and abstract classes are common tools for polymorphism. Use an interface to define a capability like Comparable or Drawable. Concrete classes implement those methods in their own way. Polymorphism is also the basis for many design patterns such as Strategy, where behavior is selected at runtime by choosing a particular implementation of an interface.

Risks and contracts
When overriding methods, ensure the subclass respects the expected contract of the parent method: do not strengthen preconditions or weaken postconditions. Unexpected changes in behaviour can break client code that relies on parent semantics. Document intended behaviour and test subclass instances in contexts where parent types are used.

Examples and benefits
Example: a function drawAll(listOfShapes) calls draw() on each Shape. Circle, Rectangle and Triangle implement draw() differently but the same code draws all. Benefits include simpler code, easier extension and reduction of conditional type checks. Polymorphism helps build systems that are modular, extendable and easier to maintain.

Why relationships matter
Classes rarely live alone: they interact. Modelling how objects relate clarifies responsibility, lifetime and ownership. Three commonly used relationship types are association, aggregation and composition. They help decide which class should create or destroy objects and how tightly they are coupled.

Association — loose link
Association is a simple link where objects know about each other and can call methods, but neither owns the other’s lifecycle. For example, a Teacher may be associated with many Students; both can exist independently. Association is used for collaborations where objects use each other but do not manage each other’s existence.

Aggregation — whole-part but independent
Aggregation is a form of association indicating a whole-part relationship where parts can exist independently of the whole. For instance, a Department may aggregate Professors; a Professor can move to another Department and outlive a particular Department. Aggregation shows a weaker ownership and suggests parts are shared or reusable across different wholes.

Composition — strong ownership
Composition expresses strong ownership: parts belong to a whole and cannot meaningfully exist outside it. If the whole is destroyed, so are the parts. Example: a House composed of Room objects; rooms are part of that house model and typically are not independent entities in the system. Composition often implies that the whole creates and destroys the parts.

Modelling consequences
Choosing composition versus aggregation affects memory and lifecycle management. Composition usually means the parent constructs and manages child objects, while aggregation suggests external code may provide parts. Carefully assess whether a part makes sense independently before modelling it as composite.

UML and multiplicity
In UML, association is a plain line, aggregation an open diamond and composition a filled diamond at the whole end. Multiplicity indicators (1, 0..*, *) show how many instances participate. Clear multiplicity helps avoid ambiguous designs and clarifies expected usage patterns.

Objects communicate by messages
In object-oriented systems, interaction between objects is performed by sending messages. A message generally corresponds to invoking a method on the target object, optionally passing parameters and receiving a result. This message-based communication keeps components decoupled: callers depend on the receiver's interface rather than its internal details.

Method call mechanics
When a method is invoked, the runtime locates the method implementation in the target object's class (considering inheritance and overriding), binds parameters, executes code in the method body and returns control to the caller with any return value. Dynamic dispatch ensures the most specific implementation is chosen at runtime for overridden methods. The call stack records active method calls so control can return correctly after each return.

Parameter passing and side-effects
Languages vary in how they pass parameters. Primitive values are often passed by value, meaning the method works on a copy. Object references are usually passed so the method can change the referred object's state. Understanding whether a method mutates its arguments or works with copies is important to avoid unintended side-effects. Document whether a method mutates its inputs or returns new objects.

Synchronous versus asynchronous invocation
Most calls are synchronous: the caller waits until the called method finishes. In concurrent or distributed systems, asynchronous message passing lets the caller continue while the recipient processes the message later. Asynchronous patterns require callbacks, listeners, futures or promises to obtain results eventually and need careful error handling and concurrency control.

Respecting encapsulation through messages
Message passing supports encapsulation because objects expose behaviour (methods) rather than internal state. Callers request actions via messages and do not rely on representation details. Design small, well-named methods that clearly express intent, which makes message-based interactions easier to understand and use.

Error handling and contracts
Define method contracts: preconditions the caller must satisfy, and postconditions the method guarantees. Methods can signal errors via return values, exceptions or status objects. Clear contracts and consistent error signalling make integration between objects safer and simplify debugging when message exchanges fail.

Static members explained
Static (or class) members belong to the class itself rather than to individual instances. A static attribute is shared across all instances and is stored once at the class level. A static method can be called without creating any object and typically performs operations that do not depend on instance-specific data.

When to use static attributes
Use static attributes for values that are common to all instances, such as configuration constants or counters tracking the total number of created objects. For example, a class may maintain a static totalCount that increments in each constructor to know how many instances exist or were created. This shared state is convenient but must be used carefully because changes affect every instance.

When to use static methods
Static methods are useful for utility operations (for example, Math.max()) and factory methods that create and return instances. A factory method can centralise complex creation logic so callers do not need to know the details of constructing different concrete classes.

Thread-safety and concurrency
Because static attributes are shared, concurrent access can lead to race conditions if multiple threads read and write them. Synchronisation mechanisms (locks, atomic operations) may be required to make updates safe. Avoid using mutable static state when possible in multi-threaded contexts to reduce complexity and bugs.

Testing and global state
Static mutable state makes testing harder because tests can interfere with each other by changing shared values. Prefer passing dependencies explicitly or using dependency injection to make testing easier. If static values are necessary, provide ways to reset or configure them during tests.

Design advice
Use static members for logically shared data or stateless helper functions. Avoid static state that creates hidden coupling between classes. Keep static usage minimal and document why a member is static to help future maintainers.

Abstract classes
An abstract class defines a base type that may provide some implemented methods and may declare abstract methods that do not have implementations. Abstract classes cannot be instantiated directly; they are intended to be subclassed by concrete classes that implement the abstract methods. Abstract classes are useful when several related classes share common code but also need to supply specialized behaviour.

Interfaces
An interface is a pure contract listing method signatures (and sometimes constants) that implementing classes must provide. Interfaces do not contain implementation (or contain limited default implementations in some languages). They describe capabilities rather than implementation and allow unrelated classes to be treated uniformly if they implement the same interface.

Choosing between them
Use an abstract class when you want to share code among related classes and enforce a common base. Use an interface when you want to define a role or capability that many different classes might provide without implying inheritance. Interfaces enable multiple-type polymorphism: a class can implement several interfaces to express many capabilities.

Polymorphism and substitution
Both abstract classes and interfaces support polymorphism: code can refer to the abstract type and work with any concrete implementation. This simplifies code and supports extension: new concrete classes implementing the interface or extending the abstract class integrate easily with existing code.

Design trade-offs
Abstract classes allow code reuse but create tighter coupling via inheritance. Interfaces keep types loosely coupled but may require duplication of helper code unless helper classes or default methods are provided. Consider maintainability and future extension when choosing between them.

Practical uses
Interfaces commonly describe behaviours like Comparable (objects that can be ordered) or Runnable (objects that can run on a thread). Abstract classes are used when there is a meaningful base implementation, such as a BaseController providing common request handling with abstract methods for module-specific details.

Why use UML class diagrams
UML class diagrams are a standard visual language to show classes, their members and relationships. They help designers and programmers communicate structure before or during implementation. A clear diagram makes it easier to understand responsibilities, object interactions and dependencies at a glance.

Class box structure
A class is drawn as a rectangle divided into three compartments: top for the class name, middle for attributes and bottom for methods. Visibility symbols precede names: '+' for public, '-' for private and '#' for protected. Including types and return types helps readers know what data each member holds or returns.

Attributes and methods details
Attributes are listed with name and type and can include default values or multiplicities when needed. Methods show name, parameters and return type. Explicitly specifying types makes the diagram clearer and aids implementation. For example: - balance: float = 0.0 and + deposit(amount: float): void.

Relationships and symbols
Association is shown as a plain line connecting classes. Aggregation uses an open diamond at the whole end to show a weak whole-part relationship. Composition uses a filled diamond to denote strong ownership where parts are created and destroyed with the whole. Inheritance is shown with a solid line and a hollow arrow pointing to the parent class.

Multiplicity and navigability
Multiplicity near the ends indicates how many instances participate in a relationship, such as 1, 0..*, or *. Navigability arrows show which class knows about or can access the other. Properly labelling multiplicities and navigability avoids misinterpretation of how objects relate at runtime.

Reading and refining diagrams
Begin with high-level diagrams showing main classes and their relations. Then refine by adding important attributes, methods and multiplicities. Use sequence diagrams to show typical interactions for key use cases. Keep diagrams concise; too much detail can hide the overall structure. Update diagrams as design evolves so they remain useful documentation.

Stages of an object's life
Objects typically pass through creation, initialisation, use and destruction. Creation allocates memory and resources, the constructor initialises state, methods are called while the object is in use, and finally the object becomes unused and may be destroyed or garbage-collected. Understanding these stages helps manage resources and avoid leaks.

Memory allocation and references
When an object is created, memory is allocated to store its attributes. Variables hold references (or pointers) to objects. The number and visibility of references determine whether an object is considered reachable. Reachable objects cannot be reclaimed until references are removed or go out of scope.

Garbage collection vs manual deallocation
Managed languages provide garbage collection that frees memory of objects that are no longer reachable. In languages without garbage collection, programmers must explicitly free memory to avoid memory leaks. Even in managed environments, non-memory resources like files, sockets and database connections must be released explicitly because garbage collection does not guarantee timely cleanup.

Reference counting and cycle issues
Reference counting deallocates objects when their reference counts reach zero, but cycles of references can prevent deallocation unless broken explicitly. Other garbage collection techniques use reachability analysis to find objects unreachable from root references. Each approach has trade-offs in performance and predictability.

Finalisers and explicit cleanup
Finaliser or destructor methods may run when an object is collected, but their timing is often unpredictable. It is better to provide explicit close or dispose methods (and use language constructs like try-finally or try-with-resources) to ensure timely release of critical resources. This makes resource management deterministic and reduces runtime errors in long-running applications.

Practical suggestions
Avoid holding unnecessary references that prolong object lifetime. Use weak references for caches to allow garbage collection. Keep object scope narrow and free external resources promptly. Monitor memory usage and test for leaks, particularly in long-running services.

Single Responsibility Principle (SRP)
SRP states that a class should have only one reason to change. This means a class should focus on a single responsibility or purpose. When a class mixes unrelated responsibilities—such as handling user input, business rules and file storage—it becomes hard to test and maintain because changes in one area affect the others. Designing classes with one clear responsibility reduces coupling and localises the impact of changes.

Separation of Concerns
Separation of concerns divides a programme into distinct sections that each address a different concern. Typical layers include presentation (UI), business logic (services), and data access (repositories). Each layer should interact with others through well-defined interfaces. This separation improves clarity, enables parallel development, and simplifies testing because components can be tested independently or with mocks.

Benefits of applying these principles
Following SRP and separation of concerns improves cohesion, which means related functionality is grouped together, and reduces coupling between unrelated parts. Such designs are easier to modify, extend, and understand. Smaller classes with focused responsibilities are often simpler to write unit tests for and result in faster, safer refactoring.

How to refactor towards SRP
Identify a class that performs multiple tasks and ask which parts are conceptually different. Extract responsibilities into new classes with clear names. For example, an OrderProcessor handling input validation, payment and persistence can be split into OrderValidator, PaymentProcessor and OrderRepository. Move code that deals with external systems into separate adapters so domain logic remains pure and testable.

Use interfaces and dependency injection
Define interfaces to decouple components. Dependency injection supplies implementations to classes at runtime, which makes swapping or mocking components easy for tests. For instance, the business layer can depend on an IOrderRepository interface instead of a concrete database implementation, enabling use of in-memory repositories for testing.

Balance and practical considerations
Avoid over-splitting into too many tiny classes which can increase navigation cost and reduce clarity. Aim for a pragmatic balance: classes should be small enough to be focused but large enough to represent meaningful concepts. Keep design simple initially and refactor to improve SRP as requirements evolve.

Why learn patterns and analysis
Design patterns are commonly occurring solutions to recurring problems in software design. Object-oriented analysis helps convert requirements into classes and objects. Together they give a practical toolkit: analysis finds the right objects and relationships; patterns suggest proven ways to organise interactions between those objects.

Object-oriented analysis (OOA) steps
1) Read requirements and identify actors and use-cases. 2) Find candidate classes by spotting important nouns in descriptions (Customer, Order, Product). 3) For each candidate class, determine attributes and key methods. 4) Establish relationships: which classes use, contain or inherit from others? 5) Create UML diagrams (class and sequence) to visualise structure and interactions, then refine iteratively.

Factory pattern (creational)
The Factory pattern provides a method (factory) to create objects instead of calling constructors directly. This centralises creation logic and allows returning different concrete subclasses based on input or configuration. Use it when object creation is complex, requires configuration, or the exact class to instantiate may vary at runtime.

Observer pattern (behavioural)
The Observer pattern defines a one-to-many relationship: when one object (subject) changes state, a set of observers are notified automatically. This suits event-driven designs like GUIs or model-view updates. Observers register themselves with the subject and receive update notifications when relevant changes occur.

Applying patterns during analysis
During analysis, recognise situations where patterns help: if creation is conditional or configurable, introduce a factory; if many parts must react to changes in a single object, design subject-observer relationships. Use UML to depict pattern participants: factory classes, product interfaces and observer lists with update messages.

Practical trade-offs
Patterns add indirection and may complicate small programmes; use them when they solve real design problems or improve extensibility. Keep designs simple at first and refactor to patterns when the need becomes clear. Document chosen patterns to help future maintainers understand design intent.