Object Oriented Programming

Every object has both state (data) and behavior (operations on data). In that, they’re not much different from ordinary physical objects. It’s easy to see how a mechanical device, such as a pocket watch or a piano, embodies both state and behavior. But almost anything that’s designed to do a job does, too. Even simple things with no moving parts such as an ordinary bottle combine state (how full the bottle is, whether or not it’s open, how warm its contents are) with behavior (the ability to dispense its contents at various flow rates, to be opened or closed, to withstand high or low temperatures).

It’s this resemblance to real things that gives objects much of their power and appeal. They can not only model components of real systems, but equally as well fulfill assigned roles as components in software systems.

_{-- Object-Oriented Programming with Objective-C, Apple}

Object Oriented Programming (OOP) views the world as a network of interacting objects.

OOP solutions try to create a similar object network inside the computer’s memory – a sort of a virtual simulation of the corresponding real world scenario – so that a similar result can be achieved programmatically.

OOP does not demand that the virtual world object network follow the real world exactly.

Every object has both state (data) and behavior (operations on data).

Every object has an interface and an implementation.

Every real world object has an interface that other objects can interact with and an implementation that supports the interface but may not be accessible to the other object.

Similarly, every object in the virtual world has an interface and an implementation.

Objects interact by sending messages.

Both real world and virtual world object interactions can be viewed as objects sending message to each other. The message can result in the sender object receiving a response and/or the receiving object’s state being changed. Furthermore, the result can vary based on which object received the message, even if the message is identical (see rows 1 and 2 in the example below).

The concept of Objects in OOP is an abstraction mechanism because it allows us to abstract away the lower level details and work with bigger granularity entities i.e. ignore details data formats and the method implementation details and work at the level of objects.

Encapsulation protects an implementation from unintended actions and from inadvertent access.
_{-- Object-Oriented Programming with Objective-C, Apple}

An object is an encapsulation of some data and related behavior in two aspects:

1. The packaging aspect: An object packages data and related behavior together into one self-contained unit.

2. The information hiding aspect: The data in an object is hidden from the outside world and are only accessible using the object's interface.

Writing an OOP program is essentially writing instructions that the computer uses to,

1. create the virtual world of object network, and
2. provide it the inputs to produce the outcome we want.

A class contains instructions for creating a specific kind of objects. It turns out sometimes multiple objects have the same behavior because they are of the same kind. Instructions for creating a one kind (or ‘class’) of objects can be done in one go and use that same instructions to instantiate (i.e. create) objects of that kind. We call such instructions a Class.

Person class and some example instances of the Person class.

While all objects of a class has the same attributes, each object has its own copy of the attribute value.

However, some attributes are not suitable to be maintained by individual objects. Instead, they should be maintained centrally, shared by all objects of the class. They are like ‘global variables’ but attached to a specific class. Such variables whose value is shared by all instances of a class are called class level attributes.

Similarly, when a normal method is being called, a message is being sent to the receiving object and the result may depend on the receiving object.

However, there can be methods related to a specific class but not suitable for sending message to a specific object of that class. Such methods that are called using the class instead of a specific instance are called class-level methods.

Class-level attributes and methods are collectively called class-level members (also called static members sometimes because some programming languages use the keyword static to identify class-level members). They are to be accessed using the class name rather than an instance of the class.

📦 A Student class with a class-level attribute and a method:

An Enumeration is a fixed set of values that can be considered as a data type.

An enumeration is often useful when using a regular data type such as int or String would allow invalid values to be assigned to a variable. e.g. if a variable can only take values 0 and 1, declaring it as an int would allow invalid values such as 2 to be assigned to it. But if you define an enumeration called Binary that has values 0 and 1 only, a variable of type Binary will never be assigned an invalid value such as 2 because the compiler is able to catch the error.

📦 Priority can be considered an enumeration because it has only three values.

Priority: HIGH, MEDIUM, LOW

Connections between objects are called associations. Objects in an OO solution need to be connected to each other to form a network so that they can interact with each other. Such connections are called associations.

📦 An object diagram example showing associations among objects. For example, there is an association between the AgeList object and the Main object.

Object structures can change over time.

Associations can be reflected among classes too.

