See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/312213177

Software Reuse and Object-Oriented Programming

Presentation · January 2017

DOI: 10.13140/RG.2.2.28395.54569

CITATIONS READS

0 1,519

1 author:

Kim Mens
Université Catholique de Louvain - UCLouvain
239 PUBLICATIONS   2,308 CITATIONS   

SEE PROFILE

Some of the authors of this publication are also working on these related projects:

Aspect Mining View project

Source code-based recommendation View project

All content following this page was uploaded by Kim Mens on 11 January 2017.

The user has requested enhancement of the downloaded file.

LINGI2252 – PROF. KIM MENS

SOFTWARE REUSE
 *

& OBJECT-ORIENTED PROGRAMMING

* These slides are part of the course LINGI2252 “Software Maintenance and Evolution”,
given by Prof. Kim Mens at UCL, Belgium
LINGI2252 – PROF. KIM MENS

A. SOFTWARE REUSE
SOFTWARE REUSE 3

REUSABILITY [DEFINITION]
Reusability is a general engineering principle whose importance
derives from the desire to avoid duplication and to capture
commonality in undertaking classes of inherently similar tasks.

Source: Peter Wegner, "Capital-Intensive Software Technology", in

Chapter 3 of Software Reusability, Volume I : Concepts and Models,
ACM Press, 1989.

Software reusability is the degree to which a software module or other

work product can be used in more than one software system.

Reusable: pertaining to a software module or other work product that

can be used in more than one computer program or software system.
SOFTWARE REUSE 4

SOFTWARE REUSE [DEFINITION]

Software reuse

The reapplication of a variety of kinds of knowledge about one

system to another in order to reduce the effort of developing or
maintaining that other system.

This “reused knowledge” includes artefacts such as domain

knowledge, development experience, requirements, architectural
components, design artefacts, code, documentation, and so forth.

Source: Software Reusability, Volume I : Concepts and Models, Eds.

Biggerstaff & Perlis, ACM Press, 1989.
SOFTWARE REUSE 5

REUSABLE COMPONENT [DEFINITION]

Software reuse

The process of implementing new software systems using existing

software information.

Reusable component

A software component designed and implemented for the specific

purpose of being reused.

Component can be requirement, architecture, design, code, test data, etc.

Source: Kang & al., Feature-Oriented Domain Analysis (FODA): Feasibility

Study, Technical Report CMU/SEI-90-TR-21, 1990.
SOFTWARE REUSE 6

SOFTWARE REUSE [EXAMPLE]

Using functions available in some library.

E.g., C libraries are collections of precompiled functions

that have been written to be reused by other programmers.

Reusing classes from another object-oriented program.

Adapting the modules of a software system with a very similar

functionality (member of a same “family”).

Reusing the architecture or design of a software system when

porting it to a new language.
SOFTWARE REUSE 7

WHY REUSE?
Economic justification:

more productive by avoiding double work

better quality by reusing good solutions

Intellectual justification:

stand on each other's shoulders

don't reinvent or reimplement old stuff

focus on what's new and relevant

SOFTWARE REUSE 8

SOME REUSE TECHNIQUES

Programming abstractions and mechanisms

procedural and data abstraction


encapsulation and information hiding

code sharing and reuse mechanisms

Design patterns

Software architecture

Software libraries & application frameworks

Generative programming & model-driven development

LINGI2252 – PROF. KIM MENS

B. OBJECT-ORIENTED PROGRAMMING
OBJECT-ORIENTED PROGRAMMING 10

OBJECT-ORIENTED PROGRAMMING PROMOTES MODULARITY AND REUSE

It is often “claimed” that object-oriented programming

is a better way of writing more modular programs

leverages code sharing and design reuse

minimises maintenance costs

Thanks to its abstraction mechanisms

OBJECT-ORIENTED PROGRAMMING 11

ABSTRACTION MECHANISMS
Encapsulation

keep data and operations that act on this data together

Information hiding

isolate and hide design and implementation choices

Polymorphism

allow for different implementations of a same design to co-exist

Code sharing

capture and exploit similarities in data and behaviour


(through inheritance)
OBJECT-ORIENTED PROGRAMMING 12

KEY OBJECT-ORIENTED CONCEPTS

Objects & Classes
DISCLAIMER
Methods & Messages
ALTHOUGH WHAT FOLLOWS MAY

