Paper 1 OOP Answers

These answers correspond to Paper 1 OOP Drills.

Answer 1: Class vs Object

Book is the class. book1 is an object, or instance, created from the Book class.

A class is the blueprint that defines attributes and methods. An object is a particular instance with actual attribute values, such as title "Algorithms" and 3 copies.

Mark points:

• identifies Book as the class;
• identifies book1 as the object/instance and explains blueprint versus instance.

Common weak answer:

• saying "Algorithms" is the object. It is an attribute value stored inside the object.

Answer 2: Attributes and Methods

Attributes:

• student_id
• name
• mark

Methods:

• update_mark(new_mark), or another clear method name such as set_mark(new_mark)
• has_passed(), or another clear method name such as is_pass()

Mark points:

• identifies student_id as an attribute;
• identifies name as an attribute;
• identifies mark as an attribute;
• gives a method for updating the mark;
• gives a method for reporting pass/fail status.

Common weak answer:

• listing Student as an attribute. Student is the class name.

Answer 3: Encapsulation

The balance should be changed through a method so the class can control how its state changes. A withdraw(amount) method can check that amount is positive and that the withdrawal will not make _balance negative before updating it. This protects the object from invalid state such as _balance = -500.

Mark points:

• private-style attribute discourages uncontrolled direct access;
• update method can validate the requested change;
• validation preserves a valid object state.

Common weak answer:

• saying private attributes are mainly to hide information from the programmer. The key purpose here is controlled access and valid state.

Answer 4: Inheritance

Person should be the superclass. Student and Teacher should be subclasses of Person.

The shared attributes name and email belong in Person. class_name belongs in Student, and department belongs in Teacher.

Mark points:

• identifies Person as superclass;
• identifies Student and Teacher as subclasses;
• puts name in the superclass;
• puts email in the superclass.

Common weak answer:

• putting all attributes in Person. Subclass-specific attributes should remain in the relevant subclass.

Answer 5: Polymorphism

This is polymorphism because both subclasses provide the same method name, send(), but the method behaves differently depending on the object. Calling send() on an EmailNotification gives "email sent", while calling send() on an SMSNotification gives "sms sent".

Mark points:

• same method name/interface;
• different subclass implementations;
• result depends on the object type.

Common weak answer:

• saying polymorphism means using many different method names. The same method call is the important idea.

Answer 6: Implementation Independence

Code using BankAccount may not need to change because it calls the public methods deposit(amount), withdraw(amount), and get_balance() rather than depending directly on how the balance is stored internally.

If the public methods keep the same names and behaviour, the class can replace one internal implementation with another. For example, it can change from storing one _balance value to storing transaction amounts, while outside code still calls the same methods.

The OOP idea is implementation independence, supported by information hiding.

Mark points:

• outside code uses public methods rather than internal storage;
• the public method names and behaviour remain stable;
• the internal representation can change from _balance to transaction records;
• calling code may not need to change;
• names implementation independence or information hiding with a clear explanation.

Common weak answer:

• saying only “it is encapsulation” without explaining that outside code depends on the public interface rather than the internal representation.

Answer 7: Generalisation

Suggested superclass: Book.

Move shared attributes into Book:

• title
• author
• pages

Keep shelf in PrintedBook and file_size in EBook.

Mark points:

• suggests a sensible superclass such as Book;
• moves shared attributes into the superclass;
• leaves subclass-specific attributes in subclasses.

Common weak answer:

• duplicating title, author, and pages in both subclasses after creating the superclass.

Answer 8: Scenario Update

Add Taxi as a new subclass of Vehicle. It should inherit registration and speed from Vehicle, and define its own subclass-specific attribute licence_number.

Mark points:

• creates Taxi as a subclass;
• reuses inherited registration and speed;
• adds licence_number only to Taxi.

Common weak answer:

• copying all Vehicle fields into an unrelated standalone Taxi class. That loses the benefit of the existing superclass.

Answer 9: Benefits

Two benefits:

• common code or state such as registration and speed is defined once in Vehicle, reducing duplication;
• shared behaviour can be maintained centrally, while new subclasses such as Taxi can extend the design with less repeated code.

Mark points:

• gives reduced duplication or reuse of common code/state;
• gives easier maintenance or extension for new subclasses.

Common weak answer:

• saying inheritance always makes programs shorter. Poor inheritance can make designs harder; it helps when there is a real is-a relationship.

Answer 10: Class Attribute vs Instance Attribute

name should be an instance attribute because each Student object has its own name. Changing s1.name should not change s2.name.

count should be a class attribute because it is shared by the Student class as a whole. It tracks a common value across all Student objects and should be updated through the class.

Mark points:

• states that name is an instance attribute;
• explains that each object has its own name;
• states that count is a class attribute;
• explains that count is shared across the class or tracks all created Student objects.

Common weak answer:

• storing count separately inside each object. That would make it difficult to keep one shared total for the class.