Object Orientation

1
Object Orientation
ORObject-Oriented Analysis Leads to
Object-Oriented Design, Which in Turn Leads to
Object-Oriented Programming Using
Object-Oriented Programming Languages
Nick Meshes
2
Ground Rules

• This presentation is interactive. Please ask
  questions and feel free to stop me at any time.
  Otherwise, we will both get bored and none of us
  will have any fun.
• The scope of this presentation is all of the
  fundamental concepts of OO and some related
  technologies which I chose pseudo-randomly. If
  you feel Im missing a fundamental concept or an
  important aspect, please bring it up so we can
  discuss it. If I fail to cover a related
  technology you were hoping to see, we should
  discuss it briefly.
• Since this is the first presentation for SWD
  Community, it might be helpful to have feedback
  publicly within the group on how presentations
  may be prepared and presented similarly or
  differently in the future.
• There will not be very many other slides with
  this much writing on them.

3
Agenda

• Defining Object Orientation
• Introduction to Objects
• Object Relationships
• Other Characteristics of OOP
• Related Concepts in Object Orientation

4
Agenda

• Defining Object Orientation
• Introduction to Objects
• Object Relationships
• Other Characteristics of OOP
• Related Concepts in Object Orientation

5
Defining Object Orientation (OO)

• The use of objects and classes in analysis,
  design, and programming
• The foundation for a systematic engineering
  discipline from beginning (analysis/design) to
  end (implementation)
• A paradigm encompassing techniques, processes,
  standards, models, notations, tools, languages,
  packages, environments, examples, community and
  skills

6
Why Object Orientation?

• Modeling of the real world ? natural and
  accessible
• Problem/business analysis and requirements
• Web presence and utilization
• Software reuse and componentization
• Enterprise engineering
• Modern 3rd party software
• Seamless process
• Higher cohesion (logical grouping)
• Lower coupling (physical dependence)

7
Object-Oriented Analysis (OOA)

• OOA is the challenge of understanding the problem
  domain and then identifying classes and objects
  that can be used to describe the problem domain.
• These objects represent reusable items such as
  classes, instances, systems of interacting
  objects, and frameworks.
• Once the problem domain has been investigated and
  concepts have been organized into logical
  objects, then design can commence.

8
Object-Oriented Analysis (OOA)

• Domain analysis (OODA) seeks to identify the
  concepts, explaining them as objects, within the
  context of an entire domain, not just for the
  immediate problem.
• Domain analysis is only useful when similar
  systems are to be built, amortizing the cost
  across systems. However, once OODA can be
  rationalized, the reusability of a system or
  framework to be built is realized.

9
Object-Oriented Design (OOD)

• Once analysis has been performed, the resultant
  classes and objects can be organized into models
  which show interactions and relationships between
  the objects. Abstractions and mechanisms to drive
  the model are invented. This process of modeling
  the object interactions is object-oriented
  design.
• Design decisions can drive choice of programming
  language, due to capabilities and limitations of
  various object-oriented programming languages
  (OOPLs).

10
Object-Oriented Programming (OOP)

• Object-oriented programming is the implementation
  of an object-oriented design.
• Object-oriented programming refers to the actual
  coding as well as use of 3rd party packages and
  APIs.
• The progression from OOA to OOD to OOP roughly
  corresponds to the Waterfall Model.

11
Agenda

• Defining Object Orientation
• Introduction to Objects
• Object Relationships
• Other Characteristics of OOP
• Related Concepts in Object Orientation

12
Introduction to Objects

• An object has
• State, behavior, and identity
• Well defined role in problem domain
• An object is an abstraction of a set of real
  world things, where
• Each instance of a common object has common
  characteristics
• All instances conform to the same rules
• The thing can be a tangible item, role,
  incident, interaction or specification

13
Categorizing Objects

• Ordinary objects simple OOPL objects
• Composite object subsystems
• Subsystems Sets of cooperation classes
• Frameworks Abstract subsystems which define
  responsibilities and collaborations between
  classes, for reuse and extension
• Patterns Solutions to common, recurring problems
• Entity (Business model), Interface/ GUI (View),
  and Controller
• Implementation hiding (Ex Distr. Arch, DBMS, OS)
• Utility classes

14
Categorizing Object Implementations

• Descriptor-based dynamically typed where
  references have no type but objects references
  point to, do.
• Capability-based different operations are
  available in different contexts and can be
  encapsulated
• Static-based each object is an instance of a
  record type which contains record fields
  (attributes) and may contain operations (methods)
  

15
Classes

• A class is the specification of an object,
  defining
• Structure (attribute variables, state, instance
  variables, member data or attributes),