Polymorphism & Dynamic Binding SEEM LIKE A CRASH COURSE IN OO


Hierarchies of classes OUR FOCUS WILL LIE ON THE

MECHANISMS IT PROVIDES FOR
Method overriding, self & super calls ACHIEVING MODULARITY,
MAINTAINABILITY, SHARING AND REUSE
Abstract classes & methods

Different kinds of inheritance

Single, Multiple, Interfaces, Mixins

OBJECT-ORIENTED PROGRAMMING 13

TWO MAIN PRINCIPLES OF OBJECT-ORIENTED PROGRAMMING

Everything is an object

Objects respond only to messages

OBJECT-ORIENTED PROGRAMMING 14

SMALLTALK’S INFLUENCE
Smalltalk is a pure object-oriented language

Was a source of inspiration to many OO languages

Ruby is heavily inspired on Smalltalk

Objective-C and Swift heavily inspired on Smalltalk

Java is heavily influenced by Smalltalk

DISCLAIMER
THIS SESSION MAY CONTAIN TRACES OF SMALLTALK CODE

(FOR DIDACTIC PURPOSES)
OBJECT-ORIENTED PROGRAMMING 15

KEY OBJECT-ORIENTED CONCEPTS

Objects & Classes

Methods & Messages

Polymorphism & Dynamic Binding

Hierarchies of classes

Method overriding, self & super calls

Abstract classes & methods

Different kinds of inheritance

Single, Multiple, Interfaces, Mixins

OBJECT-ORIENTED PROGRAMMING 16

OBJECTS ENCAPSULATE DATA

aPoint
Every object has its own data or state
x 5
Values stored in the objects
y 10
(but variables declared in classes)

Data is encapsulated aCircle

Protected from the outside world

center •
radius 2
Only accessible through messages

circumference
OBJECT-ORIENTED PROGRAMMING 17

CLASSES ENCAPSULATE BEHAVIOUR

Classes
Circle
declare the state of objects

(but objects contain the actual values) center (Point)
define the behaviour of objects
radius (Number)
method implementations

shared among all objects of a class surface π.radius2

can manipulate the state directly circumference 2.π.radius

Behaviour is encapsulated

invoked by sending message to an object

OBJECT-ORIENTED PROGRAMMING 18

CLASSES ARE FACTORIES OF OBJECTS

A class is a “factory” for producing objects of the same type

e.g., with a Circle class you can create many circle objects

Every object is an instance of the class from which it was created

A class is a blueprint for objects that share behaviour and state

All objects of a class behave in a similar fashion in response

to a same message

Enables reuse of behaviour

OBJECT-ORIENTED PROGRAMMING 19

CLASSES & OBJECTS PROMOTE MODULARITY

Through encapsulation

of both behaviour and state

grouping behaviour with the data it acts upon

facilitates modularity, code reuse and maintenance

OBJECT-ORIENTED PROGRAMMING 20

CLASSES & OBJECTS PROMOTE REUSE

Classes are fine-grained reusable components

that enable sharing and reuse of structure and behaviour

even across applications

for example via application frameworks

or reusable class hierarchies

OBJECT-ORIENTED PROGRAMMING 21

KEY OBJECT-ORIENTED CONCEPTS

▸ Objects & Classes

▸ Methods & Messages

▸ Polymorphism & Dynamic Binding

▸ Hierarchies of classes

▸ Method overriding, self & super calls

▸ Abstract classes & methods

▸ Different kinds of inheritance

▸ Single, Multiple, Interfaces, Mixins

OBJECT-ORIENTED PROGRAMMING 22

METHODS & MESSAGES (RECAP)

Objects (not functions or procedures) are the main building blocks
of OO

Objects communicate through message passing

Objects exhibit behaviour in response to messages sent to

them

The actual behaviour is implemented in methods

Methods specify what behaviour to perform on objects

Methods can manipulate the objects’ internal state

OBJECT-ORIENTED PROGRAMMING 23

POLYMORPHIC METHODS
A same message can be sent to objects of different classes

aCircle.surface aRectangle.surface

Different objects can react differently to the same message

different classes can provide different implementations


for methods with the same name
2

Circle > surface = π.radius
Rectangle > surface = (bottom-top).(right-left)

Responsibility of how to handle the message is decided by the object


(depending on the class to which it belongs)

This is called “polymorphism”

OBJECT-ORIENTED PROGRAMMING 24

