Object-oriented Design

1
Object-oriented Design

• Chapter 16

2
Real Objects and Software Objects

• Real objects are things that can be manipulated
  and used for different tasks. So, too, are
  software objects.
• Real objects fit into general classes with the
  same general purpose and means of use cars,
  televisions, microwaves, lawnmowers, dryers, etc.
• In addition, there are very broad classes that
  include general classes. For instance,
  appliances would include microwaves,
  televisions and dryers.

3
What is a Software 'Object'?

• Software objects are similar to real-world
  objects in that they can have general uses, and
  fit into classes.
• There is also the capability to have classes of
  classes just like appliances for real world
  objects.

4
The Object Paradigm

• With software objects, however, we dont interact
  directly with them (like turning on a
  television.) Instead, we send the object a
  message.
• A software object can accept and understand any
  message or messages we design it to accept.
• The model (or paradigm) is that we talk to
  objects and send it instructions about what to
  do. In turn, the object may send messages to
  other objects to help it with its task.

5
Object-oriented requirements

• Object-oriented requirements definition lends
  itself to definition of analog systems
  systems designed on the basis of existing
  physical or manual systems (such as accounting
  ledgers, invoices, receipts, etc.)
• There are techniques for extracting object
  requirements from unstructured requirements
  definitions (such as rambling prose) that work
  quite well!

6
Modeling the physical world

• Since a major strength of the object-oriented
  approach is the object paradigm, its best to
  model the physical world when building object
  oriented systems.
• For instance, since we can post an entry to a
  ledger in an accounting system, it would perhaps
  be wise to create an object class called ledger
  that understands a message named post that
  contains a ledger entry in the message.

7
The role of requirements

• In the instance of object-oriented systems, the
  requirements give the designer instructions about
  what objects should be constructed, and what
  messages they should understand.
• In addition, the requirement must give the
  designer an idea of how the objects can be
  organized, and what other objects they must
  collaborate with.

8
Booch method

• One popular method, the Booch method, models
  objects on several levels a logical levell,
  physical model, dynamic model and static model.
• The Booch method is perhaps one of the most
  popular methods, and merits careful study by the
  serious object-oriented designer.

9
Shlaer-Mellor method

• The Shlaer-Mellor method uses a slightly
  different approach from the Booch model in that
  it models three basic aspects of the system
  Object information, state and processing.
• There are many different ways to model objects,
  but we shall examine a popular pencil-and-paper
  approach.

10
Class-Responsibilites-Collaboration (CRC) Method

• The CRC method uses CRC cards that are
  essentially 3 by 5 index cards (or whatever is
  handy).
• The approach is to decompose the requirements
  to identify classes and patterns, then look at
  their responsibilities.
• After the classes and responsibilities are
  identified, the next step is to look at how they
  need to work together their collaborations in
  other words.

11
Identification of classes and patterns

• When looking for classes and patterns, scan the
  specifications for nouns and noun phrases (nouns
  or adjective/noun combinations).
• These are candidate classes, and we create a
  CRC class to represent these classes.
• We may, at a later time, change the name of the
  class, or discard it altogether. Remember, at
  this time the classes are merely candidates!

12
Identification of Responsibilities

• Once we have these candidate class CRC cards, we
  look at the verb phrases (verbs or verb/adverb
  combinations) to identify possible
  responsibilities.
• These candidate responsibilities are also entered
  on the respective CRC cards. Again, these
  responsibilities may later be modified or
  discarded!
• We can begin to see action on object potentials
  from the associated class names and verb/noun
  combinations (post and entry to a ledger).

13
Identification of collaborators

• In looking for object collaborations, we need to
  look for possible relationships, such as
• Object A is like Object B
• Object A knows about Object B
• Object A shares information with Object B
• These relationships are entered on the CRC card
  as candidate collaborations.

14
Polymorphism

• Designers may find that there are general
  classes of objects, such as ledgers and journals,
  who share similar messages (such as post entry)
  but have other unique messages that make them
  different. These objects are candidates for
  inheritance a superclass can be created that
  accepts their common messages, and the
  subclasses can inherit these methods and add
  their own.

15
Polymorphism

• Designers may likewise find that there are
  several different forms of messages or objects
  that perform the identical functions, using
  different message values.
• Object oriented programming languages provide
  features that permit these different forms
  (polymorphism.)

16
Checking an Object Design for Implementation

• Object role playing is one of the best methods
  for checking.
• Each object is assigned to an engineer to play
  the part of that object.
