This slide set contains a basic understanding on object oriented programming and its design concepts. The Agenda would be Objects (Instances) Classes Advantages of OOP Disadvantages of OOP Let’s Design an OOP Solution OOP Concepts UML - Unified Modelling Language UML Syntax Associations Inheritance Cohesion and Coupling

1. Object Oriented
Programming
Interview Preparation
Keet Malin Sugathadasa
Undergraduate
Department of Computer Science and Engineering
University of Moratuwa

2. Agenda
● Objects (Instances)
● Classes
● Advantages of OOP
● Disadvantages of OOP
● Let’s Design an OOP Solution
● OOP Concepts
● UML - Unified Modelling Language
● UML Syntax
● Associations
● Inheritance
● Cohesion and Coupling

3. Objects (Instances)
An Object can be used to effectively represent real world entities
● Object has
○ States (descriptive characteristics)
■ Simple Attributes- Primitive data types
■ Complex Attributes - Contains collections
○ Behaviours ( what it can do)
Example
● Keet’s Bank Account
○ State: Account number, Available balance
○ Behaviour: Make deposits, Withdraw

4. Classes
● An object is defined by a class

5. Advantages of OOP
● Code Reusing and Recycling
○ Saves development time and cost
● Encapsulation
○ Once object is created, knowledge of its implementation is not necessary for use.
● Design Benefits
○ Easy to understand. Large programs get more and more complex, but with OOP, designs can
be made with less flaws
● Software Maintenance
○ Programs are not disposable. An OOP is much easier to modify and maintain than a non-OOP

6. Disadvantages of OOP
● Size
○ OOPs are much larger than other programs
● Effort
○ OOPs require a lot of work and planning to develop
● Speed
○ OOPs are slower than other programs (Partially because of their size)

7. Object Oriented Problem Solving Approach
1. Identify the Problem
a. Carefully read the given problem and highlight the important points
2. Identify the Objects
a. Identify the main objects. Sometime two entities can be selected as one, but sometimes, it
might be better to have two instead of one complex one.
3. Identify the messages to be sent to other objects
a. Identify what kind of interactions happen between objects in classes
4. Create a sequence of messages to the objects - to solve the problem
a. Find a pattern to solve the final problem by interacting with different objects.

8. Let’s Design an OOP Solution
You need to create a Wedding Management System. Each wedding has a bride, a
groom, flower decorator, food provider, location etc. Each bride and groom has
their own parents and friends.
Find a way to model this problem into an OOP solution.
Just identifying the objects and the required interactions between them is
sufficient. Represent the interactions by simple arrows.

9. Overview of OOP

10. OOP Concepts
● Abstraction
○ Allows us to consider the important high level details
● Encapsulation
○ Allows us to consider what the program does and how it operates it. Without reading the
technical details of how it actually works
● Inheritance
○ Generalization and Specialization. Specialized objects can automatically inherit all the
characteristics of the more generalized objects.
● Polymorphism
○ Is the ability to interact with an object as its generalized category, regardless of its more
specialized category.

11. UML - Unified Modelling Language
● Class Diagrams
○ Classes show what the objects consists of and the methods
● Object Diagrams
○ Objects in the system and how they interact and the values in that object at a given state in time
● Sequence Diagrams
○ shows object interactions arranged in time sequence. How objects will interact to support one
specific function
● Package Diagrams
○ Packages and dependencies between packages

12. Class Consists of
● A unique Name
○ Conventionally starting with an Uppercase Letter
● A list of Attributes (Mostly Private)
○ Int, double, boolean, String, Complex Attributes
● A list of Methods (Mostly Public)
○ Unique method names starting with a Lowercase letter
Visibility Modifiers (Access Modifiers)
+ for public access
- for private access
UML allows us to suppress any information we do not wish to highlight in our
diagrams

13. UML Syntax
● Attributes
○ <visibility> <name> : <type> <multiplicity>
■ Eg: + custRef : int [1] → a public attribute custRef is a single int value
● Methods
○ <visibility> <name> ( <parameter 1> : <type 1> , …….) : <Return Type>
■ Eg: + addName (newName : String) : Boolean

14. Relationships Between Classes
● Some Class attributes can be complex
○ Can include some other class object as attributes
■ Eg: Teacher class has attribute → list of Students
○ String data type is a complex data type
■ Since it is part of the Java platform, it is implied that String is a primitive data type

15. Example
● ‘n’ → exactly n
● ‘*’ → zero or more
● ‘m..n; → between m and n

16. Types of Association
● Dependency A --------------------------> B
● Simple Association A B
● Bidirectional Association A B
● Aggregation A B
● Composition A B

17. Dependency
Class A in some way uses facilities defined by Class B. Changes to class B may
affect class A. There are 3 ways in which dependencies can occur
● Class A has a method, which passes as a parameter object of Class B
● Class A uses a local variable of Class B
● Class A calls static methods in Class B

18. Simple Association
Class A uses objects of Class B. Typically Class A has an attribute of Class B.
Navigability is from A to B.
● Class A objects can access Class B objects with which it is associated.
○ The reverse is not true.
Eg: Teacher wants to maintain a list of Students. So navigability is from Teacher to
Student. So Teacher object can access Student objects. But student objects do not
necessarily need access to teacher objects.

19. Bidirectional Association
This is when Class A and Class B has a two way association. Each refers to the
other class. Navigability is from A to B and B to A.
Navigability from A to B means
● Class A object can access Class B objects
● Objects of Class A “Has a” Class A
● This implies reference from A to B
Eg:
Between a “Degree” and “Student”. Given a degree, we may need to know which
students are studying on that degree. Alternatively, given a student, we may wish
to know the degree they are studying.

20. Aggregation
Aggregation denotes a situation where object(s) of Class B “Belongs to” Class B.
Aggregation also mentions that Objects of Class B, retain an existence
independent of Class A.
Eg:
We can think of tyres belonging to a car. Tyres “Belong To” Cars. But if our context
relates to a tyre shop or something, then Tyres can exist alone, in a garage as well.

21. Composition
● Composition is similar to aggregation, but implies a much stronger relationship.
● Class B objects are an integral part of Class A. In general, objects of class B
never exist other than as part of Class A. Both have the same lifetime.
Eg:
Between points, lines and shapes as elements of a picture. These objects can only
exist as part of a picture, and if the picture is deleted, they are also deleted.

22. Inheritance
Class A Class B
Class A inherits both implementation and interface of Class B.
This is how specialization and generalization works. Specialized classes can inherit
from generalized classes.

23. Interfaces
Class A Class B
● With interface inheritance, Class A will inherit only the interface of Class B.
● Class B contains only method headers
● Class A has to implement all methods defined in Class B

24. Cohesion
● Cohesion describes how closely all routines in a class or all the code in a
routing support a central purpose.
● Cohesion must be Strong.
● Classes must contain a strongly related functionality and aim for single
purpose
● Cohesion is an important tool for managing complexities

25. Coupling
● Coupling describes how tightly a class or routine is related to other classes or
routines.
● Coupling must be kept Loose.
○ Modules must depend little on each other
○ One module can be replaced easily without causing trouble
○ A module can be easily used by other modules
● Two types of Coupling
○ Tight Coupling
○ Loose Coupling