ObjectOriented Realities

1
Object-Oriented Realities

• A practical view

2
What is object-oriented?

• No general accepted standardized definition
  exists
• For this discussion think of OO as a set of
  principles leveraged by three general disciplines
• Goal model the solution to a more natural form
  of the problem domain
• Principles
• abstraction, encapsulation, modularity,
  polymorphism, reuse
• Disciplines
• analysis, design, and programming
• Some claim OO is a complete change from the past
  while others claim it the same information just
  wrapped differently
• It should be considered both
• OO originated from the work of many over many
  years

3
Where did OO come from?

• In the year 2001, its a matured discipline
  newness is only relative to organizations that
  havent developed an understanding in regards to
  benefits, drawbacks and application
• OO is evoluntary not revoluntary
• It has basis from the early structured analysis
  work of the 70s and 80s but also addresses
  researcher concepts from the 60s
• OO as its own entity started in the early 80s
• OO growth in terms of developmental research and
  usage has been exponential in the last several
  years
• Hardware environments have been OO (component
  based) for years
• One of the key ideas behind the OO paradigm is to
  achieve this type of component base foundation
• A practical, cost efficient direction (nothing
  more, nothing less)

4
OO fundamentals
Perceptions
5
Of course I have done OO...

• Iterative/incremental development does not imply
  OO
• RUP or any other process does not imply OO
• Use-case analysis does not imply OO
• Java usage should not imply OO implementation
• C usage should not imply OO implementation
• Ada usage should not imply OO implementation
• UML usage does not always imply OO (UML is more
  than class diagrams)
• CORBA usage does not always imply OO
• Participation in one or two OO projects is not
  a basis for claiming an understanding of the
  paradigm
• Just saying its OO doesnt mean that it is OO

6
By the way..
Two points to remember -
Note that C and assembly language programming
does not preclude the use of the OO paradigm.
Adoption of the OO paradigm does not mean
everything else that has been accomplished is
thrown out or was bad.
7
OO misconceptions

• Silver bullet - cures what ails ya
• Too heavy and slow with large degree of overhead
• Difficult to use
• Large learning curve impossible to navigate
• No advantage over legacy ways most positive
  change is evoluntary
• If I program in C, Ada and/or Java, I am doing
  OO

8
Failed OO projects

• Failed OO projects have received a great deal of
  press but before the paradigm can be put on the
  trash heap, consider the following -
• was the project really OO (see the Of course I
  have done slide)
• what was the subject organizations definition of
  OO
• was the organization truly committed and prepared
  for the change
• did the customer understand their role in OO
  development
• what actually failed in the project
• functionality, maintainability, scalability
• costs, delivery date
• what actually hurt the project
• lack of process or procedures/too much process or
  too many procedures
• scope creep or other requirements and analysis
  problems
• general human factors (motivations, training,
  communication, attitudes)
• any other issues that would have tanked non-OO
  projects
• technology

9
Why do some OO efforts fail?
There is one primary reason why develop teams
have not realized the marketed benefits of OO -
They have not been writing objects. Most
efforts have involved writing hybrid systems
using a mix of both OO and procedural
programming without developing a hybrid
strategy/process for doing so. This is because
the transition to the OO paradigm was not
supported by a change in process or development
viewpoint. This is because..
10
More of Why do some OO efforts fail?

• Management and development team members
• Did not understand the fundamentals of the
  paradigm
• Did not understand cost
• Did not understand risk
• Did not understand timing aspects
• Panic
• Legacy proponents did not embrace change or
  effort
• Training not sufficient - design activities and
  languages not understood
• More panic

11
What can prevent failed OO projects

• The only thing that can prevent OO project
  failure is a solid understanding of OO
  fundamentals
• by the development team
• by the management team
• by the organization as a whole
• Communication
• members of a development team must feel free to
  communicate concerns and issues
• management (administrative and project) must be
  open to communication
• Change acceptance
• technology and market forces changes
• someone is out there thinking of a better way to
  do things

12
Value of the fundamentals to an organization

• Systems are capable of more dynamic behavior
  since focus is on relationships between problem
  domain entities instead of functionally dependent
  processes (object relationships vs.
  procedure/sub-routine relationships)
• Better positioned to take advantage of
  component-based architectures (industry direction
  and best practice)
• Experience will evolve solutions and designs that
  are closer to the problem domain
• Once a strategy and infrastructure is in place,
  reuse is an obtainable goal that results in cost,
  delivery and maintenance improvements

13
Value of understanding the basic principles -
developers

• Broaden skill set
• good for career
• good for company
• Better positioned to leverage emerging
  technologies and processes
• Knowledge is empowerment
• know the principles to embrace new paradigm
• know the principles to resist new paradigm
• but know the fundamentals (be able to debate
  from a solid knowledge base, not an emotion base)

14
Organization commitment to OO

• Rarely does a successful team just start OO
• Both management and development teams must be
  committed to success