📦 An example class diagram showing associations between classes.

An association in a class diagram can use association labels and association roles to show additional info.

When two classes are linked by an association, it does not necessarily mean both classes know about each other. The concept of which class in the association knows about the other class is called navigability.

Multiplicity is the aspect of an OOP solution that dictates how many objects take part in each association.

📦 This class diagram does not tell us multiplicities. For exaple, how many Calculator objects can be associated with one Main object? How many Main objects can be associated with one Calculator object? and so on.

Dependencies are objects that are not directly linked in the object network can still interact with each other. These are a weaker form of associations we call dependencies.

A composition is an association that represents a strong whole-part relationship. When the whole is destroyed, parts are destroyed too.

📦 A Board (used for playing board games) consists of Square objects.

Composition also implies that there cannot be cyclical links.

📦 In this ‘sub-folder’ association, a Folder cannot be a sub-folder of itself. If the diamond is removed, it is no longer a composition relationship and technically, allows a folder to be sub-folder of itself.

Aggregation represents a container-contained relationship. It is a weaker relationship than composition.

📦 Club acts as a container for Person objects. Person objects can survive without a Club object.

An association class represents additional information about an association. It is a normal class but plays a special role from a design point of view.

📦 A Man class and a Woman class is linked with a ‘married to’ association and there is a need to store the date of marriage. However, that data is related to the association rather than specifically owned by either the Man object or the Woman object. In such situations, an additional association class can be introduced, e.g. a Marriage class, to store such information.

The OOP concept Inheritance allows you to define a new class based on an existing class. For example, you can use inheritance to define an EvaluationReport class based on an existing Report class so that the EvaluationReport class does not have to duplicate code that is already implemented in the Report class.

📦 Example: The EvaluationReport inherits the wordCount attribute and the print() method from the base classReport.

• Other names for Base class: Parent class, Super class
• Other names for Derived class: Child class, Sub class, Extended class

A super class is said to be more general than the sub class. Conversely, a sub class is said to be more specialized than the super class.

Applying inheritance on a group of similar classes can result in the common parts among classes being extracted into more general classes.

📦 Man and Woman behaves the same way for the 'owes money' association. However, the two classes cannot be simply replaced with a more general class Person because of the need to distinguish between Man and Woman for the ‘marriage’ association. A solution is to add the Person class as a super class and let Man and Woman inherit from Person.

Inheritance implies the derived class can be considered as a sub-type of the base class (and the base class is a super-type of the derived class), resulting in an is a relationship.

📦 In this class diagrams of a Snakes and Ladders board game,

• SnakeHeadSquareis aSquare (a SnakeHeadSquare is a square in which the head of a snake appears)
• SnakeTailSquareis aSquare

Inheritance relationships through a chain of classes can result in inheritance hierarchies (aka inheritance trees).

📦 Two inheritance hierarchies/trees are given below. Note that Parrotis aBird as well as it is anAnimal.

Multiple Inheritance is when a class inherits directly from multiple classes. Multiple inheritance is allowed among C++ classes but not among Java classes.

📦 The TA class inherits from the Staff class and the Student.

Method overriding is when a sub-class changes the behavior inherited from the parent class by re-implementing the method. Overridden methods have the same name, same type signature, and same return type.

📦 In the diagram below,

• Report#print() method is overridden by EvaluationReport#print() method.
• Report#write(String) method is overridden by EvaluationReport#write(String) method.
• Report#read():String method is NOT overridden by EvaluationReport#read(int):String method.  Reason: the two methods have different signatures; EvaluationReport#read(int):Stringoverloads (rather than overrides) the Report#read():String method.

Design → Object Oriented Programming →

Overloading

Method overloading is when there are multiple methods with the same name but different type signatures. Overloading is used to indicate that multiple operations do similar things but take different parameters.

Type Signature: The type signature of an operation is the type sequence of the parameters. The return type and parameter names are not part of the type signature. However, the parameter order is significant.

Method	Type Signature
int add(int X, int Y)	(int, int)
void add(int A, int B)	(int, int)
void m(int X, double Y)	(int, double)
void m(double X, int Y)	(double, int)