ADVANTAGES OF POLYMORPHISM
Cleaner, more maintainable code

Less ≠ method names

Less need for conditionals

More implementation freedom

Each class can decide how best to implement a method

Locality

Every object/class is responsible for its own actions

Easy to change the implementation by another one

OBJECT-ORIENTED PROGRAMMING 25

EXAMPLE OF POLYMORPHISM
Procedural style vs. object-oriented style

Example:

Write some code that calculates the sum of the surfaces of

a collection of different shape objects

surface(collection) = Σshape∈collection surface(shape)

OBJECT-ORIENTED PROGRAMMING 26

EXAMPLE OF POLYMORPHISM (PSEUDOCODE)

Procedural style (no polymorphism)
circleSurface(c) = π.radius(c)2


rectangleSurface(r) = (bottom(r) - top(r)) * (right(r) - left(r))


surface(collection) : Real
total = 0
∀ shape ∈ collection :
if ( shape == Circle ) then
total = total + circleSurface(shape)
else if ( shape == Rectangle ) then
total = total + rectangleSurface(shape)
return total
OBJECT-ORIENTED PROGRAMMING 27

EXAMPLE OF POLYMORPHISM (PSEUDOCODE)

OO style (using polymorphism)
Circle {
Point center ; Real radius ;
Real surface() : { π.radius2 }
}
Rectangle {
Real bottom, top, right, left;
Real surface() : { (bottom-top)*(right-left) }
}
Real surface(collection) : {
total = 0
∀ shape ∈ collection : total = total + shape.surface()
return total

}
OBJECT-ORIENTED PROGRAMMING 28

EXAMPLE OF POLYMORPHISM (PSEUDOCODE)

OO style (using polymorphism)


Real surface(collection) : {
total = 0
∀ shape ∈ collection : total = total + shape.surface()
return total

}


Advantages:

Adding a new shape does not require to change the existing

implementation

No need to know the kind of objects it manipulates as long as they

all share a common interface
OBJECT-ORIENTED PROGRAMMING 29

LATE BINDING
When sending a message, the actual receiver of a message is not
necessarily known until run-time

Mapping of messages to methods is deferred until run-time

depending on which object actually received the message

we call this late binding or dynamic binding

Most traditional languages do this at compile time (static binding)

Smalltalk uses late binding aCircle

aRectangle surface
aTriangle
OBJECT-ORIENTED PROGRAMMING

EXAMPLE OF LATE BINDING (PSEUDOCODE)

Circle {
Point center ; Real radius ;
2
Real surface() : { π.radius } polymorphic methods
}

Rectangle {
Real bottom, top, right, left;
Real surface() : { (bottom-top)*(right-left) }
}

test() : { late bound messages

shape = new Circle(new Point(0,0), 2);
print(shape.surface());
shape = new Rectangle(10,10,30,50);
print(shape.surface())
}
OBJECT-ORIENTED PROGRAMMING 31

STATIC VS. DYNAMIC BINDING IN JAVA

Smalltalk uses dynamic binding (a.k.a. late binding)

For Java it depends

Binding of overridden methods happens at runtime (dynamic)

Binding for overloaded methods at compile time (static)

Binding of private, static and final methods at compile time (static)

since these methods cannot be overridden.

Sources:

http://beginnersbook.com/2013/04/java-static-dynamic-binding/

http://stackoverflow.com/questions/19017258/static-vs-dynamic-binding-in-java
OBJECT-ORIENTED PROGRAMMING

Apart from syntactic differences and

LATE BINDING EXAMPLE (JAVA) the lack of type declarations in
Smalltalk, this example could be
recreated nearly “as is” in Smalltalk.

In fact for Smalltalk you could even

create an example that doesn’t
require inheritance.

Source: http://stackoverflow.com/questions/19017258/static-vs-dynamic-binding-in-java
OBJECT-ORIENTED PROGRAMMING

LATE BINDING EXAMPLE IN JAVA

The method call vehicle.start()

is dynamically bound to the
overridden Car > start() method

Because even though vehicle is

typed as being of class Vehicle,
it is determined at runtime that
it contains an object of type Car

and because the method start()

is overridden
OBJECT-ORIENTED PROGRAMMING 34

STATIC BINDING EXAMPLE IN JAVA

Source: http://stackoverflow.com/questions/19017258/static-vs-dynamic-binding-in-java
OBJECT-ORIENTED PROGRAMMING 35