• There must be a willingness to pursue a slightly
  different way of doing things
• There must be a understanding of why a slightly
  different way of doing things is being pursued
• Openness to address issues and risks is essential
• Training is a must
• Requires changes in infrastructure
• Process is an absolute
• The temptation to panic must be resisted - rarely
  is it as bad as it looks

15
Organization commitment to OO
Did I mention that - Both management and
development teams must be committed to success
16
One other thing before the fundamentals

• A good OO system will provide all of the
  advertised advantages and benefits, a bad OO
  system will make you long for the days of pencil
  and paper
• As with all software development efforts, quality
  has to be pursued and measured - the fact that OO
  is attempted is good but not good enough
• standards must be pursued
• understanding and justifying why a class was or
  was not created is needed to give design efforts
  validity
• crucial during an organizations initial startup
• Metrics must be determined and applied (trust me
  rarely cuts it these days)
• measured reuse
• measured development cycle length
• measured time required for correction on the bench

17
OO fundamentals
Basic Principles
18
OO basic principles

• abstraction
• encapsulation
• relationship
• polymorphism
• reuse

19
Abstraction

• Abstraction - the representation of important
  details of a problem domain entity
• manages/reduces complexity (some details are not
  important to the problem solution)
• problem domain and perspective dependent (what is
  important to one problems solution may not be
  important to anothers solution)

Example Concepts important to an air traffic
control game
Aircraft
Game players
Computer
ATC Controller
20
Encapsulation
Definitions -

• General - grouping of problem domain entity
  related concepts and features into a single,
  cohesive concept
• OO - the combining of operations and attributes
  representing state into an object type so that
  state is accessible or modifiable only via the
  respective interface

Supporting concept -

• Information hiding - restricting the external
  view of information and implementation within an
  abstracted entity. Focus on the interface - how
  the entity behaves, not on how the behavior is
  implemented
• A key concept when building component based
  architectures/frameworks (communication is by
  interface not implementation)

21
Relationship

• Abstracting problem domain subjects into single
  cohesive entities is one thing, but the real
  strength of the OO paradigm is how those entities
  relate to one another
• entities can request services from other entities
• entities can be combined to form larger more
  complex objects that can share behaviors
• this can be done from a hierarchical structure
  perspective or
• entities attributes can be themselves other
  entities

22
Polymorphism

• Polymorphism -
• Polymorphism is essentially the ability of
  multiple entities that have assumed the behavior
  and state of a single parent entity to
  dynamically respond differently to the interface
  of a behavior defined by the parent entity
  (isnt that a mouthful)
• poly (many) morphism (type/form)

23
Polymorphism example
Example lets assume that all of these rides
have a parent entity called vehicle and that
vehicle defines a behavior called turn
Each one of these entities requires a unique
implementation of the turn operation at
runtime At runtime, the operating environment
will be able to determine which implementation of
turn to use by virtue of the unique turn
implementation provided by each specific vehicle
being used
24
Reuse
Definition Reuse - the strategy of using
architecture, design patterns and/or software
components in the design and implementation of
multiple software systems.
Reuse should not be confused with code
salvaging, opportunistic but unplanned for use
of code snippets. True Reuse is only
accomplished via an established plan and
structured configuration control.
25
Typical Reuse Myths

• Software reuse is the silver bullet to decreasing
  software development costs
• true, successful software reuse programs can
  reduce software development cost but only after
  significant investment in time and resources
  required for infrastructure support
• All software should be reusable
• false, only those components that have some type
  of strategic value should be reusable. Trying to
  make every component reusable would be virtually
  impossible support
• OO paradigm makes software reuse easy to
  accomplish
• false, easier maybe but easy no. A successful
  software reuse program is 90 good planning and
  execution and 10 technology and etc

26
Reuse - somewhat encapsulated
For the purpose of this presentation, reuse is
best described as an analogy between
object-oriented software components and hardware
components such as computer parts, integrated
circuits, and other plug-and-play
strategies Cost benefits will be only be
obtained when the same degree of plug-and-play
that hardware environments have is achieved with
software components
27
Reuse issues

• Reuse is dependent on architecture strategies and
  development methodologies
• decision needs to be made if reuse is important -
  effects all design decisions
• not all software components are destined for
  reuse status
• architectures should be the target reuse
  opportunities
• Reuse is not accomplished overnight
• Reuse is an evolving principle that builds
  gradually returns investment gradually
• Return on investment can only be determined after
  a significant time frame has passed

28
Reuse - primary success factors

• Reuse can only be accomplished via a defined
  management and architectural strategy
• Configuration management (CM) is crucial
• Libraries of reusable components must be
  supported (easily accessible)
• Process is needed for determining when a
  component should be reusable
• Versioning can be difficult
• Adherence policies and plans must be developed
  and followed
• Failed reuse is rarely a technology problem and
  mostly an administrative and/or planning problem
• Expensive startup cost
• Return on investment is far-term, not near-term
• Constant coordination issues require full-time
  administrator

