Chapter 3: Demonstrate object-oriented programming skills

Object-oriented programming (OOP) is a fundamental paradigm that enables software developers to structure code in a way that models real-world entities through objects and classes. In Kenya’s dynamic software development industry, OOP facilitates the creation of modular, reusable, and maintainable code, which is essential for the development of scalable applications in sectors such as banking, healthcare, and e-commerce. This chapter focuses on demonstrating essential OOP skills with particular emphasis on namespaces, a vital feature for organizing code and preventing naming conflicts especially in large projects or collaborative environments. Mastery of namespaces allows Kenyan software professionals to build robust applications that are easier to maintain and extend.

3.1 Implementing Objects and Classes

Object-oriented programming builds software from objects that model the things a program deals with. Each object is created from a class, which describes what every object of that kind knows and can do. This topic follows one running situation: a program that keeps track of the stock of a hardware shop. It starts with the two core ideas, moves to the parts of a class, builds and runs a small program, and ends with a team exercise in which each member writes a different class from one shared design. The code is written in Java, the language used throughout this unit. The ideas are the same in C#, C++ and Python, and only the syntax changes.

3.1.1 Overview of objects and classes in OOP

An object is a single, identifiable item inside a running program. It has state, which is the data it holds, and behaviour, which is what it can do. A class is the description from which objects are built: it lists the fields that hold the state and the methods that carry out the behaviour. Creating an object from a class is called instantiation, and the object is called an instance of the class.

Example: in the stock program, StockItem is a class. One object is the hinge sets on the shelf, with the name "Hinge set", a quantity of 12 and a unit price of Ksh 450. Another object is the 4-litre tins of paint, with its own name, quantity and price. Both objects follow the same class, but each keeps its own values.

Class and object compared:

The main parts of a class:

• Fields: Variables that store the state of each object, such as name, quantity and unitPrice.
• Constructor: A special block that runs when an object is created and sets its starting values.
• Methods: Named blocks of code that give the object its behaviour, such as calculating the value of the stock.
• Access modifiers: Words such as public and private that control which code may use a field or method.
• The this reference: A name that stands for the object currently running the code, used to tell a field apart from a parameter with the same name.

Three properties make objects useful. Each object has an identity, so two objects with equal values are still two objects. The state of one object is separate from the state of another, so selling hinge sets does not change the paint. The behaviour is stored with the data, so code that needs the stock value asks the object for it instead of repeating the calculation.

3.1.2 Implementation of classes

To implement a class, the developer turns a description of a thing into code: a class declaration, its fields, a constructor and its methods. The class is then compiled and used by other code. In Java, each public class is saved in a file with the same name as the class, so the class StockItem is saved in StockItem.java.

How the parts of a class are written in Java:

Steps to implement a class:

1. Identify the thing the program must handle and write its name as a singular noun, such as StockItem. Class names start with a capital letter and use capitals for each new word.
2. List the data every object must keep, for example the item name, the quantity in stock and the unit price, and choose a data type for each: String, int and double.
3. Declare each piece of data as a field inside the class. Declare fields private so that other classes cannot change them directly. Encapsulation is taught in full in Applying Object Encapsulation.
4. Write a constructor with the same name as the class and no return type. Give it one parameter for each value an object needs at the start, and copy each parameter into its field using this.
5. Add methods for what the object must do. A method that reports a value, such as stockValue, returns it. A method that changes the state, such as sell, can return nothing.
6. Compile the class with the command javac StockItem.java. Read each error message from the first one, because later errors are often caused by the first.
7. Test the class from another class that creates objects and calls their methods, as shown in the next sub-topic.

Two rules are worth knowing early. If a class declares no constructor, Java supplies a constructor with no parameters that leaves the fields at their default values: 0 for numbers and null for text. As soon as the class declares any constructor, that supplied constructor is no longer provided. Members marked static belong to the class itself and are shared by every object, while members without static belong to each object separately.

3.1.3 Creating a simple class and instantiating objects to demonstrate understanding