• Behavior (methods, member functions, operations
  or representation)
• Inheritance (parent classes which provide
  structure and behavior implicit to the class)
• Visibility of structure and behavior
  (encapsulation)
• Interface (the operations and data available to
  other classes)
• Identity also known as Type

16
Modeling a Class using UML
The diagram on the left shows a single class of a
model diagram. A model diagram shows the
attributes and relationships between key objects
of the system. These attributes and relationships
are called the model.

• We can see that the class diagram is divided into
  three parts
• Class name the name of the class or object
• Attributes also called properties, these are
  the variables that belong to the class.
  Attributes represent
• information that the object knows.
• Operations also called methods, these are the
  functions of
• that class.

17
Code Example of a Class
public class Car private int maxSpeed //
attribute defining the maximum speed of this
car // Note that if you had two cars, they could
have two // different max speeds. private
int acceleration // attribute that defines the
acceleration of the car   public void
accelerate(int howLong, int howQuickly) //
operation of the car, that it can
accelerate   public void decelerate(int
howLong, int howQuickly) // operation of the
car, that it can decelerate
18
Classes and Instances

• An object is an instance of a class. An instance
  is a run-time object bound to the definition of a
  class.
• Two objects of the same class have the same
  behavioral operations and structure, but
  different attribute values.

19
Classes and Instances

• When calling an operation upon an object, the
  object receiving the request is the receiver
  while the one referencing the method is the
  caller.
• Within the code of the method, the receiver
  refers to itself as this or self.

this.acceleration .76
20
Classes and Metaclasses

• If an object must have a class, then that class
  can act as an object (the Metaclass), providing a
  means to accessing the classs attributes,
  methods, parents, and implemented types.
• The Metaclass was used originally by the compiler
  and runtime environment.
• In many OOPLs, the Metaclass also provides
  reflection (accessing the above items as well as
  creating new instances).

21
Levels of OOPLs

• Not all object-oriented programming languages use
  the same system of class-to-object correlation.
• Simpler systems define objects only in runtime so
  all objects are of the same type (1 Level), while
  others allow programmers to define classes, but
  not access Metaclasses (2 Level). Still others
  include the concept of Metaclasses which are
  implicitly defined (3 Level) and, finally, others
  allow programmers to explicitly define
  Metaclasses (5 Level).
• Any OOPL with 2 Levels falls within the
  classical OO paradigm.

22
Methods

• Define the signature of the interface
• Method name
• Parameters (or messages) required (with this
  implied as the first)
• Return type
• Define the implementation within a class, i.e.
  the actual functionality (behavior)
• Often has an level of visibility

public AccelStatus accelerate(AccelParams
accelparams) this.acceleration
accelparams.getAcceleration() // implementation
goes here
23
Methods

• Behavior is how an object acts, based on state
  changes and message passing.
• Methods have access to the entire internal state
  defined within the class.
• Methods can be thought of as procedures which
  implicitly take the object being called upon as
  the first parameter.

24
Methods

• Classes can define multiple methods with the same
  name but different parameters and possibly
  different return types (overloading).
• The behavior of the class changes based on the
  the parameters passed (multiple polymorphism).
• Some OOPLs will dynamically choose the closest
  matched method at run-time.

25
Constructor Methods

• Classes can define a method that must be called
  in order to create an new instance of the object,
  called the constructor.
• A class can also define multiple constructors,
  each overloaded to take different parameters.
  However, only one constructor must be called to
  create an instance.
• The process of creating an instance of an object
  by invoking the constructor defined in the class
  is called instantiation.

26
Attributes

• Define the structure of the class, i.e. the data
  defined within the class and existing on the
  objects instance
• All attributes of an object are the state of the
  object.
• Often has an level of visibility, but usually
  hidden from other classes
• Member variables can be other classes, allowing
  the class to reference behavior of other classes
• Attributes and behavior are also inherited from
  parent classes

27
Encapsulation

• Each component (class) should hide implementation
  details and design decisions
• Information that should be encapsulated
• Data types of variables
• Variable names
• Internal methods that provide underlying behavior
• Only public interface remains
• Black-box reuse A well-defined interface and no
  externals exposed

28
Levels of Encapsulation

• Private data and behavior only available to
  this
• Protected data and behavior only available to
  this and instances of derived classes
• Package data and behavior available within a
  logically grouped subsystem
• Public data and behavior available to any other
  object

29
Encapsulation

• Per-class protection private methods can access
  any instance of the class, not just the receiver
  (C)
• Per-object protection private methods can only
  be called by the receiving object (Java)

30
Agenda