29
Reuse - Obstacles

• If a strategy is not in place for determining
  when a development component is to be reused,
  opportunity is lost and support increases
• Designing a component for reuse requires extra
  effort said effort must be recognized and
  encourage for developers to consider worth
• Maintainability and versioning require
  maintenance and administration
• Reusable components must be easily accessible and
  supportable
• Developers done not understand appropriate use of
  language concepts
• If developers are rewarded for lines of code,
  reuse will never be achieved
• Requirements can often cause a developer to
  attempt to write one component for all needs.
  While OO can assist this, diminishing returns can
  be quickly reached and the component becomes
  un-maintainable

30
OO fundamentals
Basic Concepts that Support the Principles
31
What are the basic concepts?

• Object
• Class
• Class Relationship

32
Object - definition

• An object is a particular instance of a defined
  abstracted and modeled entity with
• identity
• state
• behavior
• Objects are generally defined in terms of the
  problem domain
• Abstraction is crucial to successful
  object-development
• In design, a practical approach is needed for
  object definition and development - depends on
  the problem domain, architectural approach and
  skill set levels

33
Object - what it represents

• Objects can represent
• any physical entity
• conceptual entities
• problem domain process (manufacturing, chemical,
  timing, storage)
• problem domain entity (events, relationships,
  goals)
• software domain entity (GUI component, arrays,
  lists, hierarchies)
• software domain process (add, delete, timing
  strategies, interation schemes)
• software domain design pattern (singleton,
  controller, factory)

34
Class - definition,types and relationships

• Relationships
• generalization
• realization
• association
• dependency
• composition
• aggregation

• Definition
• key concepts
• structure
• abstraction examples

35
Class - definition

• Definitions abound but key point is -
  representation of an entity (state and behavior)
• A description of a set of objects that share the
  same attributes, operations, relationships, and
  semantics
• An implementation concept that defines the stored
  data and associated procedures for manipulating
  the stored data in support of the instances of
  the class (objects) (DSOU)
• A class defines the attributes and behaviors that
  each object created from the class will possess
  (GIL)

36
Class - key concepts

• THE KEY CONCEPTS TO CONSIDER
• ABSTRACTION What is actually being represented
  and modeled?
• ENCAPSULATION State and behavior (attributes and
  methods) are collocated
• A class should be the single expert regarding the
  entity that it represents
• Focus is on only those elements that are
  important to the problem domain

37
Class - structure identification

• All classes should have some identification type
  characteristic
• name
• index id
• feature
• type
• Just for grins - An exception to this is Java
  anonymous inner classes (at least the
  identification attribute is not viewable by the
  programmer)

38
Class - structure attribute

• As with the various definitions of class,
  definitions of attribute are many but key point
  is - representation of a quality or feature of
  the entity being modeled (representation of
  state)
• A named property of a classifier that describes a
  range of values that instances of the property
  may hold (THREE1)
• A named characteristic or property of type
  (THREE2)
• The description of a field present in all the
  instances of a class.

39
Class - structure method

• The definition of methods are also many but the
  primary thought is - a method is a communication
  vector between a caller an a functionality/behavio
  r related to an entity (representation of
  behavior)
• A method defines a subset of the abstracted
  entitys overall behavior
• A procedure that executes related steps or
  instructions related to the respective message
• An implementation of an operation related to an
  abstracted entity
• A Smalltalk term for a routine
• In the UML, the specific implementation or
  algorithm of an operation for a class.
  Informally, the software procedure that can be
  executed in response to a message

40
Class - abstract example
Consider the ATC simulation mentioned earlier in
the presentation - important attributes would be

• AC type
• current speed
• current altitude

Un-important attributes would be

• color
• armament
• radar capabilities

41
Class - abstract example (on the other hand)
Consider if the F22 Raptor is being modeled for
mission capabilities, the following attributes
would be important.

• AC type
• current speed
• current altitude
• armament
• radar capabilities
• color

42
OO fundamentals

• Class Relationships

43
Class - relationship generalization (inheritance)

• What is inheritance?
• (LAR) A feature of object-oriented programming
  languages by which classes may be specialized
  from more general superclasses. Attributes and
  method definitions from superclasses are
  automatically acquired by the subclass (depends
  on accessibility options)
• (PAGE) By subclass S from class C, the facility
  by which a subclass S has implicitly defined
  upon it each of the attributes and operations of
  C as if those attributes and operations had been
  defined upon S.

• Purpose -
• Extend and generalize an abstraction
• Consistency between behaviors and states
• Reuse opportunity

44
Class - relationship generalization (inheritance)

• What does all this mean? Relationships are built
  and extended structural from the general to more
  specific.
• Superclass is a class that has been inherited
  from
• Subclass is-a-kind-of superclass
• Static structure - does not imply process
• Visibility issues in parent class (see
  guidelines)

45
Class - relationship generalization (inheritance)
Are there constraints - yes abstract and final

