IB Computer Science Topic B3.1.1: Evaluating the Fundamentals of OOP Notes

Object-Oriented Programming: Modelling a System as Interacting Objects

1. A procedural program separates the two: data sits in variables and functions act on it from outside.
2. OOP puts them together, so a program about a library contains Book objects that hold their own title and know how to lend themselves out.
3. This statement asks you to evaluate the paradigm, so you need the five concepts below *and* an argued view of when OOP is the right choice.

The Five Concepts You Must Be Able to Model

1. Class
   1. A blueprint that defines the attributes and methods every object of that type will have.
   2. A class holds no data of its own until objects are made from it.
2. Object
   1. An instance of a class, holding its own values for the attributes the class defined.
   2. Two Book objects made from the same class carry different titles.
3. Encapsulation
   1. Bundling attributes and the methods that operate on them inside one class, and restricting outside access to the attributes.
   2. A BankAccount keeps its balance private, so no outside code can set it to a negative number.
4. Inheritance
   1. A subclass takes on the attributes and methods of a superclass and then adds or changes its own.
   2. A Vehicle superclass holds owner and mass; Car and Airplane inherit both and add fuelType and maxRange.
5. Polymorphism
   1. One method name behaving differently depending on the object it is called on.
   2. Calling draw() on a Circle and on a Square runs different code through the same instruction.

Advantages of OOP

1. Code reusability
   1. Inheritance lets a subclass reuse a superclass's tested code instead of copying it.
   2. A Car class inherited by ElectricCar keeps one copy of the shared braking logic.
2. Modularity
   1. Encapsulation splits a system into classes that can be understood and changed one at a time.
   2. Changing how BankAccount stores its balance does not break any class that only calls deposit().
3. Real-world modelling
   1. Classes map onto the entities a problem already talks about, so the design follows the problem description.
   2. A school system needs Student, Teacher and Course objects, which is how a school describes itself.
4. Concurrent development
   1. Because classes communicate only through their public methods, separate programmers can build different classes at the same time.
   2. One developer writes Payment while another writes Order, agreeing only on the method names between them.
5. Controlled access to data
   1. Private attributes reached only through public methods let the class validate every change before accepting it.
   2. A withdraw() method can refuse an amount larger than the balance; a public balance variable cannot.

Disadvantages of OOP

1. Added complexity for small problems
   1. A class, a constructor and a driver class are a lot of structure around a task a few lines of procedural code would finish.
   2. A script that converts a temperature does not benefit from a Temperature class.
2. Performance and memory overhead
   1. Every object carries its own copy of the instance variables, and creating and destroying objects costs processing time.
   2. This matters on an embedded controller with kilobytes of RAM, where procedural code is often chosen instead.
3. Steeper learning curve
   1. The paradigm has to be learned before any of it pays off, and inheritance and polymorphism are where beginners stall.
   2. A team new to OOP can produce a worse design than the procedural one it replaced.
4. Over-engineering through inheritance
   1. Deep inheritance hierarchies couple classes tightly, so a change to a superclass ripples through every subclass below it.
   2. Composition is often the better answer where the relationship is "has-a" rather than "is-a".

Choosing the Paradigm: OOP Suits Some Problems and Not Others

1. The examinable skill is matching the paradigm to a given scenario, so work through the shape of the problem rather than reaching for a verdict.
2. Reach for OOP when
   1. The problem describes several kinds of entity with their own data and behaviour, such as a hospital booking system with Patient, Doctor and Appointment.
   2. Many similar items each need their own state, such as every enemy in a game tracking its own health and position.
   3. A team is building the system and needs to divide it into independent parts.
   4. The system is expected to grow, so new types can be added as new classes.
3. Reach for procedural code when
   1. The task is a short sequence of steps on one data set, such as reading a file and printing a total.
   2. Hardware is constrained and the object overhead is not affordable.
   3. The program is a one-off utility that nobody will extend.

Modelling One Entity End to End: The Book Class

1. Working one entity through the whole paradigm shows where each concept lands.
2. A library needs to track books, so Book becomes the class and each physical book becomes an object.
   1. Title, author and isOnLoan are the attributes; lend() and returnBook() are the methods.
   2. The attributes are private and reached only through methods, which is encapsulation.
   3. If the library later adds audiobooks, an Audiobook subclass inherits Book and adds duration.
   4. Calling describe() on a Book and on an Audiobook produces different output, which is polymorphism.
3. At standard level you would build the Book class and a driver class only, stopping before the subclass.