OOP in a Nutshell - PowerPoint PPT Presentation

1 / 7
About This Presentation
Title:

OOP in a Nutshell

Description:

Classes define objects, objects hold 'state' and respond to methods. Whenever you define an object in a program, you need to know its data type (what ... – PowerPoint PPT presentation

Number of Views:43
Avg rating:3.0/5.0
Slides: 8
Provided by: Steve57
Category:
Tags: oop | define | nutshell

less

Transcript and Presenter's Notes

Title: OOP in a Nutshell


1
OOP in a Nutshell
  • Everything is either data or function
  • data are objects, things, nouns
  • functions are algorithms, procedures, methods,
    verbs
  • In Java we talk about objects (data) and methods
    (function)
  • for example, in the single line of code
  • aString.toUpperCase().trim().charAt(3)
  • Classes define objects, objects hold "state" and
    respond to methods
  • Whenever you define an object in a program, you
    need to know its data type (what class is it an
    instance of)
  • Whenever you define a method in a program, you
    need to know its signature what are its inputs,
    and what does it return

2
The Point of the Whole Quarter Modularity
String getFirstName()
aString
Contract no preconditions returns
the person's first name, which is guaranteed
to be non-null and non-empty
void setAge(int)
anInt
Contract input argument must be (an
integer) greater than 0 subsequent calls to
getAge() will return this value (until a
call to setAge() changes it again)
3
Modularity
  • A module defines some functionality without
    revealing how it implements the functionality
  • is there an instance variable called name?
  • how/where is the age stored?
  • A module defines its input/output behavior
    through its interface
  • Modularity is a broader concept than just
    class/method
  • a class defines its behavior through its public
    interface
  • a method defines its behavior through its
    signature
  • a block of code defines its interface through
    comments
  • But in all cases, the module's behavior depends
    on nothing external apart from its inputs and
    affects nothing external excepts through its
    outputs

4
An Example of Modularity in Code
int x 3 int y 4 int z 2 int answer int
someOtherint 99 // Computes (xy)/z //
Precondition z ! 0 (code is free to do
anything // if the precondition is
violated) // Postcondition variable answer
contains output value int tmp x y answer
tmp / z // Code continues, knowing that answer
has been // set to the value, and that values of
x, y, z, and // someOtherInt have not been
changed // Variable tmp should NOT be used at
this point someOtherInt someOtherInt result
5
Modularity at the Application Level
sort
standard input
standard output / standard input
standard output
head
Contract for sort Accepts text lines from
standard input stream Writes the same lines
to standard output stream, but in
alphabetical order
Contract for head Accepts text lines from
standard input stream Writes the first 10
lines to standard output (or fewer if
end-of-stream before it writes 10)
6
Modularity and Interfaces
  • In the informal sense, a module is defined by its
    interface its inputs and outputs. These can be
    defined informally (in comments or
    documentation).
  • In the special case of a class as module, the
    interface is the set of methods that instances of
    the class can respond to
  • public String toUpperCase()
  • public char charAt(int index)
  • In addition, you can also define an Interface as
    a set of methods, then a class can declare that
    it implements the interface
  • the Scanner class implements the Iterator
    interface, which means the class implements
    methods next(), hasNext(), and remove()
  • the method anArrayList.iterator() returns an
    object that implements the Iterator interface,
    and you don't know what class the resulting
    object is (only that it implements those three
    methods)
  • the interface Comparable is implemented by String
    and many other classes that are willing to
    compare themselves (lt, , gt) to other instances

7
Why Bother?
  • As systems get bigger and more complex, it gets
    harder to understand them all at once. Therefore
    you need to "divide and conquer" the problem into
    smaller pieces that can be understood, and/or
    sub-contracted. If different people are working
    on different pieces, the interfaces must be well
    defined and the effects of each module must not
    affect other modules, except through the
    interface.
  • Breaking problems into small "generic" pieces
    allows use to re-use libraries, but only if they
    can be picked up and used in isolation.
  • the Scanner class
  • the InputUtilities class
  • the Java collections like ArrayList
  • all of the Java language, for that matter
Write a Comment
User Comments (0)
About PowerShow.com