📦 In the class below, the calculate method is overloaded because the two methods have the same name but different type signatures (String) and (int[])

class RatingCalculator{
    void calculate(String matric) { ... }
    void calculate(int[] averages) { ... }
}

Method overloading is when there are multiple methods with the same name but different type signatures. Overloading is used to indicate that multiple operations do similar things but take different parameters.

class RatingCalculator{
    void calculate(String matric) { ... }
    void calculate(int[] averages) { ... }
}

An interface is a behavior specification i.e. a collection of method specifications. If a class implements the interface, it means the class is able to support the behaviors specified by the said interface.

There are a number of situations in software engineering when it is important for disparate groups of programmers to agree to a "contract" that spells out how their software interacts. Each group should be able to write their code without any knowledge of how the other group's code is written. Generally speaking, interfaces are such contracts. _{--Oracle Docs on Java}

📦 SalariedStaff is an interface that contains two methods setSalary(int) and getSalary(). AcademicStaff implements the SalariedStaff interface.  That means an AcademicStaff object is able to support the behaviors setSalary(int) and getSalary(). That's why the same two methods also appear under the methods implemented by the AcademicStaff class (in blue)

A class implementing an interface results in an is-a relationship, just like in class inheritance.

An abstract method is simply the method interface without the implementation.

📦 The Account class has an abstract method (addInterest()).

Overridden methods are resolved using dynamic binding, and therefore resolves to the implementation in the actual type of the object.

Implementation → Object Oriented Programming →

Overriding

To override a method inherited from an ancestor class, simply re-implement the method in the target class.

📦 A simple example where the Report#print() method is overridden by EvaluationReport#print() method:

class Report{

    void print(){
        System.out.println("Printing report");
    }

}

class EvaluationReport extends Report{

    @Override  // this annotation is optional
    void print(){
        System.out.println("Printing evaluation report");
    }

}

class ReportMain{

    public static void main(String[] args){
        Report report = new Report();
        report.print(); // prints "Printing report"

        EvaluationReport evaluationReport = new EvaluationReport();
        evaluationReport.print(); // prints "Printing evaluation report"
    }
}

• Java - Overriding -- a tutorial by tutorialspoint.com

Which of these methods override another method?

• a
• b
• c
• d
• e

d

Explanation: Method overriding requires a method in a child class to use the same method name and same parameter sequence used by one of its ancestors

📦 Consider the code below. The declared type of s is Staff and it appears as if the adjustSalary(int) operation of the Staff class is invoked.

void adjustSalary(int byPercent) {
    for (Staff s: staff) {
        s.adjustSalary(byPercent);
    }
}

However, at runtime the adjustSalary(int) operation of the actual object will be called (i.e. adjustSalary(int) operation of Admin or Academic). If the actual object does not override that operation, the operation defined in the immediate superclass (in this case, Staff class) will be called.

In contrast, overloaded methods are resolved using static binding.

class Account {
    Account () {
        ...
    }
    
    Account (String name, String number, double balance) {
        ...
    }
    
    void save(int amount){
        ...
    }
}

class SavingAccount extends Account{
    
    void save(Double amount){
        ...
    }
}

class Account {
    Account () {
        // Signature: ()
        ...
    }
    Account (String name, String number, double balance) {
        // Signature: (String, String, double)
        ...
    }
}

void calculateGrade (int[] averages) { ... }
void calculateGrade (String matric) { ... }

Every instance of a subclass is an instance of the superclass, but not vice-versa. As a result, inheritance allows substitutability : the ability to substitute a child class object where a parent class object is expected.

📦 an Academic is an instance of a Staff, but a Staff is not necessarily an instance of an Academic. i.e. wherever an object of the superclass is expected, it can be substituted by an object of any of its subclasses.

The following code is valid because an AcademicStaff object is substitutable as a Staff object.

Staff staff = new AcademicStaff (); // OK

But the following code is not valid  because staff is declared as a Staff type and therefore its value may or may not be of type AcademicStaff, which is the type expected by variable academicStaff.

Staff staff;
...
AcademicStaff academicStaff = staff; // Not OK