This example cannot be recreated in

STATIC BINDING EXAMPLE IN JAVA Smalltalk since Smalltalk has no
method overloading.

(Nor does it have final methods or

private methods.)

The method call et.sort(c)


is statically determined by

the compiler to refer to

the sort(Collection) method

Even though c is an object of type

HashSet and the sort(HashSet) method
is more specific

Because c is statically

determined to have type Collection

and the method sort is overloaded, not

overridden
OBJECT-ORIENTED PROGRAMMING 36

CLASSES & OBJECTS PROMOTE MODULARITY

Through information hiding

restricted access to objects through a well-defined interface

users of an object only know the set of messages it will accept

they do not know how the actions performed in response to a message

are carried out

This is the responsibility of the receiving object (through polymorphism)

improves modularity by hiding implementation details

How the data is represented internally

How the behaviour is implemented in terms of that data

OBJECT-ORIENTED PROGRAMMING 37

KEY OBJECT-ORIENTED CONCEPTS

▸ Objects & Classes

▸ Methods & Messages

▸ Polymorphism & Dynamic Binding

▸ Hierarchies of classes

▸ Method overriding, self & super calls

▸ Abstract classes & methods

▸ Different kinds of inheritance

▸ Single, Multiple, Interfaces, Mixins

OBJECT-ORIENTED PROGRAMMING 38

HIERARCHIES OF CLASSES

Shape
colour (Colour)

Rectangle Circle
bottom top center radius
left right surface π.radius2

surface height*width circumference 2.π.radius

circumference 2.height+2.width
OBJECT-ORIENTED PROGRAMMING 39

HIERARCHIES OF CLASSES
Classes are typically organised into hierarchical structures

Information (data/behaviour) associated with classes higher in the

hierarchy is automatically accessible to classes lower in the hierarchy

Each subclass specialises the definition of its ancestors

subclasses can use ancestor’s behaviour and state

subclasses can add new state and behaviour

subclasses can specialise ancestor behaviour

subclasses can override ancestor’s behaviour

OBJECT-ORIENTED PROGRAMMING 40

HIERARCHIES OF CLASSES
Inheritance is a powerful incremental reuse mechanism Container
colour contents
Often you don’t want to rewrite everything; you just want some
small changes to what exists

Classes are the units of reuse

Vehicle
velocity location
Inheritance is the reuse mechanism

e.g., extends keyword in Java :


class Automobile extends LandVehicle
LandVehicle
wheels
Class hierarchies are ideal for sharing declarations and
implementation among classes
Automobile
Object’s state and behavioural description is broken into
pieces and distributed along specialisation paths brand

Promotes encapsulation, modularity, and reusability

OBJECT-ORIENTED PROGRAMMING 41

KEY OBJECT-ORIENTED CONCEPTS

▸ Objects & Classes

▸ Methods & Messages

▸ Polymorphism & Dynamic Binding

▸ Hierarchies of classes

▸ Method overriding, self & super calls

▸ Abstract classes & methods

▸ Different kinds of inheritance

▸ Single, Multiple, Interfaces, Mixins

OBJECT-ORIENTED PROGRAMMING 42

SELF AND SUPER CALLS

Methods use:

self calls to reference the receiver object

this keyword in Java, self in Smalltalk

super to reference their implementor’s parent

Attention ! Key issue in object-oriented programming:

self = late/dynamically bound

method lookup starts again in the class of the receiver object

super = statically bound

method lookup starts in the superclass of the class of the method


containing the super expression;

not in the superclass of the receiver class

OBJECT-ORIENTED PROGRAMMING 43

SELF REFERS TO THE RECEIVER CLASS

SomeSuperclass {
void printMyself : {
self.print self refers to the receiver object
}
void print : { receiver class is SubSubclass
display("Printed in superclass. ")
}
self will dynamically look up
}
SomeSubclass inherits from SomeSuperclass {
methods starting from this class
void print : {
super.print
display("Printed in subclass.”)
}
}
SubSubclass inherits from SomeSubclass {
}
test : {
s = new SubSubclass()
s.printMyself
}
}
OBJECT-ORIENTED PROGRAMMING 44

METHOD OVERRIDING
Subclasses can re-implement methods that are already implemented in
superclasses

enables fine-grained reuse

clients do not have to know this (encapsulation and polymorphism)