A good proof that a learner understands classes is a short program that defines a class, creates objects from it and shows that each object keeps its own state. The program below uses two files. StockItem.java holds the class and ShopDemo.java holds the main method that creates the objects.

StockItem.java:

public class StockItem {
    private String name;
    private int quantity;
    private double unitPrice;

    public StockItem(String name, int quantity, double unitPrice) {
        this.name = name;
        this.quantity = quantity;
        this.unitPrice = unitPrice;
    }

    public double stockValue() {
        return quantity * unitPrice;
    }

    public void sell(int units) {
        if (units > 0 && units <= quantity) {
            quantity = quantity - units;
        } else {
            System.out.println("Cannot sell " + units + " of " + name);
        }
    }

    public String describe() {
        return String.format("%s: %d in stock at Ksh %.2f each", name, quantity, unitPrice);
    }
}

ShopDemo.java:

public class ShopDemo {
    public static void main(String[] args) {
        StockItem hinges = new StockItem("Hinge set", 12, 450.0);
        StockItem paint = new StockItem("Paint 4 litre", 5, 2100.0);

        System.out.println(hinges.describe());
        System.out.println(paint.describe());

        hinges.sell(3);
        paint.sell(8);

        System.out.println(hinges.describe());
        System.out.println(paint.describe());
        System.out.printf("Value of hinges: Ksh %.2f%n", hinges.stockValue());
    }
}

Compile both files with javac StockItem.java ShopDemo.java and run the program with java ShopDemo. The output is:

Hinge set: 12 in stock at Ksh 450.00 each
Paint 4 litre: 5 in stock at Ksh 2100.00 each
Cannot sell 8 of Paint 4 litre
Hinge set: 9 in stock at Ksh 450.00 each
Paint 4 litre: 5 in stock at Ksh 2100.00 each
Value of hinges: Ksh 4050.00

Reading the program step by step:

1. The expression new StockItem("Hinge set", 12, 450.0) creates an object in memory and runs the constructor, which stores the three values in its fields. The reference to the object is kept in the variable hinges.
2. The second new creates a separate object for the paint. The two objects now exist side by side with different values.
3. The first two describe calls print the starting state of each object.
4. hinges.sell(3) changes only the hinge object: 12 − 3 = 9. The condition units <= quantity is true, so the stock is reduced.
5. paint.sell(8) fails the same test because 8 is more than the 5 in stock. The object prints a message and its state does not change.
6. The last describe calls show 9 hinge sets and still 5 tins of paint, which proves that the objects keep separate state.
7. The stock value of the hinges is 9 × 450 = 4,050.

Common mistakes when creating objects:

• Forgetting new: Writing StockItem hinges = StockItem("Hinge set", 12, 450.0); does not compile, because the constructor must be called with new.
• Wrong arguments: Passing the values in the wrong order, such as 450.0 before 12, causes a type error or a wrong stock value. The arguments must match the constructor's parameters in number, type and order.
• File name mismatch: A public class named StockItem saved in a file called Item.java is refused by the compiler.
• Calling a method on the class: Writing StockItem.describe() fails because describe belongs to an object, not to the class itself.
• Using an object that was never created: A variable that holds null, such as StockItem shelf = null; or a field of a class that was never assigned, refers to no object, and calling a method on it stops the program with a NullPointerException. A local variable with no value at all is refused by the compiler before the program runs.

Practice task: add a method restock(int units) that adds to the quantity only when units is above zero, create a third object for a box of nails, call restock on it and print its state.

3.1.4 Participating in a group project where each member implements a different class based on a shared design

Software for real clients is written by teams. One way to share the work is to agree a design first, give each member one class to build, and then join the classes together. Each member must follow the agreed design exactly so that the classes fit when they are combined.

Understanding the shared design

A shared design states which classes the system needs, what each one stores and which public methods it offers, with the exact method names, parameters and return types. It may be drawn as a UML class diagram or written as a table. Every member reads the whole design, not only their own class, because their class will call the methods of the others.

Example: three trainees build a booking program for a car wash. The shared design is:

Division of responsibilities

Each member owns one class and writes, compiles and tests it alone, without editing a class owned by someone else. This allows parallel progress without two people changing the same file. A change to the design, such as a new method, is discussed with the whole team and written into the design first.

Ensuring interface compatibility

Classes work together through their public methods, so the names, parameter types and return types agreed in the design must be followed exactly. Member C writes the Booking class knowing only that WashBay has an occupy method and a getNumber method. If Member B renamed occupy to take, Booking would fail to compile when the classes are joined.

The three classes written by the three members:

public class Customer {
    private final String name;
    private final String phone;

    public Customer(String name, String phone) {
        this.name = name;
        this.phone = phone;
    }

    public String getName() {
        return name;
    }

    public String getPhone() {
        return phone;
    }
}

public class WashBay {
    private final int number;
    private boolean free = true;

    public WashBay(int number) {
        this.number = number;
    }

    public int getNumber() {
        return number;
    }

    public boolean isFree() {
        return free;
    }

    public void occupy() {
        free = false;
    }

    public void release() {
        free = true;
    }
}

public class Booking {
    private final Customer customer;
    private final WashBay bay;
    private final String service;
    private final double price;

    public Booking(Customer customer, WashBay bay, String service, double price) {
        this.customer = customer;
        this.bay = bay;
        this.service = service;
        this.price = price;
        bay.occupy();
    }

    public String summary() {
        return String.format("%s booked %s in bay %d for Ksh %.2f",
                customer.getName(), service, bay.getNumber(), price);
    }
}

Version control and collaboration tools

A tool such as Git keeps every version of the project in one shared repository. Each member works on a separate branch for their class and merges it into the main branch when it compiles and passes its own tests. Git records who changed what, lets the team compare versions, and helps them resolve a conflict if two people edited the same lines.

Code integration and testing

After the classes are written, the team joins them and tests them together. An integration test creates objects of every class and checks that they cooperate. The test below books a bay for a customer and checks that the bay becomes taken:

public class Main {
    public static void main(String[] args) {
        Customer customer = new Customer("Wanjiru", "0700 000 001");
        WashBay bay = new WashBay(1);

        if (bay.isFree()) {
            Booking booking = new Booking(customer, bay, "full wash", 600.0);
            System.out.println(booking.summary());
        }

        if (!bay.isFree()) {
            System.out.println("Bay " + bay.getNumber() + " is now taken");
        }
    }
}

Output:

Wanjiru booked full wash in bay 1 for Ksh 600.00
Bay 1 is now taken

The price and the customer details are values chosen for the exercise. When the integration test fails, the team reads the error to find which class and which method do not match the design, and the owner of that class repairs it. Teams that use continuous integration let a server compile and test the whole project after every merge, so an interface mismatch is found within minutes.

Communication and documentation

Short regular meetings help the team share progress and ask questions before small doubts become integration faults. Each class carries comments that say what its methods do, and the design document is updated whenever the team agrees a change. Clear documentation lets a member who joins late, or who must repair a class written by someone else, understand it without guessing.

Chapter Summary

This chapter provided a comprehensive demonstration of object-oriented programming skills, beginning with defining class methods that meet application requirements and emphasizing best practices for method naming and functionality. It explored the development of classes with multiple methods and their practical use in small applications, followed by conducting code reviews to ensure method declarations align with the intended application needs. The role of namespaces was examined to organize code effectively, including implementation techniques and the benefits of using namespaces in collaborative environments. Data abstraction concepts were introduced, highlighting their importance and practical implementation through abstract classes and pair programming exercises. The chapter also covered object encapsulation, detailing access modifiers such as private, public, and protected, and demonstrated encapsulation advantages through class design and presentations. Further, the use of class templates was discussed, focusing on creating generic templates and applying them to various data types in collaborative projects. Finally, the chapter addressed class inheritance by explaining different types and applying them in program hierarchies, and concluded with polymorphism, detailing its compile-time and runtime forms, practical implementation, and the benefits of polymorphism in software development.