ICS312 Object Oriented Programming

1
ICS312 Object Oriented Programming

• Lecture 1
• Dr. Ken Cosh

2
What is this course about?

• Introduction to principle concepts used in
  object-oriented programming such as definition
  and characteristics of object-oriented languages,
  object, classes, encapsulation, inheritance, and
  polymorphism. The course includes object-oriented
  design and techniques of object-oriented
  programming.

3
Dont we know this already?

• Well, weve covered many of these topics in CP1
  CP2
• but that was from the perspective of learning to
  program.
• In this course well look at OOP as an approach
  to programming, also covering topics such as OOA
  and OOD.
• Why do this?
• Well, hopefully this class will explain why OO is
  important.

4
Course Structure

• 2 Ajarns, 2 key parts
• Dr. Ken
• The Theory of O-O.
• Aj. Geng
• The Practical part of O-O.
• Through Java!

5
Course Assessment

• Exams
• In class assignments
• Major Project
• The last 3 weeks are devoted to this obviously
  more details will come along later.

6
If youre ready

• then let us begin!

7
Complexity

• A physician, a civil engineer and a computer
  scientist were arguing about what the oldest
  profession in the world was. The physician said,
  Well in the bible it says that God created Eve
  from a rib taken out of Adam this clearly
  required surgery, so clearly mine is the oldest
  profession in the world!

8
Complexity

• The civil engineer interrupted, But even earlier
  in the book of genesis, it states that God
  created the order of the heavens and the earth
  from out of the chaos this was the first and
  certainly most spectacular application of civil
  engineering, so my friends mine is the oldest
  profession in the world.

9
Complexity

• The computer scientist sat back and smiled, Ah,
  but who do you think created the chaos?

10
Complex Problems

• OK, so weve all programmed simple programs
• a Fibonacci Number calculator.
• And, weve all tried to tackle a little more
  complex problems
• Battleships, Cards
• But what we are really interested in is really
  complex problems!
• How can we build solutions to really complex
  problems?

11
Complex Problems

• Many problems are just too complex for humans
  intellectual capacity
• We cant comprehend all the subtleties of the
  design.
• Unless youre a genius!
• The world is only sparsely populated with
  geniuses. There is no reason to believe that the
  software engineering community has an
  inordinately large proportion of them. (Peters)
• So for ordinary peons a way of dealing with
  complexity is needed.

12
Complexity Problem Domain

• Functional Requirements
• Non-Functional Requirements
• Volatile Requirements
• Difficulties in Eliciting Requirements
• Dealing with Requirement conflict
• Managing the development process
• Many developers
• Much code

13
Complexity Flexibility

• Does a construction firm have its own forge to
  custom build girders?
• Yet, within Software Development, often we build
  our own raw materials.
• This means we have infinitely flexible solutions.
• There are no standards for the raw materials
• While this flexibility might appear to be
  seductive, allowing any abstractions, it
  inherently adds complexity to an already complex
  environment.

14
Complexity Characterising Behaviour

• Variables are just that variable!
• Even within discrete environments, changes to
  inputs affect outputs, but mapping these changes
  are difficult
• Mapping from state to state is not always
  deterministic.
• If the passenger in seat 38J was to switch on
  their light, we wouldnt expect the plane to
  dive.
• Issues of internal and external state.

15
Complex System Attributes 1

• Frequently, complexity takes the form of a
  hierarchy, whereby a complex system is composed
  of interrelated subsystems that have in turn
  their own subsystems, and so on, until some
  lowest level of elementary components is
  reached.
• The idea of a hierarchy, with decomposable
  subsystems, gives us an access point to
  understand, describe systems in terms of their
  parts.

16
Complex System Attributes 2

• The choice of what components in a system are
  primitive is fairly arbitrary and is largely up
  to the discretion of the observer of the system.
• We may see different sub components, and each sub
  component may appear more or less important to
  each of us.

17
Complex System Attributes 3

• Intracomponent linkages are generally stronger
  than intercomponent linkages. This fact has the
  effect of separating the high-frequency dynamics
  of the components involving the internal
  structure of the components from the
  low-frequency dynamics involving interaction
  between components.
• This enables us to explore different parts of a
  system in relative isolation.

18
Complex System Attributes 4

• Hierarchic systems are usually composed of only
  a few different kinds of subsystems in various
  combinations and arrangements.
• Complex systems are made up of subcomponents that
  are then reused over and over again.

19
Complex System Attributes 5

• A complex system that works is invariably found
  to have evolved from a simple system that worked
  A complex system designed to work from scratch
  never works and cannot be patched up to make it
  work. You have to start over, beginning with a
  simple system.
• Systems evolve and often the reason they can
  survive as complex systems is that they evolved
  to that state and were not designed in that state!

20
Bringing Order into Chaos

• Well, attempting to anyway
• Since ancient times a key way of dealing with
  complexity is to divide and conquer.
• Have a complex system, break it down into simpler
  parts
• If we understand the parts, then we can
  understand the system
• But how do we decompose the problem?
• Algorithmically?
• OO?

21
Greek Philosophy

• Democritus proposed a passive view, where the
  world is composed of matter called atoms, and
  these atoms should be the center of focus.
• Heraclitus proposed and active view, emphasizing
  the notion of process.
• Which is more important? The things, or the
  things they do?

22
Algorithmic view

• Traditional approach to top down structured
  design.
• Each module is comprised of a step in the
  process. E.g.
• Take input from user.
• Perform calculation on the input.
• Return output to user.
• Place each of these in a function.

23
O-O View

• The world is comprised of autonomous agents, that
  collaborate to perform some high level behaviour.
• The problem is broken into objects, and these
  objects do things we ask them to do it by
  sending messages to them.

24
Which is Right?

• Well, neither or both rather
• Both views are important and useful, just
  opposite ways of viewing a problem.
• Sadly we cant use both to form our design, so in
  this course we will of course focus on the Object
  Oriented approach.

25
Abstraction

• We are only able to comprehend certain numbers of
  chunks of information at a time.
• As we learn and understand things, we can begin
  to comprehend new things.
• Once we know how the individual parts of a
  computer work, we can focus on using the computer
  without thinking how the RAM works.
• Different people abstract to different levels at
  different times, by chunking information together.

26
Hierarchy

• Creating a hierarchy involves grouping chunks
  appropriately by recognising where and how chunks
  are related.
• This is not an easy task!