An overridden method

can either overwrite a method with a completely new implementation

or can specialise the behaviour of the method defined in its superclass

special keyword for accessing the superclass : super

OBJECT-ORIENTED PROGRAMMING 45

EXAMPLE OF METHOD SPECIALISATION

SomeSuperclass {
void print : { overridden method
display("Printed in superclass. ")
}
}
SomeSubclass inherits from SomeSuperclass {
void print : { overriding method
super.print specialises overridden method

display("Printed in subclass.”) using super keyword
}
}
test : {
s = new SomeSubclass()
s.print
}
}

After calling test, the program prints:

Printed in superclass. Printed in subclass.
OBJECT-ORIENTED PROGRAMMING 46

SUPER IS NOT THE SUPERCLASS OF THE RECEIVER CLASS

SomeSuperclass {
void print : {
display("Printed in superclass. ")
}
}
super statically refers to
SomeSubclass inherits from SomeSuperclass { this class
void print : {
super.print
display("Printed in subclass.”)
}
}
SubSubclass inherits from SomeSubclass {
}
test : {
s = new SubSubclass()
s.print
receiver class is SubSubclass
}
}
if super would refer to
After calling test, the program prints: the super class of the receiver
Printed in superclass. Printed in subclass. class, we would get a loop
OBJECT-ORIENTED PROGRAMMING 47

KEY OBJECT-ORIENTED CONCEPTS

▸ Objects & Classes

▸ Methods & Messages

▸ Polymorphism & Dynamic Binding

▸ Hierarchies of classes

▸ Method overriding, self & super calls

▸ Abstract classes & methods

▸ Different kinds of inheritance

▸ Single, Multiple, Interfaces, Mixins

OBJECT-ORIENTED PROGRAMMING 48

CONCRETE VS. ABSTRACT CLASSES

Abstract Class
Container
Holds on to common characteristics shared
colour contents
by other classes

Not expected to have instances Vehicle

velocity location
Concrete Class

Contains complete characterisation
 LandVehicle AirVehicle

of actual objects of that class
wheels wings

Expected to have instances

OBJECT-ORIENTED PROGRAMMING 49

ABSTRACT CLASSES AND ABSTRACT METHODS

cannot be instantiated (in Java)

but can provide some method implementations

methods of which the implementation is shared by all subclasses

methods with a default implementation to be specialised by subclasses

methods with a partial implementation to be completed by a subclass

(e.g., template method pattern)

typically have at least one abstract method

a method with an empty implementation that must be provided by each

subclass
OBJECT-ORIENTED PROGRAMMING 50

KEY OBJECT-ORIENTED CONCEPTS

▸ Objects & Classes

▸ Methods & Messages

▸ Polymorphism & Dynamic Binding

▸ Hierarchies of classes

▸ Method overriding, self & super calls

▸ Abstract classes & methods

▸ Different kinds of inheritance

▸ Single, Multiple, Interfaces, Mixins

OBJECT-ORIENTED PROGRAMMING 51

KINDS OF INHERITANCE
Different kinds of inheritance

Single: 1 superclass

Multiple: 1 or more superclasses

Interface

Mixin modules
OBJECT-ORIENTED PROGRAMMING 52

SINGLE INHERITANCE
Organises classes in tree structures

Every class has a unique superclass

There is a root class, typically called Object

OBJECT-ORIENTED PROGRAMMING 53

SINGLE INHERITANCE PROBLEMS

Classes can play several roles

Factories from which instances can be created

Units of reuse

Inheritance can play several roles

code reuse

design reuse

These roles can conflict

Multiple inheritance to the rescue… ?

OBJECT-ORIENTED PROGRAMMING 54

MULTIPLE INHERITANCE
Sometimes it is convenient to have a Vehicle
class which has multiple parents velocity location

Some languages, like C++,


support multiple inheritance LandVehicle AirVehicle
wheels wings
Subclasses inherit instance variables
and methods from all parents
FlyingCar

https://en.wikipedia.org/wiki/Multiple_inheritance
OBJECT-ORIENTED PROGRAMMING 55

THE DIAMOND PROBLEM

A problem arises when the same methods or Vehicle
variables are inherited via different paths velocity location
e.g. what version of location method to use
when called on FlyingCar?
LandVehicle AirVehicle
duplicated behaviour wheels location wings location

can be solved through manual overriding