• Defining Object Orientation
• Introduction to Objects
• Object Relationships
• Other Characteristics of OOP
• Related Concepts in Object Orientation

31
Inheritance

• A relationship where one class is the parent
  (superclass or base class) of another (subclass).
• The subclass automatically receives the interface
  and implementation of the parent, allowing for
  programming by extension, rather than programming
  by reinvention.
• Inheritance is a is-a-kind-of or is-a
  relationship.
• White-box reuse A subclass inherits the
  interface and implementation, but is unable to
  access private internals

32
Inheritance
Inheritance One object can inherit the
attributes and operations of another object if
its class extends from the other objects class.
Additionally, the subclass object can override
the behavior of the superclass by creating a
method that has the same name, takes the same
parameters, and returns the same class. (Wed
say an overridden method has the same interface
or signature as the superclasss operation.)
In this diagram, Subclass extends from
Superclass. Subclass is a special type of
Superclass. When you call operation1() on a
Subclass object, you will have different behavior
than if you can operation1() on a Superclass.
However, since operation2() is not overridden,
you will have the same behavior on an instance of
a Superclass or a Subclass.
33
Code Example for Inheritance
public class Vehicle private int maxSpeed
private int acceleration   public void
accelerate(int howLong, int howQuickly)
public void getMaxSpeed() return
this.maxSpeed   public class Car extends
Vehicle // maxSpeed and acceleration
attributes automatically // exist for the Car
since it is a special type of Vehicle   public
void accelerate(int howLong, int howQuickly)
// accelerate() is overridden to behave
differently than // the default implementation
of Vehicle
34
Inheritance

• Advantage Differing subclasses can have
  differing implementations of a common interface
  (simple polymorphism). Referring objects only
  need to know the interface.
• Advantage Code and structural reuse beats
  duplicate code, especially when a code change is
  required.
• Disadvantage One cannot change behavior on a
  subclass without changing code or adding more
  subclasses. (Delegation is the solution to this
  problem.)

35
Inheritance

• A subclass is also called a derived class.
• An object is an instance of its exact class and
  all parent classes.
• However, the exact class of an object is called
  its most derived class.

36
Inheritance

• Creation of a subclass is specialization,
  meaning the derived class is a special form of
  the parent.
• Factoring all common parts of classes into a
  common parent is called generalization.

37
Inheritance

• An object-based language does not support
  inheritance and therefore, does not support
  polymorphism.
• A language must support inheritance in order to
  be truly object-oriented.

38
Inheritance

• Differential programming The use of inheritance
  to reuse existing classes by making a small
  change on a subclass, adding a method or altering
  behavior.

39
Multiple Inheritance

• Multiple Inheritance occurs when a class inherits
  from more than one parent.
• MI is a characteristic of the real world.
• Since several parents can define a member
  (variable or method), which to use becomes an
  issue. Different OOPLs use different solutions.
• Not all OOPLs support Multiple Inheritance.

40
Dynamic Inheritance

• Dynamic Inheritance allows objects to change over
  time.
• Dynamic Inheritance is implemented as the ability
  to add, remove, and modify parents of classes at
  runtime.
• Not all OOPLs support Dynamic Inheritance.
• 1 Level systems implement DI though delegation.

41
Overriding

• A subclass can define a method implementing the
  interface of a method defined on a superclass.
• The overridden method can completely change the
  implementation underlying the interface and/or
  call upon the superclasss implementation of the
  method.
• When a method is invoked on an object of a base
  class, the method is executed on the derived
  class, overriding the base classs implementation.

42
Polymorphism

• The ability of an object to assume many different
  forms of object
• Inheritance allows a derived class to define more
  specific behavior and attributes over a base
  class (type)
• In other words, the same operation may perform
  differently on different classes.
• Well call the interface and default
  implementation of a method defined on the base
  class a virtual function (C).

43
Component Relationships

• Classes which have other classes as attributes
  have a component relationship to these classes.
  At run-time, the objects instantiated form an
  object composition.
• Object composition can act as an alternative to
  class inheritance.

44
Component Relationships
public class Car extends Vehicle private
Engine theEngine private Tire
theTires   public void accelerate(int howLong,
int howQuickly) theEngine.accelerate(howLong,
howQuickly)   for (int i0 i lt
theTires.length i) theTiresi.spin(howLong,
howQuickly)   public class Engine
public void accelerate(int howLong, int
howQuickly)   public class Tire public
void spin(int howLong, int howQuickly)
45
Polymorphism by Delegation

• In lieu of using inheritance hierarchies to
  control implementation, a class may also
  reference other classes that can handle requests.
