Lecture 01: Introduction to

Object Oriented Programming

SE116 - Introduction to Programming II
Lecturer Information
● Lecturers:
○ Prof. Dr. Hüseyin Akcan
○ Asst. Prof. Dr. Kutluhan Erol
○ Asst. Prof. Dr. İlker Korkmaz
● Use email instead of OASIS when you are asking questions.
● Textbook: Deitel, Java How to Program
Course Information
● Evaluation
○ Laboratory: 10%
○ Project: 20%
○ Midterm: 30%
○ Final: 40%
● Project details will be announced later.
Syllabus
● Week 1: Introduction
● Week 2: Thinking in Objects
● Week 3: Java Collections
● Week 4: Inheritance
● Week 5: Polymorphism
● Week 6: Interfaces and Abstract Classes
● Week 7: Exceptions
● Week 8: Streams, Buffers, and Serialization
● Week 9: Text Processing with Regular Expressions
Syllabus
● Week 10: MIDTERM
● Week 11: Generic Classes and Methods
● Week 12: Best Practices 1
● Week 13: Best Practices 2
● Week 14: Project Presentations
Programming Paradigms
● In SE115 we have used Java, an object oriented language, like a procedural
language.
● “Procedural language” gets its name from procedures, or from methods, or
from functions.
● They have a top-down design where a problem is associated with a
procedure.
● Procedural languages are still being used to solve complex problems.
● However object oriented programming is now the most popular paradigm.
● There are several reasons.
Object Oriented Programming
● Just as we use “procedures” in procedural programming languages, we use
“objects” in object oriented languages.
● As humans, we are more inclined to think everything in objects, or more
broadly speaking, in categories.
● Since the ancient times, it is natural for us to generalize the things around us;
○ Animals, plants,
○ Food,
○ Personalities, etc.
● We see common traits in things; and we can do so in programming as well.
Object Oriented Programming
● It is easy to think of a “student” as an object where the student has properties
such as name, student id, department, etc.
● Once we start thinking in objects, we can take the idea further to provide
additional capabilities.
○ We can define relations between them (student objects that are “enrolled” to course objects)
○ We can generalize or specialize (animals (general), cats (specialized), scottish fold (more
specialized).
● Even “enrolling” - which is an action - can be an object.
Why?
● What other advantages does OOP provide over the procedural paradigm?
● The most apparent ones are reusability and maintenance.
● Reusability allows pieces of code to be used in different projects.
○ Think about the methods and objects you have used in SE115, such as the Scanner object.
The Scanner object in each of your programs does not care what your program does. But we
reuse the same code to build more complicated programs.
● Maintainability allows us to update our programs when the requirements
change.
○ Think about OASIS - there are new rules and new requirements that come up every
semester. It has to be maintained so that it can be used.
Object Oriented Design Principles
● Even though you are still relatively at the beginning of your career as
engineers, you have started to build complex programs.
● The fundamental goal of dealing with their complexity creates several goals
for producing quality software.
● These goals are
○ Robustness, a software that is “correct” - which means the software produces the right output
for all anticipated inputs.
○ Adaptability, a software that can evolve over time in response to changing conditions in its
environment.
○ Reusability, which we have already discussed before.
Object Oriented Design Principles
● To reach these goals, OOP has the following design principles;
○ Abstraction
○ Encapsulation
○ and Modularity.
● Abstraction is to distill (decompose) a complicated system down to its most
fundamental parts and then describe these parts in a simple, precise
language.
○ Think about the light switch we use. When I press the switch, the light is turned on. When I
press it again, it is off. I don’t know the details behind its operation and its hardware (such as
its cables and electrical components), but the idea is to be able to turn the light on or off.
○ This is the same with the System.out.println() method - I don’t know how it prints on the
screen, but it does, and it is all I need. The method “println” is an abstraction to printing on the
screen!
Object Oriented Design Principles
● Encapsulation - also known as information hiding - states that different
components of a software system should not reveal the internal details of their
respective implementations.
● Consider the System.out.println() method again.
● If in Java 20 (not out yet) they keep the abstraction, but change its
implementation (how it works) we will not notice anything.
● The implementation is hidden from us, as it should be.
● Why?
● The different components of a large software system should operate on a
“need-to-know” basis.
○ As the software gets larger, it gets more difficult to track which piece of code access which other
part of the code. This leads to bugs and errors which is hard to detect and correct.
Object Oriented Design Principles
● Modularity refers to an organizing structure in which different components of a
software system are divided into separate functional units.
● Modularity in a software system can provide a powerful organizing framework
that brings clarity to an implementation.
Java and OOP
● We have already used some of these principles in SE 115.
● For example, we have asked you to declare class member variables as
“private” and use “public” accessor methods -setters and getters- to access
and modify them.
● This is encapsulation; information hiding.
● Let’s quickly go over the classes once again.
Classes vs Objects
● A class is a “blueprint” of an object.
● There are cats - which is a large group of animals.
● The properties of cats, such as their physical traits and behaviors belong to all
cats. This is what the class is about.
● There are also cats you know about - for example, your cat, or your friend’s
cat. They are specific cats - not just any cat. This is what the object is about.
● Another example would be a “car” - which has a blueprint.
● You have the specifications to build a car (class), and you use it to “build” or
“construct” a car (object).
● Let’s go with that!
The Car Class
public class Car {
private int year;
private String model;
public Car(String m, int y) { // the constructor
model = m;
year = y;
}
}

Here is your car class, in Car.java file. Now, I can create Car objects.
Car sahin = new Car(“Şahin”, 1991);

The object sahin is an instance of the Car class.

Classes
● Once we define a class, or when it is defined for us, we can use it just like any
primitive variable.
● However, remember that when we use the new keyword, a reference is
returned as a value.
● So, when you create a variable for an object, the variable stores the memory
address of the object, not the object itself.
● It makes sense, because a class can have references to other classes, which
could have references to the original class, which in turn would create a
recursive loop.
○ Let’s say a Student object has a reference to a Course object, and the Course object has a
reference to a Lecturer object, and the Lecturer object has a reference to the same Student
object…
 Point.java PointDemo.java
public class Point { public class PointDemo {
public int x; public static void main(String[] args) {
public int y; Point a = new Point (0, 0);
public Point(int a, int b) { Point b = new Point (3, 4);
x = a; System.out.println(a.distanceTo(b));
y = b; }
} }
public double distanceTo(Point b) {
double dx = Math.pow(x - b.x, 2);
double dy = Math.pow(y - b.y, 2);
return Math.sqrt(dx + dy);
}
}

The name of the function is “distanceTo” which makes the

code readable when we write a.distanceTo(b).
Classes
● This semester we will be working with classes all the time.
● Next week we will be talking about how we think in objects - that is how we
use objects to solve our problems.
● We will still use methods and other basic programming constructs, such as
conditionals and loops, but the solution will lie in our usage of objects and
classes effectively.
References
● Data Structures and Algorithms in C++, Goodrich, Tamassia, Mount, Wiley.