1.2.4 - Object-oriented programming principles

A class defines behavior while each object holds state

Object-oriented code separates a reusable definition from each particular entity created from it.

An attribute stores state; a method is a subroutine belonging to the object. A Session class might have a minutes attribute and an extend method; two Session objects can hold different minutes values while using the same method definition.

[DIAGRAM: One Session class instantiates morning and evening objects with independent minutes values; asset_slug: session-class-objects; caption: A shared class definition creates separate objects, each with its own state.]

Creating morning with 20 minutes and evening with 45 minutes does not create one shared minutes variable. Extending morning by 5 should change morning to 25 and leave evening at 45. The class is a definition; the object is the particular entity on which a call such as morning.extend(5) acts. A method's parameter supplies extra input to that operation, rather than creating another object automatically.

Object-oriented design can keep related state and operations together so callers need not manage every internal update. That benefit depends on a sensible design: using classes does not itself make a program faster, safer or easier to maintain. A class should represent a meaningful responsibility, not merely rename a collection of unrelated functions.

Constructors and access methods protect valid state

A constructor initialises a new object. OCR pseudocode names this procedure new; new Session(20) creates an instance and passes 20 to its constructor. A public member can be used by outside code; a private member is accessible through the class's implementation rather than direct outside access. OCR's printed pseudocode assumes members are public unless explicitly marked otherwise, and its methods are instance methods.

Encapsulation combines state with operations and provides a controlled interface. Marking an attribute private stops callers bypassing the intended operations. A getter returns state; a setter or another update method can enforce an invariant, such as minutes never becoming negative. Encapsulation requires appropriate method behavior, not simply a getter and setter with no checks.

class Session
    private minutes
    public procedure new(givenMinutes)
        minutes = givenMinutes
    endprocedure
    public function getMinutes()
        return minutes
    endfunction
    public function extend(amount)
        if amount < 0 then
            return false
        endif
        minutes = minutes + amount
        return true
    endfunction
    public function describe()
        return "Session"
    endfunction
endclass
morning = new Session(20)
accepted = morning.extend(5)
print(morning.getMinutes())

The constructor's givenMinutes has a precondition of being a nonnegative integer. The last call prints 25. Calling extend with −3 returns false before changing minutes; zero is accepted and leaves it unchanged. Outside code should use getMinutes() rather than assign to morning.minutes. A getter returns a value and is therefore a function; a procedure without a returned value is not a substitute.

Inheritance shares behavior and constructor work

Inheritance defines a subclass from a superclass. The subclass receives the superclass's available behavior and may add or specialise features. Use it for a meaningful 'is a kind of' relationship: a PaidSession is a kind of Session. A booking system containing a Session is a 'has a' relationship and does not by itself justify inheritance.

OCR writes inherits in the class declaration and super.new(...) to call the superclass constructor. super.method(...) calls a superclass method. These calls reuse an existing implementation rather than duplicate its state updates.

class PaidSession inherits Session
    private rate
    public procedure new(givenMinutes, givenRate)
        super.new(givenMinutes)
        rate = givenRate
    endprocedure
    public function cost()
        return getMinutes() * rate
    endfunction
    public function describe()
        return super.describe() + ": paid"
    endfunction
endclass
evening = new PaidSession(45, 2)
print(evening.cost())

This uses the preceding Session definition. The rate is an integer price per minute for this example; givenMinutes and givenRate are nonnegative integers. The superclass constructor sets minutes to 45 and the subclass constructor sets rate to 2, so cost returns 90. PaidSession can use inherited extend and getMinutes. It should not directly access Session's private minutes; the getter is the defined interface.

Calling super.describe() explicitly gets the superclass's "Session" result, to which the subclass adds ": paid". This demonstrates reuse even when a method is specialised. Calling the superclass constructor matters because inherited state must be initialised too. Inheritance can reduce duplication, but an unsuitable hierarchy can couple classes so that a superclass change has unintended effects in its subclasses.

The object's class selects an overridden method

Overriding supplies a subclass implementation of an inherited method with the same interface. Polymorphism lets the same kind of call use different appropriate implementations for different objects. The call is not chosen merely from a variable's name; it depends on the object receiving it.

Session and PaidSession both provide describe() with no explicit parameters. Calling morning.describe() uses Session's implementation and returns "Session". Calling evening.describe() uses PaidSession's override and returns "Session: paid". Client code can call describe on either object without writing a separate type test for each class.

For example, a display routine receives one of these objects and calls its describe method. Adding a new subclass with its own compatible describe method can add another display behavior without changing the routine. The shared interface must still mean something consistent to callers; a method with a different name or incompatible parameters is not this override. Overriding is also distinct from merely giving several unrelated functions different names.

Polymorphism does not imply every inherited method changes. PaidSession's getMinutes and extend still use the inherited implementations, while describe is specialised.

Follow and amend equivalent pseudocode and Python

Programming principles are independent of one language's punctuation, but a working implementation must respect its language's conventions. Python constructors use __init__; self identifies the current object. Python's double-underscore attributes are name-mangled to reduce accidental access and collisions, rather than providing an absolute security boundary. This is an implementation aid to the encapsulation design, not identical enforcement to OCR's private keyword.

The following complete Python 3 sandbox implements the same interface and behavior. Its constructors reject negative initial values with ValueError; inputs are integers. No extra libraries are needed. This is ungraded exploration: predict before Run, then change the receiver or argument and observe which object's state and method behavior changes. Run neither submits an answer nor awards marks.

Trace attributes per object: the failed evening extension does not alter its minutes or rate. Check initial zero and extend(0), a successful positive extension, a rejected negative extension, and negative constructor values. A faulty extension that updates state before testing amount would violate the invariant even if it eventually returned False. Move the rejection before the assignment; changing only the returned Boolean does not undo state corruption.

For writing practice, construct a small class with a private state attribute, a constructor, a getter and one validated update method in an ordinary local Python IDE or OCR-style pseudocode editor. Test each public operation against its stated contract. NovaLearn's standalone pseudocode source editor preserves source for marking but does not run it; Python console execution is available only for deliberately runnable tasks. Writing a complete inherited solution and broader design trade-offs are developed further in the later implementation lesson.