• When a request is made, the receiver forwards (or
  delegates) the request to another object. The
  delegate handles the request for the original
  receiver, or it may delegate.
• By delegating a request to an object, where that
  object may use polymorphism by inheritance, one
  can achieve powerful behavior underlying a simple
  interface.
• Most often, the receiver will have a component
  relationship to the delegate.

46
Polymorphism by Delegation
Sequence Diagram or Interaction Diagram
47
Component Relationships

• Association The loosest bond between two objects
  where one maintains an attribute reference to the
  other. Often other objects will reference the
  associated object as well.
• Composition The tightest bond between two
  objects where one (the aggregate) maintains an
  attribute reference to the other and owns the
  other object. The other often has a reference
  back to its aggregate.
• Aggregation A bond between two objects which has
  less coupling than Composition but more than
  Association. In an aggregation, one object may
  have ownership of the other.

48
Agenda

• Defining Object Orientation
• Introduction to Objects
• Object Relationships
• Other Characteristics of OOP
• Related Concepts in Object Orientation

49
Dynamic Binding

• Allows new objects and code to be added to a
  system without affecting the existing code
• Eliminates the need for switch statements
• Removes spread of knowledge as each object knows
  what operations to support
• Allows small packages of behavior, improving
  coherence and loose coupling.
• There are two forms of dynamic binding
  statically-typed and dynamically-typed.

50
Dynamic Binding

• It is not known which implementation will be
  called at run-time on a virtual function since a
  derived class may override the method. In
  statically-typed dynamic binding, all such
  functions are resolved statically for actual
  objects when the whole code of the entire program
  is compiled (compile-time resolution).
• The run-time selection of methods, meaning lookup
  (binding) is performed at run-time, is
  dynamically-typed (run-time resolution).

51
Separation of Type and Class

• Type provides the complete set of method
  signatures (interface) whereas Class
  (Representation) defines the behavior
  implementation of that interface.
• By separating type from class, a replacing object
  must implement the set of operations or type
  constraints (subtype polymorphism), but is not
  required to do so by an inheritance relationship
  (subclass polymorphism).

52
Separation of Type and Class

• Some OOPLs (Java) require an object being
  assigned to a variable of an interface type to
  inherit from that type, linking the class to the
  type.
• Other OOPLs do not require this linkage, which is
  less type-safe and accidental matches of method
  signature can occur.

53
Abstract Classes

• Abstract classes in typing provide a facility
  similar to subtype polymorphism.
• The main purpose of an abstract class is to
  define the interface for all subtypes.
• Abstract classes can define representation
  (default implementation) and require
  type-compatible classes to inherit from them.
• Subtyping is most useful to avoid spread of
  knowledge of classes throughout a system, a high
  priority for loose coupling in modules and in
  distributed programming.

54
Abstract Classes

• Abstract classes do not define all the behavior
  necessary to create an instance.
• Methods which do not define behavior are called
  abstract methods. They provide only interface.
• Concrete classes subclass from abstract classes,
  implementing behavior for all the abstract
  methods, and may override behavior of the
  abstract class.

55
Generics (Templates)

• Generics refer to the ability to parameterize
  types and functions with types (parametric
  polymorphism).
• Generics provide for reusability in OOPLs.
• Example a Stack with a generically parameterized
  base type. The Stack can contain a set of any
  type.
• Generics can be considered a special case of type
  variables.

56
Agenda

• Defining Object Orientation
• Introduction to Objects
• Object Relationships
• Other Characteristics of OOP
• Related Concepts in Object Orientation

57
Persistence

• Objects that outlive the run-time of the programs
  that create them.
• Objects can be persisted (stored) in an endless
  number of ways.
• XML is becoming a common means of storing object
  state.
• Objects can be persisted in files, relational or
  Object-Oriented Databases, etc.

58
Object Oriented Databases (OODBs)

• Object-Oriented Databases are DBs that support
  objects and classes.
• They allow structured subobjects, each object has
  its own identity, and they support methods and
  inheritance.
• Relational operations are also available.
• All benefits of OO and a strong equivalence with
  OO programs.
• A persistent object store with a DBMS.

59
Object Oriented Databases (OODBs)

• Orbiters Persistence layer (framework) in
  conjunction with Metadatas Orbiter tables and
  the MD API provide a pseudo-OODB.
• Objects are stored/retrieved as XML.
• Persistence framework calls operations on objects
  to prepare for storage and complete restoring
  state at retrieval time.
• The missing component is that the stored state is
  decoupled from the implementation.

60
Object Oriented Operating Systems

• Provide resources through objects, sometimes all
  the way down to the machine
