Objects versus Components

1
Objects versus Components

• CSCI3007 Component Based Development

2
Topics

• Components from an object-oriented perspective
• Principles of object-oriented programming
• What is an object?
• Principles of components
• Aspects of components
• What is a component?

3
Components from an OO perspective
Object Principles
evolving
1995-
1967-
1989-
Distributed Object Technology
Components
Object-oriented Programming
Language neutral. Multiple address
spaces. Non-integrated services
Only interoperable within a specific language.
Single address space
Packaging of object implementations for easier
use. Integrated services
4
Principles of OO Programming (1)

• Object Instance
• A way of representing a behavioural abstraction
  in software
• Object Class
• A classifier of object instances. A cookie
  cutter creates and describes the objects it
  classifies. All object instances belong to
  exactly one class.
• Interface
• Defines capabilities of objects as a set of
  operations that can be invoked by sending the
  object a message. One object can support many
  interfaces one interface can be realized by many
  objects

5
Principles of OO Programming (2)

• Identity
• Every object has a unique tag or identifier by
  which it can be accessed
• Unification
• An object bundles together data and the
  operations that manipulate them
• Encapsulation
• All design decisions that it is unnecessary for
  the client to know about are hidden from it by
  the server
• Polymorphism
• The client is only interested in the behavioural
  interface, not in the class of the object that
  supports it

6
Principles of OO Programming (3)
ObjectID
7
What is an Object?
Implementation unit
1..
Interface
0..1
Class Implementation
source
realization
1

Specification unit
Class
Run-time (execution) unit
1

Object
instance
8
Principles of OO Construction

• Objects are about behaviour, not representation
• As opposed to entities which are concerned with
  (data) representation, not behaviour
• Develop to interface, not to implementation
• Client needs to know how to use the services of a
  server, not how the services are delivered
• Design by Contract
• Given certain preconditions guaranteed either by
  the environment or by the client itself, the
  server guarantees to provide a legally requested
  service (or throw an exception)

9
Principles of Components (1)

• Components are units of deployment and
  replacement
• Implies that it is well-separated from its
  environment and other components
• Therefore encapsulates its constituent features
• Will never be deployed partially
• Implies a Third Party has no access to
  construction details
• Components are units of third-party composition
• Must be sufficiently self-contained
• Needs to have clearly specified what it requires
  and what it provides
• Implies interaction is allowable only through
  well-defined interfaces

10
Principles of Components (2)

• Components have no persistent state
• Cannot be distinguished from copies of itself
• Possible exceptions are attributes that do not
  contribute to a components functionality
• E.g., serial numbers for accounting
• Therefore makes little sense to have multiple
  copies in the same system (according to Szyperski
  1997)
• Components are immutable because they do not have
  mutable state
• N.B. by this criterion a database server object
  would be a component, but the database(s)
  maintained by it would not be

11
Aspects of Components

• Components
• Have specifications
• Have implementations
• Not necessarily in an OO language
• Can be deployed
• As binaries
• Can be packaged into modules
• Will normatively conform to a standard
• E.g., CORBA components
• COM and DCOM components
• EJBs

12
What is a Component?
Specification unit
1..

Interface
Component Specification
Implementation unit
1
specification
Component Implementation
Component Module

realization
0..1
1..
file
source
Component
1
1..
1

Component Object
Packaging unit
Run-time (execution) unit
13
Component Deployment
Component Module
1..
1..
Component
file
1
1
installed as


1..
Installed Module
1..
Installed Component
server
Registration unit
Installation unit
14
Components and Classes

• Components can be regarded as a special kind of
  Class
• Has hooks to connect it into the environment
• Can provide other classes (dependent on the
  standard being used)
• The component (with provided classes) is the unit
  of deployment and replacement
• cf. with Object Class
• Booch no class is an island

15
Compile-time and Run-time
Run-time
Compile-time
component
Provided class
At run-time we can create many independent
instances of the component and its provided
classes
16
Example Component Form MS Word
wordDocumentComponent
wordApplicationComponent
file
file
winWord.exe ComponentModule
installed as
wordDocument InstalledComponent
copy
server
installed as
c/../winWord.exe InstalledModule
wordApplication InstalledComponent
server
instance
instance
docObject ComponentObject
applicationObject ComponentObject
17
Example Component Form Enterprise Java Beans
c/../invoice.java ComponentImplementation
invoice ComponentSpec
realization
invoiceBean Component
invoicing Interface
file
invoice.jar ComponentModule
installed as
invoiceBean InstalledComponent
copy
server
c/,,/invoice.jar InstalledModule
instance
invoiceABC ComponentObject
18
Component Standards

• Underlying each component standard is a
  component model
• Defined set of services that support the software
• Set of rules that must be obeyed to take
  advantage of the services
• Simple programming model
• No need to design the infrastructure
• Services include
• Remote access, transactions, persistent storage,
  security
• Typically services are used by configuring, not
  programming

19
Why Standards are Important

• Maximum reuse is achieved by outsourcing
  everything but the prime functionality offered by
  the component
• OO programming styles bends in this direction
• But this leads to a greater number of context
  dependencies which make the component more
  complex to use
• Different platforms, environments, version mixes
  etc.

20
Maximizing Reuse Minimizes Use
Optimal sweet spot can be pushed towards lean
components if context is standardized
Leanness
Robustness
100
reuse (outsourcing)
0
Limited context dependencies stability
Strong functional cohesion limited fat
21
Summary

• Objects and Components are physically and
  conceptually distinct
• Component principles are an extension of Object
  principles
• Component standards help optimize the trade-off
  between leanness and robustness