or through linearisation
FlyingCar
duplicated state

harder to solve
OBJECT-ORIENTED PROGRAMMING 56

INTERFACES
Java has single inheritance

Java interfaces were introduced to provide some of the

functionality of true multiple inheritance

You can inherit from one class and from multiple interfaces

simultaneously

Interfaces are like abstract classes with no fields or method

implementations

No diamond problem since interfaces contain no data or behaviour

http://stackoverflow.com/questions/3556652/how-do-java-interfaces-simulate-multiple-inheritance
OBJECT-ORIENTED PROGRAMMING 57

EXAMPLE OF USING INTERFACES

If Java has no multiple inheritance

then how should I do something like this?

class FoodTruck extends Truck, Kitchen {

}
Truck Kitchen
drive cook
foodTruck.drive();
foodTruck.cook(pizza);

FoodTruck

http://stackoverflow.com/questions/3556652/how-do-java-interfaces-simulate-multiple-inheritance
OBJECT-ORIENTED PROGRAMMING 58

EXAMPLE OF USING INTERFACES

class FoodTruck extends Truck implements KitchenInterface {
Kitchen kitchen;
public void cook(Food foodItem) {
kitchen.cook(foodItem);
}
class interface
}
Truck KitchenInterface
foodTruck.drive(); drive cook
foodTruck.cook(pizza);
class
 interface

inheritance inheritance

FoodTruck Kitchen
cook cook

http://stackoverflow.com/questions/3556652/how-do-java-interfaces-simulate-multiple-inheritance
OBJECT-ORIENTED PROGRAMMING 59

MIXINS
Factoring out the increment when subclassing

Mixins can be seen as the “increment” that needs to be applied to a class

Mixin composition is an operation that applies a mixin to a class to produce a

more specialised class

Typically, mixin composition is linearised

this can cause problems:

composition order important

introducing extra mixin can change behaviour

Example: mixin modules in Ruby

OBJECT-ORIENTED PROGRAMMING 60

CONCLUSION
OO promotes maintainability by viewing programs as collections of loosely connected
objects

Each object is responsible for specific tasks

It is through the interaction of objects that computation proceeds

Objects can be defined and manipulated in terms of the messages they understand
and ignoring the implementation details

OO promotes the development of reusable components

By reducing the interdependency among individual software components

Such components can be created and tested as independent units in isolation from the
rest of the software system

Reusable software components permit to treat problems at a higher level of abstraction

OBJECT-ORIENTED PROGRAMMING 61

ABSTRACTION MECHANISMS (REVISITED)

Encapsulation

objects contain their own data as well as the methods that work on that data

Information hiding

clients of an object know only the set of messages it can receive

implementation details of how it processes these messages remain hidden to external clients

Polymorphism

cleaner and more maintainable code by delegating responsibilities and implementation choices
to the objects

Code sharing

classes enable sharing behaviour among objects

class hierarchies and inheritance enable reuse of class definitions

LINGI2252 – 3. SOFTWARE REUSE

LEARNING OBJECTIVES
▸ definitions of reusability, software reuse and reusable component

▸ how object-oriented programming promotes modularity, maintainability and

reuse

▸ encapsulation, information hiding, polymorphism and code sharing

▸ key object-oriented concepts: object, classes, methods, messages, inheritance

▸ polymorphism and dynamic binding

▸ method overriding, self and super calls

▸ abstract classes and methods

▸ different kinds of inheritance: single, multiple, interfaces, mixins

LINGI2252 – 3. SOFTWARE REUSE

POSSIBLE QUESTIONS
▸ Define and illustrate, in your own words, the notions of software reuse, reusability and reusable
components.

▸ Give two economic and two intellectual justifications for software reuse.

▸ Give (and explain) at least 3 different software reuse techniques seen throughout the course.

▸ How and why does object-oriented programming promote modularity and maintainability?

▸ Explain the object-oriented techniques of encapsulation, information hiding, polymorphism and code
sharing and their link with software reusability.

▸ Explain, using a concrete example, what polymorphism and dynamic binding is, and how it can lead to
more maintainable code.

▸ Explain on a concrete example the concepts of method overriding, self and super calls.

▸ How can abstract classes and methods improve reusability?

▸ Explain, using a concrete example, how a multiple inheritance problem could be modelled in terms of
single inheritance on classes and interfaces in Java.

View publication stats