• Almost always distributed systems, allowing
  objects to be passed freely between machines
• Typically capability-based since system resources
  can only be accessed if the capability is
  available to programs

61
Unified Modeling Language (UML)

• Unified Modeling Language is the
  industry-standard language (tool) for specifying,
  visualizing, constructing, and documenting the
  pieces of software systems.
• De-facto standard OO Methodology
• Developed by the Object Management Group (OMG)

62
Object Management Group (OMG)

• Consortium with two primary aims
• Promotion of the OO approach to software
  engineering
• Development of models and a common interface for
  the development and utilization of large-scale
  distributed applications using OO methodologies

63
Object Management Group (OMG)

• Object Management Architecture (OMA) Guide
• A signal terminology for OO languages, systems,
  DBs, and application frameworks
• An abstract framework for OO systems
• A set of technical and architectural goals
• An architecture for distributed applications
  using OO techniques

64
Object Management Group (OMG)

• Object Request Broker (ORB) key communications
  element for handling distributing messages
  between application objects
• Object Model Single design-portability abstract
  model for communicating with OMG-conforming OO
  systems
• Object Services The main functions for
  implementing basic object functions using the
  ORB, logical modeling and physical storage of
  objects
• Common Facilities facilities useful in many app
  domains and made available through OMA-compliant
  class interfaces

65
Object Management Group (OMG)

• Common Object Request Broker Architecture (CORBA)
  and specification provides mechanisms where
  objects transparently make requests and receive
  responses across distributed systems.
• ORB provides interoperability of apps on
  different machines, in different environments,
  using different languages and seamlessly
  interconnects multiple object systems.
• There are many implementations of CORBA available
  for different OOPLs and machine architectures.

66
Garbage Collection (GC)

• A facility in run-time systems to automatically
  reclaim memory from objects no longer in use.
• Many OOPLs have built-in GC (Java, C) while
  others have been retrofitted (C, C).
• Without GC, programmers must explicitly
  deallocate dynamic storage (heap) when out of
  scope.

67
Garbage Collection (GC)

• Issues with explicit memory management
• Bugs due to storage deallocation are hard to
  find.
• In some cases, programmer cannot decide when to
  deallocate, leading to application-specific GC
  code.
• Object responsible for deallocating must have
  intimate knowledge of modules, leading to tight
  binding.
• Libraries with different strategies may be
  incompatible, hinder reuse.
• Reference counting is inefficient and cannot
  handle circular data structures.
• Garbage collection is a mature technology!

68
Design Patterns

• A description and solution to a common, recurring
  problem (in Software Development).
• Not dependent on programming language, but
  usually requires an OOD paradigm.
• Gang of Four book

69
Types of Patterns

• Design Patterns software design, often
  object-oriented
• Analysis Patterns recurring reusable analysis
  models
• Organization Patterns structure of
  organization/projects
• Domain specific, e.g CDI, insurance,
  manufacturing

70
Reasons to Use Patterns

• Same reason you reuse good code benefit from the
  knowledge and experience of other people.
• Patterns can be more reusable then code, since
  they can be adapted to a particular special
  circumstance.
• Concentrate on client problems
• Capture domain expertise
• Document design decisions and rationale
• Form a shared vocabulary for problem-solving

71
Object-Oriented Testing

• For confidence in reuse, module classes must be
  easily testable by client programmers.
• Packages must be testable under different OS
  configurations, different compiler optimizations,
  etc.
• Testing modules must be constructed in a way
  recognized as correct and must be shipped with
  class libraries.

72
Model-View-Controller (MVC)

• Model-View-Controller, aka Model 2, separates
  user interface from the business logic and data,
  providing a coordinator to connect view with
  model.
• View supports graphical interfacing.
• Model is the set of application objects.
• Controller handles interaction.
• By having clean separation, one view can be
  traded easily for another without affecting model
  code.

73
Visual Programming

• Many contemporary IDEs provide a facility to
  program an application by manipulating a
  artifacts within a GUI, either to write GUI code
  or to create object interactions.
• Visual Studio (VB, C, etc) and many incarnations
  of the Sun BeanBox for Java are two examples.
• Also common now is automatic code generation from
  a UML model (.mdl file).

74
References

• Object Orientation FAQ (http//www.objectfaq.com)
• Previous Presentations (http//www.meshes.com)
• Orbiter Development Team Training Materials
• Design Patterns
• By Gamma, Helm, Johnson, Vlissides
• Object-Oriented Technology A Managers Guide
• By David A. Taylor, Ph.D.
• Programming Languages Concepts Constructs
• By Ravi Seth

Shameless self-promotion