• When a class or one or more class methods are
  abstract, method implementations have not been
  provided and the class cannot be instantiated
  (the class can only be a building block). The
  subclass must provide implementations to all
  abstract methods.
• When a class is final, it cannot be a superclass
  (building block)

This can be a very powerful tool when
establishing reusable architecture APIs.
46
Class - relationship generalization (inheritance)
Guidelines (da rules) -

• A subclass can have additional attributes and
  methods but rules apply
• When a childclass can override all public and
  protected methods of the superclass (private
  methods are not seen by the subclass)
• When a superclass is final, it cannot be
  inherited
• When a superclass method is marked final, it
  cannot be overridden
• When a superclass method is abstract, it does not
  provide an implementation (subclass must provide
  the implementation
• If a superclass method implementation is only
  going to be used by a single subclass, then that
  method should be declared abstract in the
  superclass and the implementation should be
  placed in the subclass
• In general - classes should not be subclassed
  unless the intention is on modifying or enhancing
  the fundamental behavior of the class

(LAR, PAGE, GIL)
47
Class - relationship realization

• What is realization?
• (LAR) A set of signatures of public operations.
• What is promised a contract if class A
  implements interface Y, class A commits to
  providing implementation to all methods declared
  in Y
• Related to polymorphism
• Definition of common, specific behaviors

Realizations are supported by interfaces - a
named set of operations that characterize the
behavior of an abstract entity
48
Class - relationship realization
What does this mean and how is it different
from generalization? As with generalization,
the strategy behind realization is to define a
consistent interface to the abstracted
object. Anything that implements the Vehicle
interface must provide an implementation to the
defined methods - its a usage contract.
49
Class - relationship realization

• Guidelines (more rules) -
• When a set of classes share nothing but a common
  behavior and default method implementations are
  not needed
• Interfaces generally only specify a limited part
  of the behavior of a class or component
• (Java Unique) When several behaviors from
  multiple classes are needed, interfaces can
  provide a form of multiple inheritance
• (Java Unique) Attributes (state) cannot be
  defined aside from constants

50
Class - relationship association
What is an association?

• (LAR) A uses relationship, in which objects
  communicate via messages
• (ROSE) Associations provide the pathway for
  communication
• When modeling, associations represent structural
  relationships

Just to confuse the issue - aggregation and
composition relationships are specialized
associations whose use is dependent on the level
and type of modeling that is being done - more
on that later
51
Class - relationship association
Its important that this relationship is
understood. This is a structural relationship
that facilitates communication between
objects. This is also called a uses
relationship (somewhat confusing when we discuss
the dependency relationship).
52
Class - relationship dependency

• A dependency relationship reflects when a class
  (or package) requires another class (or package)
  for non-structural purposes
• when a class is used in a methods parameters
• when a class is used as a local reference within
  a methods body
• when a class is used as a methods return type
• generally thought of as a using relationship

Class Aircraft public void
startEngine(SecurityLock lock) . .
Class Aircraft public void
startEngine(SecurityLock lock)
IndicatorLight startLight() .
startLight.illuminate() .
Aircraft has a dependency on IndicatorLight
Aircraft has a dependency on SecurityLock
53
Class - relationship dependency
54
Class - relationship dependency
Note the difference between dependency and
association relationships.
55
Class - relationship aggregation
What is an aggregation?

• (LAR) A kind of association used to model
  whole-part relationships between things. The
  whole is generally called the composite, but the
  parts have no standard name - part of component
  is common
• (THREE2) A form of association that specifies a
  whole-part relationship between an aggregate (a
  whole) and a constituent part

Bottom-line -
A standard association denotes a type of
structural uses relationship while an
aggregation reflects a structural has-a
relationship. Aggregation to an object is
considered to be sum of its parts.
56
Class - relationship aggregation
57
Class - relationship aggregation

• Guidelines (more rules) -
• A part may belong to more than one aggregate
• A part may exist independently of the aggregate
• An aggregate may not be directly or indirectly
  part of itself
• There cannot be any cycles in the directed paths
  of aggregations links

58
Class - relationship composition
What is an composition?

• A form of association that specifies a whole-part
  relationship between an aggregate (a whole) and a
  constituent part

Bottom-line -
A standard association denotes a type of
structural uses relationship while an
aggregation reflects a structural has-a
relationship.
59
Class - relationship composition
Note - diamond should be filled in (Rose doesnt
support composition)
60
Class - relationship composition

• Guidelines (more rules) -
• A part may belong to only one composite
• A part shares lifetime with composite
• can be created after composite is created
• must die when composite dies
• A composite has sole responsibility for the
  creation and destruction of its parts

61
Class - relationship aggregation vs. composition
Dont get hung-up on the differences between
aggregation and composition. The majority of
modeling can be done without this distinction.
62
OO fundamentals

• Creating Quality Classes -
• The basics

63
Creating quality classes -what are the criteria?

• What is the class definition based on?
• How is the classed created and controlled?
• How do modifiers change a classes perspective in
  a system?
• Instance vs. class methods and attributes?
• What is coupling and how does it effect a class?
• What is cohesion and how does it effect a class?
• What are design patterns?
• Definition
• Composite
• Singleton
• Command

64
Creating quality classes
Here are a few things to think about when
creating classes -

• A class should describe a single entity
• the class should be the sole expert of its domain
• attributes and behaviors (representing state and
  behavior) should be unique to that entity
• the methods of the class should be cohesive
  (supporting only the operations needed to
  represent the class responsibility)
• Planning should be given as to how a class is
  instantiated
• within the controlling class/process, when should
  a class be instantiated
• classes that contain other classes as attributes
  should be responsible for the instantiation of
  those classes
• when should classes be instantiated up-front
  and on-the-fly?

65
Creating quality classes
An important factor to creating a well-designed
class is how well the class Hides its internal
data and behaviors from other classes effective
use of Data hiding. This prevent user classes
from a high coupling relationship with the
class. Each class or member should be as
inaccessible as possible.
66
Class - modifiers

• When is a class concrete?
• Modifiers - how is a class represented in the
  system?
• concrete
• abstract
• static
• final
• public (access modifier)
• private (access modifier)
• protected (access modifier)

Access modifiers control the visibility of a
classes methods and attributes to other classes
67
Class - modifier concrete
What is a concrete class? A class that can
be directly instantiated. All methods have been
provided implementations. The opposite of an
abstract class Only concrete classes can be
instantiated
68
Class - modifier abstract

• What is abstract class?
• A class with an abstract method (no
  implementation
• provided or declared abstract with default
  implementation)
• An abstract class that cannot be instantiated
• instances cannot be created
• intended for specialization purposes

69
Class - modifier abstract
Abstract classes are used to allow subclasses to
provide method implementation (an abstract method
can provide a default implementation). Abstract
classes are very important when used to setup
frameworks and reusable architectures. If a
subclass fails to provide an implementation of a
superclasses abstract methods, it to become
abstract. If a class implementing an interface
fails to provide an implementations to the
interfaces declared methods, it to becomes
abstract.
70
Class - modifier abstract

• Usage guidelines -
• Only descendants who provide implementation to
  all abstract methods can be instantiated
• An abstract class can totally consist of
  abstract methods
• An abstract class can contain concrete methods
• An abstract class can consist totally of
  concrete methods (but must be declared)
• This should be the primary vector for
  inheritance (generalization) the class being
  inherited should usually be intended for
  specialization (abstract)

71
Class - modifier static
What is a static when used with a class?
When a method or attribute is declared static,
only one occurrence of the method or attribute
exists in the system, regardless of the
number of object instances of the class
(additional information is provided in
instance/class attributes and methods slide)
72
Class - modifier static

• Rules
• static methods may only access its classes
  static data (non-static data is inaccessible)
• static methods can only call its classes static
  methods (non-static methods are no inaccessible)
• static methods do not have this (reference to
  currently executing object - no instance for
  this to refer to)
• static methods may not be overridden by
  subclasses non-static methods

Java - inner classes can be static static also
used to build classes that do not need to be
instantiated Example, math libraries and print
systems
73
Class - modifier final
When is a final used with a class? Final
classes cannot be sub-classed. Final methods
cannot be overridden. Final attributes cannot
be changed (if attribute is an object, object
state is changeable as long as state is not
final). Java Particular - PI in
java.lang.Math is final final is Java unique
consts in C and define in C.
74
Class - access modifier public
When is a public used with a class? When a
class, method, or attribute is to be accessible
without restriction. When an attribute is
public, encapsulation and data hiding are
difficult to ensure and enforce. Java
Particular - all classes except for inner classes
must be public but some or all methods and
attributes could be private or protected.
75
Class - access modifier private
When is private used with a class? When a
method or attribute can only be seen by an
instance of the class that declared it. When
an attribute is private, it can only be accessed
by methods within the class. Private
attributes of super classes are not accessible by
any subclasses Java Particular - the only
classes that can be private are inner classes
76
Class - access modifier protected
When is protected used with a class? When a
method or attribute can only be seen by an
instance of the class that declared it or
classes within its package. Unlike private,
a protected attribute of method can be seen from
a subclass.
77
Class - access modifier package-protected
What is package-protected? The member is
accessible from any class in the package where
it is declared. Known as default access, this
is the access level when no access modifier is
specified As with protected, a protected
attribute of method can be seen from a
subclass. True or false can this be declared
explicitly?
78
Class - access modifier access modifiers
overriding

• When a subclass is overriding methods found in
  the superclass, a order of priority is observed
• the order - private, (default - Java unique)
  protected, public
• the overriding methods cannot be made more
  private, only more public

Example - class Airplane long altitude
long currentAirSpeed protected void
adjustAirSpeed() public long getAirSpeed()
class Helicopter extends Aircraft private
void adjustAirSpeed() ILLEGAL
- OVERRIDING METHOD CANNOT BE MORE
PRIVATE public long adjustAirSpeed()
LEGAL public long getAirSpeed()
79
Class - instance methods and attributes

• Instance methods and attributes
• available only when a class is instantiated
• the usual approach
• instance methods have access to all visible class
  methods and attribute

Class declaration Class Airplane long
altitude int airspeed public long
getAlitude() public int getAirSpeed() Usage
example - long currentAlitude 0 Airplane
bomber new Airplane() . . . . currentAltitutde
bomber.getAlitude()
80
Class - class methods and attributes

• Class methods and attributes
• available any time after system startup no
  instances required
• indicated by keyword static
• class methods cannot access instance methods or
  attributes at any time(even when instance exists)

Class declaration Class Airplane static
private long altitude // class attribute
private int airspeed // instance
attribute static public long getAltitude()
// class method int temp
getAltitude() public int getAirSpeed()
// instance method return
airspeed Usage example - // use of class
method long currentAltitude Airplane.getAltitude
( ) Airplane bomber new Airplane() // use of
instance method int currentAirspeed
bomber.getAirSpeed()
81
Class - class methods and attributes
Problem Example -
Usage problem example - // Illegal, not a class
method int currentAltitude Airplane.getAirSpeed(
) Airplane bomber new Airplane() // use of
instance method long altitude
bomber.getAirSpeed()
Class declaration Class Airplane static
private long altitude // class attribute int
airspeed // instance
attribute static public long getAltitude()
// class method int tempA
getAirSpeed() // ILLEGAL - CANNOT ACCESS
INSTANCE METHOD int temp getAltitude()
public int getAirSpeed() // instance
method int temp getAltitude()
//LEGAL - INSTANCE METHODS CAN ACCESS CLASS
METHODS AND ATTRIBUTES return
airspeed
82
OO fundamentals

• Creating Quality Classes -
• Coupling and Cohesion

83
Creating quality classes -coupling

• Definition
• same as it was for SA or procedural paradigms
• a degree as to how related a class is to the
  classes that it has relationships with (how many
  classes are there and what degree of
  interconnections do they have?)
• a measure in terms of how interconnected system
  components are

84
Creating quality classes -coupling

• Goal - low coupling
• easier to extend and modify designs of classes
• easier to maintain systems comprised of classes
• is represented by the number of relationships and
  to the degree of complexity that those
  relationships have
• high coupling is a large number of relationships
  and high degree of complexity
• low coupling is lower number of relationships
  with low degree of complexity
• There will always be a degree of coupling must
  focus design effort on minimizing it to support
  reusability and maintainability goals

85
Creating quality classes -coupling

• Low coupling benefits
• abstraction better represented
• fewer connections between classes (lower
  complexity) reduces the chance of changes in one
  class effecting changes in associated classes
• improves reuse opportunity
• simpler to understand classes

86
Creating quality classes -coupling

• Types of coupling
• data
• stamp
• control
• common
• content

87
Creating quality classes -coupling
88
Creating quality classes -coupling
89
Creating quality classes -coupling
90
Creating quality classes -coupling
91
Creating quality classes -cohesion

• Definition
• same as it was for SA or procedural paradigms
• Definition - a degree as to how related the
  responsibilities (represented by
  attributes/state and methods/behaviors of a class
  are
• a measure in terms of how a classes behaviors and
  attributes are related

92
Creating quality classes -cohesion

• Goal - high cohesion
• behavior and attributes should represent a single
  entity of the problem domain
• tightly related responsibilities associated with
  the appropriate degree of work for the
  abstracted entity
• should always consider how the behaviors within
  the class relate to each other
• easier to extend and modify designs of classes
  with high cohesion
• easier to maintain systems comprised of classes
  of high cohesion
• Inheriting attributes and behavior from a
  super-class can weaken cohesion

93
Creating quality classes -cohesion

• High cohesion benefits
• supports low coupling
• improves reuse opportunity
• simpler to understand classes
• abstraction better represented
• better maintainability

94
Creating quality classes -cohesion

• Types of cohesion (SOM95)
• Coincidental (weak)
• Logical association (weak)
• Temporal (weak)
• Procedural (weak)

• Communicational (medium)
• Sequential (medium)
• Functional (strong)
• Object (strong)

95
Creating quality classes -cohesion
96
Creating quality classes -cohesion
97
Creating quality classes -coupling and cohesion
A balance is needed -

• Balanced is achieved only when the appropriate
  responsibilities/behavior has been assigned (a
  class is the expert in its problem domain)
• High coupling can lead to low cohesion and vice
  versa
• Coupling and cohesion is essentially the same
  between SA and OO
• low coupling and high cohesion is good for both
• high coupling and low cohesion is bad for both
• high cohesion generally leads to low coupling and
  vice-versa

98
OO fundamentals

• Creating Quality Classes -
• Overloading and Overriding

99
Creating quality classes -overloading
100
Creating quality classes -overriding
101
OO fundamentals

• Creating Quality Classes -
• Design Patterns
• and
• MVC

102
Creating quality classes -OO and design patterns

• Definition of design patterns - structurally
  names, analyzes, and proposes solutions to
  recurring design needs and issues typically found
  in object-oriented systems
• avoids so-called reinventing the wheel for
  solutions
• illustrates best practices solutions to common
  problems
• allows developers to more readily capitalize on
  research of others
• provides lowest common denominator for
  communication between development groups
• when discussing a factory solution, everyone
  understands the problem and the solution strategy
• communication tends to be more direct and focused
  when team is in design/solution mode

103
Creating quality classes -OO and design patterns
Sure, Ive found that the design patterns are
useful, but their advantage is not only in
creating re-usable, easy to understand code -
but, more importantly in helping me clarify the
way that I think about programs. I find this
second advantage much more substantial.
Cristobal Baray CS Phd Candidate Indiana
University www.cs.indiana.edu/cbaray/projects/m
vc.html
104
Creating quality classes -OO and design patterns

• Think the typical architecture analogy
• there are inherent approaches to constructing a
  building
• most structures require some type of foundation
• building materials are usually categorized for
  certain uses

105
Creating quality classes -OO and design patterns

• Sources for design patterns (there are many but
  here are two very prominent sources)
• GRASP
• Craig Larman
• Applying UML and Patterns
• Patterns for using basic fundamental principles
  in defining classes and objects
• Gang of four (GoF)
• Erich Gamma, Richard Helm, Ralph Johnson, John
  Vlissides
• Design Patterns - Elements of Reusable
  Object-Oriented Software
• Focused on communication between objects and
  classes architectural structures
• Becoming the defacto standard

106
Creating quality classes -OO and design patterns

• GRASP
• Expert
• Creator
• Controller
• Low Coupling
• High Cohesion
• Polymorphism
• Pure Fabrication
• Indirection
• Dont Talk to Strangers (Law of Demeter)

Larman identifies his patterns as GRASP (General
Responsibility Assignment Software Patterns) to
reflect the importance that he places on
understanding fundamental principles of designing
object-oriented software. He has taken key
fundamentals of object and system design and
wrapped them into a common format and
presentation. Key concept to the GRASP - how to
place a responsibility where it belongs (what is
the right class).
107
Creating quality classes -OO and design patterns

• GRASP - Low Coupling
• Solution Assign a responsibility so that
  coupling remains low
• Problem How to support low dependency and
  increased reuse?
• Strategy As stated in the coupling slides
  (slides developed using the pattern)
• low coupling encourages reuse and maintainability
• high coupling is vice versa
• must consider effect of this pattern on other
  GRASPs
• GRASP - High Cohesion
• Solution Assign a responsibility so that
  cohesion remains high
• Problem How to keep complexity manageable?
• Strategy Stated in the cohesion slides (slides
  developed using the pattern

108
Indirection GRASP - problem example
Indirection - Assign the responsibility to an
intermediate object to mediate between other
components or services so that they are not
directly coupled. Goal is to avoid high
coupling.
109
Indirection GRASP - solution example
110
Indirection GRASP
There is nothing new or novel about the use of
the Indirection pattern. The point that should
be derived here is what the design reason for
wrappering classes is not because I need this
function but because of design strategy that
supports a specific goal - low coupling. Relates
to being able to validate a design.
111
Danger Will Robinson..
If GRASP or some other defined strategy or
process is not used to assign responsibilities
to classes/objects, the design cannot be
considered OO. This is one of the reasons many
first OO projects fail - a lack of class
design guidelines. Strategies documented in
design guideline backs up the design with more
than it just feels right.
112
Creating quality classes -OO and design patterns

• Structural
• Adapter
• Bridge
• Composite
• Decorator
• Façade
• Flyweight
• Proxy

• Behavior
• Chain of responsibility
• Command
• Interpreter
• Iterator
• Mediator
• Memento
• Observer
• State
• Strategy
• Template Method
• Visitor

The GoF patterns identify common
architectural mechanisms for resolving
typical issues and needs in object-oriented system
s. These patterns are not problem- domain
specific nor do they represent complex
theory. They also do not represent designs for
entire applications or subsystems.

• Creational
• Abstract Factory
• Builder
• Factory Method
• Prototype
• Singleton

113
Creating quality classes -OO and design patterns
For GoF -

• A distinguishing feature of a pattern is that it
  states (in some form) its
• definition (GRASP also)
• applicability
• consequences (GRASP also)
• To support the above, patterns should also state
  (also in some form)
• motivation (GRASP also)
• structure
• participants
• and collaborations

114
Creating quality classes -OO and design patterns
The material on the following GoF slides is
presented almost exactly as it appears in the
book - Design Patterns - Elements of Reusable
Object-Oriented Software There was no reason to
paraphrase, reword, or redo the authors
presentation of this material - it stands on its
own as is. This book should be required reading
for any developer.
115
Composite pattern (GoF)

• Definition - Compose objects into tree structures
  to represent part-whole hierarchies. Composite
  lets clients treat individual objects and
  compositions of objects uniformly.
• Applicability -
• The Composite pattern is used when
• a representation of part-whole hierarchies of
  objects is needed
• when client objects should be able to ignore the
  difference between compositions of objects and
  individual objects. Clients will treat all
  objects in the composite structure uniformly
• Consequences -
• Defines class hierarchies consisting of primitive
  objects and composite objects
• Simplifies clients
• Simplifies adding new components to a design
  and/or implementation
• Can make a design over general (a negative)

116
Composite pattern (GoF) problem example
117
Composite pattern (GoF) solution example
118
Singleton pattern (GoF)

• Definition - Ensure a class only has one
  instance, and provide a global point of access to
  it
• Applicability -
• The Singleton pattern is used when
• there must be exactly one instance of a class,
  and it must be accessible to clients from a
  well-known access point
• when the sole instance should be extensible by
  sub-classing, and clients should be able to use
  an extended instance without modifying their code
• Consequences -
• Controlled access to sole instance
• Reduced name space
• Permits refinement of operations and
  representation
• Permits a variable number of instances
• More flexible than class operations

119
Singleton pattern (GoF) example
120
Command pattern (GoF)

• Definition - Encapsulate a request as an object,
  thereby letting you parameterize clients with
  different requests, queue or log requests, and
  support undoable operations
• Applicability -
• The Command pattern is used when
• objects are parameterized by an action to perform
• requests can be specified, queued and executed at
  different times
• command undo is needed
• logging changes is needed to support recovery
  from a system crash

121
Command pattern (GoF)

• Consequences -
• Command decouples the object that invokes the
  operation from the one that knows how to perform
  it
• Command are first-class objects. They can be
  manipulated and extended like any other object
• You can assemble commands into a composite
  command. An example is a Command designed to
  handle groups of commands
• Its easy to add new Command since existing
  classes do not have to be changed

122
Command pattern (GoF) problem example
Typical scenario - GUI processing of commands
123
Command pattern (GoF) solution example
124
Creating quality classes -OO and design patterns

• With the previous in mind consider these key
  concepts
• program to the interface, not the implementation
• design for possible reuse, not absolute reuse
• class design strategies base on patterns and
  software engineering best practices is crucial to
  an OO success

125
One last thing about patterns, Model View
Controller(MVC)

• MVC - a very popular pattern that
  segregates/decouples
• data (related state and behaviors) and the
  respective presentation and
• controlling mechanisms into separate distinct
  components (model, view,
• and controller)
• Originated as a pattern from Smalltalk user
  interface development
• Whats the point? Usage of design patterns such
  as this
• clarifies design
• improves reuse opportunity
• improves scalability
• provides more powerful user interfaces

126
MVC
127
MVC - Example
Air Traffic Control Game
128
OO fundamentals

• Creating quality classes -
• Composition vs. inheritance

129
Creating quality classes - composition vs.
inheritance
Composition (aggregation and composition
relationships) and inheritance (generalization)
are the two primary strategies for reusing
functionality in an OO system. But each has
advantages and disadvantages. A system design
can be drastically effected depending on how
those advantages and disadvantages are addressed.
130
Creating quality classes - composition vs.
inheritance
Inheritance -

• Advantages
• defined statically at compile time
• easy to use
• overriding operations straight forward and can
  effect other inherited operations

• Disadvantages
• cant change implementations of inherited methods
  at run-time
• superclasses define subclass physical
  representation or implementation
• changes in a superclass can have immediate
  compile time effect on subclasses

In regards to the disadvantages, implementation
dependencies have a strong negative impact on
reuse opportunities.
131
Creating quality classes - composition vs.
inheritance
Composition -

• Advantages
• defined dynamically at run-time via parent
  objects
• requires adherence to interfaces stronger design
  focus, doesnt break encapsulation
• fewer design dependencies
• encourages high cohesion

• Disadvantages
• number of objects increases (some maintenance
  overhead)
• if reuse library does not exist, composition
  becomes more difficult

132
Creating quality classes - composition vs.
inheritance
133
Creating quality classes - composition vs.
inheritance

• Bottom line
• inheritance is considered an overused reuse
  mechanism
• design focus should be on programming to the
  interface (API) and not specific implementations
• inheritance needs to be use along with
  composition and not instead of

134
OO Fundamentals

• Success Factors, Practical Benefits, Examples and
  Other Stuff

135
Other important factors to successful OO

• Analysis and design activity must be
  architecture-centric
• Solution needs to be based on component-based
  architectures
• Formal process or approach to software
  engineering is needed
• design artifacts must be clear as to what the
  primary complex parts of the system are (example
  Software Architecture Document)
• incremental
• iterative
• metrics to verify success
• configuration management is essential
• reuse management
• artifacts of design must also be considered