• The objects are then walked through a cases in
  the system, and each object player checks to make
  sure that the information is available for proper
  execution of the objects responsibilities.

17
Object-oriented languages

• There are many object oriented languages today.
  Many of these are modern languages with
  extensions to support the object-oriented
  concepts Classes, Methods, Inheritance, and
  Polymorphism.
• Still, thee of the major object oriented
  languages are still Smalltalk, C and Java.

18
Smalltalk

• Smalltalk was advanced as a language originally
  by Alan Kay, who was working at the Xerox Palo
  Alto Research Center (Xerox PARC).
• Smalltalk was used as the fundamental language
  for programming the Xerox Star system, one of the
  early Object-oriented workstations.

19
C

• In the mid-1980s C was developed as the
  object-oriented extension to the C programming
  language.
• Bjarne Stroustrop was the major proponent of the
  C programming language.
• Another major contender at the time was
  Objective C which was used by the Next system
  built by Steve Jobs company.

20
Java

• Java emerged from the Oak programming language
  at Sun Microsystems.
• Java was well suited to providing small programs
  that could be downloaded quickly (applets).
  This proved to be very useful for internet
  applications, and Java quickly became the
  language of choice for Web browser applet
  programming.

21
Java

• An exceedingly brief introduction

22
It's like

• C
• Smalltalk

23
How is Java different?

• No preprocessor
• No define
• No ifdef
• Strongly typed
• No multiple inheritance
• No operator overloading

24
How is Java different? (contd)

• Interpreted (Virtual Machine)
• Run-time error checking
• Garbage collection
• Standard class libraries
• No pointers, only references
• Scoping

25
Terminology

• Classes vs. Objects
• A "Class" is a definition.
• An "Object" is the instance.
• Methods
• In C, called member functions"

26
Inheritance

• Parent class defines common elements (data,
  methods)
• Child class defines ONLY elements unique to that
  specific class.
• Rule Promote methods and data to the HIGHEST
  level of abstraction.

27
Public, Protected, and Private

• private is visible only to the class.
• protected is visible only to the class and child
  classes.
• "super" allows reference to parent elements,
  providing overrides.

28
Defining Objects

• class Myclass
• ltobject contentgt

29
Data

• class Myclass
• public int mypublicdata
• private int myprivatedata
• protected int myprotecteddata

30
Methods

• class Myclass
• public int mypublicdata
• private int myprivatedata
• protected int myprotecteddata
• public int get_myprivatedata return
  myprivatedata

31
Constructors

• class Myclass
• public int mypublicdata
• private int myprivatedata
• protected int myprotecteddata
• public int get_myprivatedata return
  myprivatedata
• Myclass(int myarg)
• mypublicdata myarg
• myprivatedata myarg
• myprotecteddata myarg

32
Instatiating Objects

• Myclass Myobject new Myclass(arglist)
• System.out.println
• ("My public data " Myobject.mypublicdata)
• System.out.println
• ("My private data " Myobject.myprivat
  edata() )

33
Notation

• Dot notation
• Instance.item
• Instance.item()
• this and super
• "this" insures self-reference.
• "super" insures parent reference.

34
Built-in types

• boolean (true or false)
• char (16-bit Unicode)
• byte (8-bits)
• short, int, long (integers)
• float, double (floating point)

35
Built-in objects and methods

• Arrays
• length()
• Strings
• Not mutable! (StringBuffer is!)
• length(), indexOf(), lastindex()...
• Concatenation ("")
• Exceptions
• throw
• catch

36
Libraries

• java.lang - core language classes
• java.io - io package
• java.util - general utility
• java.text - date, I18N, L12N, sorting
• java.awt - abstract windows
• java.applet - applets
• java.beans - user composable code
• java.rmi - remote method invocation (distributed
  processing)

37
Libraries (contd)

• java.net - networking
• java.math - math routines
• java.sql - SQL (database)
• java.security - encryption, authentication,
  signatures

38
Control

• if-else
• switch
• (to define a constant
• public static final int SOMECONST 1 )
• while
• for
• while (and do-while)
• break (and labeled break break somelabel )
• continue
• return

39
Inheritance

• class Otherclass extends Myclass
• public int get_myprivatedata()
• return myprivatedata-1
• Otherclass Oc new Otherclass(4)
• System.out.println(Otherclass private data
  Oc.get_myprivatedata()

40
But consider

• class Otherclass extends Myclass
• public int get_myprivatedata()
• return super.get_myprivatedata()-1
• Otherclass Oc new Otherclass(4)
• System.out.println(Otherclass private data
  Oc.get_myprivatedata()