Take the example of writing a payroll application for a university to facilitate payroll processing of university staff. Suppose an adjustSalary(int) operation adjusts the salaries of all staff members. This operation will be executed whenever the university initiates a salary adjustment for its staff. However, the adjustment formula is different for different staff categories, say admin and academic. Here is one possible way of designing the classes in the Payroll system.

📦 Calling adjustSalary() method for each Staff type:

Here is the implementation of the adjustSalary(int) operation from the above design.

class Payroll1 {
    ArrayList< Admin > admins;
    ArrayList< Academic > academics;
    // ...

    void adjustSalary(int byPercent) {
        for (Admin ad: admins) {
            ad.adjustSalary(byPercent);
        }
        for (Academic ac: academics) {
            ac.adjustSalary(byPercent);
        }
    }
}

Note how processing is similar for the two staff types. It is as if the type of staff members is irrelevant to how they are processed inside this operation! If that is the case, can the staff type be "abstracted away" from this method? Here is such an implementation of adjustSalary(int):

class Payroll2 {
    ArrayList< Staff > staff;
    // ...

    void adjustSalary(int byPercent) {
        for (Staff s: staff) {
            s.adjustSalary(byPercent);
        }
    }
}

The above code is better in several ways:

• It is shorter.
• It is simpler.
• It is more flexible (this code will remain the same even if more staff types are added).

This does not mean we are getting rid of the Academic and Admin classes completely and replacing them with a more general class called Staff. Rather, this part of the code “treats” both Admin and Academic objects as one type called Staff.

For example, ArrayList staff contains both Admin and Academic objects although it treats all of them as Staff objects. However, when the adjustSalary(int) operation of these objects is called, the resulting salary adjustment will be different for Admin objects and Academic objects. Therefore, different types of objects are treated as a single general type, but yet each type of object exhibits a different kind of behavior. This is called polymorphism (literally, it means “ability to take many forms”). In this example, an object that is perceived as type Staff can be an Admin object or an Academic object.

Three concepts combine to achieve polymorphism: substitutability, operation overriding, and dynamic binding.

• Substitutability: Because of substitutability, you can write code that expects object of a parent class and yet use that code with objects of child classes. That is how polymorphism is able to treat objects of different types as one type.
• Overriding: To get polymorphic behavior from an operation, the operation in the superclass needs to be overridden in each of the subclasses. That is how overriding allows objects of different sub classes to display different behaviors in response to the same method call.
• Dynamic binding: Calls to overridden methods are bound to the implementation of the actual object's class dynamically during the runtime. That is how the polymorphic code can call the method of the parent class and yet execute the implementation of the child class.

You can use models to analyze and design a software before you start coding.

Suppose You are planning to implement a simple minesweeper game that has a text based UI and a GUI. Given below is a possible OOP design for the game.

Before jumping into coding, you may want to find out things such as,

• Is this class structure is able to produce the behavior we want?
• What API should each class have?
• Do we need more classes?

To answer those questions, you can analyze the how the objects of these classes will interact with each other to produce the behavior you want.

As mentioned in [ Design → Object Oriented Programming → Conceptualizing OO Solutions → Introduction], this is the Minesweeper design you have come up with so far. Our objective is to analyze, evaluate, and refine that design.

Design → Object Oriented Programming → Conceptualizing OO Solutions →

Introduction

You can use models to analyze and design a software before you start coding.

Suppose You are planning to implement a simple minesweeper game that has a text based UI and a GUI. Given below is a possible OOP design for the game.

Before jumping into coding, you may want to find out things such as,

• Is this class structure is able to produce the behavior we want?
• What API should each class have?
• Do we need more classes?

To answer those questions, you can analyze the how the objects of these classes will interact with each other to produce the behavior you want.

Let us start by modelling a sample interaction between the person playing the game and the TextUi object.

newgame and clear x y represent commands typed by the Player on the TextUi.

How does the TextUi object carry out the requests it has received from player? It would need to interact with other objects of the system. Because the Logic class is the one that controls the game logic, the TextUi needs to collaborate with Logic to fulfill the newgame request. Let us extend the model to capture that interaction.

W = Width of the minefield; H = Height of the minefield

The above diagram assumes that W and H are the only information TextUi requires to display the minefield to the Player. Note that there could be other ways of doing this.
The Logic methods we conceptualized in our modelling so far are:

Now, let us look at what other objects and interactions are needed to support the newGame() operation. It is likely that a new Minefield object is created when the newGame() method is called.

Note that the behavior of the Minefield constructor has been abstracted away. It can be designed at a later stage.

Given below are the interactions between the player and the Text UI for the whole game.

Continuing with the example in [ Design → Object Oriented Programming → Conceptualizing OO Solutions → Basic], next let us model how the TextUi interacts with the Logic to support the mark or clear operations until the game is won or lost.

Design → Object Oriented Programming → Conceptualizing OO Solutions →

Basic

As mentioned in [ Design → Object Oriented Programming → Conceptualizing OO Solutions → Introduction], this is the Minesweeper design you have come up with so far. Our objective is to analyze, evaluate, and refine that design.

Design → Object Oriented Programming → Conceptualizing OO Solutions →

Introduction

You can use models to analyze and design a software before you start coding.

Suppose You are planning to implement a simple minesweeper game that has a text based UI and a GUI. Given below is a possible OOP design for the game.

Before jumping into coding, you may want to find out things such as,

• Is this class structure is able to produce the behavior we want?
• What API should each class have?
• Do we need more classes?

To answer those questions, you can analyze the how the objects of these classes will interact with each other to produce the behavior you want.

Let us start by modelling a sample interaction between the person playing the game and the TextUi object.

newgame and clear x y represent commands typed by the Player on the TextUi.

How does the TextUi object carry out the requests it has received from player? It would need to interact with other objects of the system. Because the Logic class is the one that controls the game logic, the TextUi needs to collaborate with Logic to fulfill the newgame request. Let us extend the model to capture that interaction.

W = Width of the minefield; H = Height of the minefield

The above diagram assumes that W and H are the only information TextUi requires to display the minefield to the Player. Note that there could be other ways of doing this.
The Logic methods we conceptualized in our modelling so far are:

Now, let us look at what other objects and interactions are needed to support the newGame() operation. It is likely that a new Minefield object is created when the newGame() method is called.

Note that the behavior of the Minefield constructor has been abstracted away. It can be designed at a later stage.

Given below are the interactions between the player and the Text UI for the whole game.

💡 Note that a similar technique can be used when discovering/defining the architecture-level APIs.

📺 Defining the architecture-level APIs for a small Tic-Tac-Toe game:

This interaction adds the following methods to the Logic class

• clearCellAt(int x, int y)
• markCellAt(int x, int y)
• getGameState() :GAME_STATE (GAME_STATE: READY, IN_PLAY, WON, LOST, …)

And it adds the following operation to Logic API:

• getAppearanceOfCellAt(int,int):CELL_APPEARANCE (CELL_APPEARANCE: HIDDEN, ZERO, ONE, TWO, THREE, …, MARKED, INCORRECTLY_MARKED, INCORRECTLY_CLEARED)

In the above design, TextUi does not access Cell objects directly. Instead, it gets values of type CELL_APPEARANCE from Logic to be displayed as a minefield to the player. Alternatively, each cell or the entire Minefield can be passed directly to TextUi.

Here is the updated class diagram:

The above is for the case when Actor Player interacts with the system using a text UI. Additional operations (if any) required for the GUI can be discovered similarly. Suppose Logic supports a reset() operation. We can model it like this:

Our current model assumes that the Minefield object has enough information (i.e. H, W, and mine locations) to create itself.

An alternative is to have a ConfigGenerator object that generates a string containing the minefield information as shown below.

In addition, getWidth(), getHeight(), markCellAt(x,y) and clearCellAt(x,y) can be handled like this.

The updated class diagram:

How is getGameState() operation supported? Given below are two ways (there could be other ways):

1. Minefield class knows the state of the game at any time. Logic class retrieves it from the Minefield class as and when required.
2. Logic class maintains the state of the game at all times.

Here’s the SD for option 1.

Here’s the SD for option 2. Here, assume that the game state is updated after every mark/clear action.

It is now time to explore what happens inside the Minefield constructor? One way is to design it as follows.

Now let us assume that Minesweeper supports a ‘timing’ feature.

Updated class diagram: