Object oriented programming

Object-Oriented Programming

paradigm based on objects

Objects contain:

1. data (attributes, properties) and code (methods, functions)

2. Objects are instances of classes, which determine their types

Object-Oriented Design

process of using objects and object- oriented programming when designing a software solution

Object Calling and Answering

Objects don’t accept arbitrary calls

Acceptable calls are defined by methods

Object Interface

set of method signatures for that object

Information hiding

An object can hide its state (attributes), restricting access through an interface

Client and server objects

Objects send messages by calling methods

what are messages and client objects

1. The method call is the message

2. Object calling the method is the client object

what is an interface

An interface is a set of functional properties (services) that a software object provides or requires.

On demand design

we “pull” interfaces and their implementations into existence from the needs of the client, rather than “pushing” out the features that we think a class should provide

Modular programming

software

design technique that emphasizes separating the functionality of a program into independent, interchangeable modules

Modules vs Objects

1. Modules are loose groupings of subprograms and data

2. Objects encapsulate data

UML

standardized visual language used in software engineering to represent different aspects of a system's structure and behaviour

Types of UML diagrams

1. Class diagrams: Represent the structure of a system by showing classes, their attributes, methods, and relationships.

2. Use Case Diagrams

3. Sequence Diagrams

4. Activity Diagrams

5. State Machine Diagrams

6. Component Diagrams

7. Deployment Diagrams

8. Package Diagrams: Organize and structure the elements of a system into logical groupings.

UML object relationship:Association

Association: one object accesses the other in some way

UML object relationship:Inheritance

object inherits the properties of another object through class extension

→“is a” relationship

UML object relationship:Composition

object references another object as an instance variable.

→”has a” relationship

UML object relationship:Aggregation

Aggregation implies the child class can exist without the parent

Composition implies the child class cannot exist without the parent

Object relationships

Both inheritance and composition extend the base functionality provided by another object

however:

1. Inheritance: Change in the “base” class propagates to the derived class and its client classes

2. Composition: More adaptive to change, because change in the “base” class is easily “contained” and hidden from the clients of the front-end class

Polymorphism

Polymorphism is the provision of a single interface to entities of different types. In essence, it is the ability to take on many forms

e.g Ducktyping

Types of Polymorphism

1. Compile-time Polymorphism (Static Binding or Early Binding)

2. Runtime Polymorphism (Dynamic Binding or Late Binding)

Compile-time Polymorphism

1. Decision on which method to call is made at compile time

2. Method & operator overloading

Runtime Polymorphism

1. decision about which method to call is made at runtime based on the type of the object

2. It is achieved through method overriding and interface implementation.

3. involves redefining a method in a subclass that is already defined in its superclass.

Ducktyping

an object’s type/class is less important than the methods it defines

→focus is on the object's behaviour rather than its actual type or class.

Subtyping

type of polymorphism where code written for a supertype will work on a subtype

Ad-hoc polymorphism

refers to a single name or symbol having multiple implementations depending on the arguments

Polymorphism Pros

1. Allows programmers to reuse code

2. Helps cut down on the size of code

3. Can improve the modularity of code

Polymorphism con

1. Can be very complex

2. Can make code harder to read (not sure which implementation will be called)

3. Dynamic dispatch can be slower (run-time)

Object oriented vs Process-oriented

1. Process-Oriented is more intuitive because it is person-centric (x happens then y)

2. Object-oriented may be more confusing because of labour-division

   Object-Oriented is organisation-centric, designed to scale to large problems