Abstract data types ADTs

1
Abstract data types (ADTs)

• A stack ADT allows to have more than one
  instance of a stack module
• Define a type and its objects

indicates that details of the data structure are
hidden to clients
2
ADTs

• An ADT module is a module that exports a type,
  along with the operations needed to access and
  manipulate objects of that type.
• An ADT hides the representation of the type and
  the algorithms used in the operations. The
  details of the type is dealt with in the
  implementation of the ADT.
• Correspond to Java and C classes
• Concept may also be implemented by Ada private
  types and Modula-2 opaque types
• May add notational details to specify if certain
  built-in operations are available by default on
  instance objects of the ADT
• e.g., type A_TYPE ? (, ) indicates that
  assignment and equality check are available

3
An examplesimulation of a gas station
module FIFO_CARS uses CARS exports type QUEUE
? procedure ENQUEUE (Q in out QUEUE C in
CARS) procedure DEQUEUE (Q in out QUEUE C
out CARS) function IS_EMPTY (Q in QUEUE)
BOOLEAN function LENGTH (Q in QUEUE)
NATURAL procedure MERGE (Q1, Q2 in QUEUE Q
out QUEUE) This is an abstract data-type
module representing queues of cars,
handled in a strict FIFO way queues are
not assignable or checkable for equality,
since and are not exported. end
FIFO_CARS
gasoline_1, gasoline_2, gasoline_3
QUEUE car_wash QUEUE ENQUEUE (car_wash,
that_car) MERGE (gasoline_1, gasoline_2,
gasoline_3)
4
Object-oriented design

• One kind of module ADT, called class
• A class exports operations (procedures) to
  manipulate instance objects
• often called methods
• Instance objects accessible via references

5
Syntactic changes in TDN

• No need to export opaque types
• class name used to declare objects
• Instead of using the notation type X ? in the
  interface of some module Y to introduce the
  types name, we let the client module to use the
  class name directly.
• In OO we write aX to say object a is of class
  X and a is a reference to an instance object of
  the abstract data type implemented by class X.
• If a is a reference to an object of class X
• a.op (parameters) means invocation of the
  operation op provided by the instance a of class
  X

6
A further relation inheritance

• ADTs may be organized in a hierarchy
• Class B may specialize class A
• B inherits from A
• Conversely, A generalizes B
• A is a superclass of B
• B is a subclass of A

7
An example
8
(No Transcript)
9
Inheritance

• A way of building software incrementally
• A subclass defines a subtype
• subtype is substitutable for parent type
• Polymorphism
• a variable referring to type A can refer to an
  object of type B if B is a subclass of A
• Dynamic binding
• the method invoked through a reference depends on
  the type of the object associated with the
  reference at runtime

10
How can inheritance be represented?

• We start introducing the UML notation
• UML (Unified Modeling Language) is a widely
  adopted standard notation for representing OO
  designs
• We introduce the UML class diagram
• classes are described by boxes

11
UML representation of inheritance
12
UML associations

• Associations are relations that the
  implementation is required to support
• Can have multiplicity constraints

13
Aggregation

• Defines a PART_OF relation
• Differs from IS_COMPOSED_OF
• Here TRIANGLE has its own methods
• It implicitly uses POINT to define
• its data attributes

14
UML Modeling
15
UML Models
16
Ticket Selling BoothUse Case View
17
Ticket Selling BoothClass Diagram
18
Sequence Diagram
19
Component Diagram
20
Statechart diagramState machine view
Shows the history of a ticket to a performance
21
Software architecture

• Describes overall system organization and
  structure in terms of its major constituents and
  their interactions
• Standard architectures can be identified
• pipeline
• blackboard
• event based (publish-subscribe)

22
Standard architectures
pipeline
blackboard
event based
23
Design Pattern

• Christopher Alexander (1977, buildings / towns)
• Each pattern describes a problem which occurs
  over and over again in our environment, and then
  describes the core of the solution to that
  problem, in such a way that you can use this
  solution a million times over, without ever doing
  it the same way.
• At high-level design Architectural Styles
• At low-level design Design Patterns
• Encourages design reuse (intended for OO)
• Used as a means for transferring knowledge from
  experienced designers to novice designers

24
Design pattern definition

• Describe the objects and classes (can be modules)
  that communicate with each other and are
  customized to solve a general design problem in a
  particular context.
• A pattern has four essential elements
• Name a handle we can use to describe a design
  problem, its solution, and consequences in a word
  or two.
• Problem describes when to apply the pattern can
  be a specific design problem or a set of
  conditions to exist.
• Solution describes the elements that make up the
  design, their relationships, responsibilities,
  and collaborations.
• Consequences are the results and trade-offs
  applying the pattern.

25
MVC Pattern in Smalltalk

• MVC (Model / View / Controller) consists of
• Model the application program (object)
• View its screen presentation
• Controller defines the way the user interface
  reacts to user input.

Subscribe Notify model
Controller not shown

26
MVC

• Model notifies the views when its value changes
• Views communicate with model to access new values
• The problem that MVC addresses
• Decoupling objects so that changes to one can
  affect any number of others without requiring the
  changed object to know details of the others.
  Observer design pattern.
• MVC a control panel of buttons, ie, nested view
• A design pattern that let us treat a composite
  view just like we treat one of its components.
  Composite design pattern.
• MVC possible to change a views controller at
  run-time
• Lets you change the way a view responds to user
  input without changing its visual presentation.
  Strategy design pattern

27
Organizing the Catalog
28
Describing Design Patterns

• Pattern name and classification
• Conveys the essence of the pattern (Creatinal,
  Structural, Behavioral)
• Intent short statement to answer
• What particular design issue it addresses? What
  is its rationale?
• Also known as
• other name for the pattern
• Motivation
• A scenario that illustrates a design problem
• Applicability
• In what situations the pattern applies?
• Structure
• Graphical representation of the classes in OMT
  notation

29
Describing Design Patterns .

• Participants
• Classes and their responsibilities
• Collaborations
• Collaboration among participants
• Consequences
• How does the pattern support its objectives?
• Implementation
• Pitfalls, hints, techniques to be aware of when
  implementing
• Sample code
• Code in C , Smalltalk, Java to implement
  pattern
• Known uses
• Examples of the pattern found in real systems in
  other domains.
• Related patterns

30
The Catalog of Design Pattern

• Abstract Factory
• Provide an interface for creating families of
  related or dependent objects without specifying
  their concrete classes
• Example a user-interface toolkit that supports
  multiple look-and-feel standards such as Motif
  and Open-window.
• Adapter
• Convert the interface of a class into another
  interface that clients expect. Adapter lets
  classes work together that couldnt otherwise
  because of incompatible interfaces
• Example component programming
• Bridge
• Decouple an abstraction from its implementation
  so that two can vary independently.
• Example implementation of a portable window
  abstraction in a user interface toolkit. The
  abstraction should enable us to write
  applications that work on both the X window
  system and Presentation Manager.

31
The Catalog of Design Pattern

• Decorator
• Attach additional responsibilities to an object
  dynamically. Decorators provide a flexible
  alternative to sub-classing for extending
  functionality.
• Example a graphical user interface toolkit
  should let you add properties like borders, or
  behaviors like scrolling to any user interface
  component.
• Façade
• Provide a unified interface to a set of
  interfaces in a subsystem. Façade defines a
  higher-level interface that makes the subsystem
  easier to use.
• Example consider a compiler component having
  scanner, parser, Some specialized applications
  may need to access these classes directly. But
  most clients of compiler only want to compile the
  program and dont care about the details of
  compiler.

32
The Catalog of Design Pattern

• Iterator
• Provide a way to access the elements of an
  aggregate object sequentially without exposing
  its underlying representation
• Example an aggregate object such as a list
  should provide a way to access its elements
  without exposing its internal structure. You
  should be able to traverse the list in either
  direction.
• Mediator
• Define an object that encapsulates how a set of
  object interact. Mediator promotes loose coupling
  by keeping objects from referring to each other
  explicitly, and it lets you vary their
  interaction independently.

33
The Catalog of Design Pattern

• Strategy
• Define a family of algorithms, encapsulate each
  one, and make them interchangeable. Strategy lets
  the algorithm vary independently from clients
  that use it.
• Example many algorithms exist for breaking a
  stream of text into lines. Hard coding all such
  algorithms into the classes that require them is
  not desirable.
• Visitor
• Represent an operation to be performed on the
  elements of an object structure. Visitor lets you
  define a new operation without changing the
  classes of the elements on which it operates.

34
Abstract Factory Design Pattern

• Intent
• Provide an interface for creating families of
  related or dependent objects without specifying
  their concrete classes
• Motivation
• A user-interface toolkit that supports multiple
  look-and-feel standards such as Motif and
  Open-window.
• A Kitchen-viewer software that allows the home
  owners to choose between two styles modern an
  antique for their wall and floor kitchen-cabinets
  and then view the kitchen.

35
Abstract Factory Pattern (Kitchen View Example)
Provide an interface for creating families of
related or dependent objects without specifying
their concrete classes Example a user-interface
toolkit that supports multiple look-and-feel
standards such as Motif and Open-window.
36
Kitchen viewer without Design Pattern
Application
Aggregation Kitchen contains a number of
wall-cabinets and floor-cabinets
Implementation dependency

• Cabinet size, location
• No. of knobs

Specialization Wall cabinet can
be ModernWallCabinet or AnticWallCabinet

• Style, color
• Wood / metal

37
Rendering a Kitchen Without applying design
pattern
// NO design pattern // Determine the style //
Assume that the antique style was selected
// Case
statements to select antique or modern // Create
the antique wall cabinet AntiqueWallCabinet
antiqueWallCabinet1 new AntiqueWallCabinet ()
AntiqueWallCabinet antiqueWallCabinet2 new
AntiqueWallCabinet () .. //Create the antique
floor cabinet AntiqueFloorcabinet
antiqueFloorCabinet1 new AntiqueFloorCabinet
() //Create the kitchen object, assuming the
existence of add() method Kitchen antiqueKitchen
new Kitchen() antiqueKitchen.add (
antiqueWallCabinet1, ) . antiqueKitchen.add (
antiqueFloorCabinet1, ) . // Render
antiqueKitchen

Concrete class


//Create the modern wall cabinet
38
Abstract Factory Design Pattern ideaApplied to
KitchenView
Different implementations for getFloorCabinet()
FloorCabinet getFloorCabinet() return new
ModernFloorCabinet()
FloorCabinet getFloorCabinet() return new
AntiqueFloorCabinet()
Abstract Class
KitchenStyle getWallCabinet() getFloorCabinet()
Polymorphism Dynamic Binding
FloorCabinet
WallCabinet

Concrete Class
AnticWallCabinet
ModernKStyle WallCabinet getWallCabinet() FloorCa
binet getFloorCabinet()

AnticFloorCabinet
AntiqueKStyle WallCabinet getWallCabinet() Floor
Cabinet getFloorCabinet()
At RUN TIME myStyle can be ModernKStyle
or AntiqueKStyle
39
Abstract Factory Design PatternApplied to
KitchenView
Client renderKitchen( KitchenStyle )
Kitchen getWallCabinet() getFloorCabinet()
KitchenStyle getWallCabinet() getFloorCabinet()
FloorCabinet
WallCabinet
ModernWallCabinet
AnticWallCabinet
ModernKStyle getWallCabinet() getFloorCabinet()
ModernFloorCabinet
AnticFloorCabinet
AntiqueKStyle getWallCabinet() getFloorCabinet()
40
Code for methodrenderKitchen(KitchenStyle
myStyle)
//Determine style by instantiating my Style of
type KitchenStyle to be either // ModernKStyle
or AnticKStyle (Polymorphism) // Create the
wall cabinets Type determined by the calss of
myStyle (dynamic bind) WallCabinet wallCabinet_1
myStyle.getWallCabinet () .. //Create the
floor cabinet Type determined by the class of
myStyle FloorCabinet floorCabinet_1
myStyle.getFloorCabinet () .. //Create the
kitchen object (in the style required) Kitchen
kitchen new Kitchen () Kitchen.add (
wallCabinet_1, .) //Antic/Modern
WallCabinet is returned Kitchen.add (
wallCabinet_2, .) . Kitchen.add
(floorCabinet_1, ) //Antic/Modern
FloorCabinet is returned Kitchen.add
(floorCabinet_2, )
41
Adapter Design Pattern

• Intent
• Convert the interface of a class into another
  interface that the clients expect.
• Motivation
• We want to use the functionality provided by an
  existing application.
• We want to modify our application as little as
  possible
• We want to be able to easily switch to
  alternative implementations.
• Example an existing financial application
  computes the principal money obtained from
  investing a given amount of money for a given
  number of years in a special type of investment

42
Adapter Class Model

• Write the application against an abstract version
  of the external class introduce a subclass that
  aggregates the external class.

adaptee
clientNameForRequiredMethod()
requiredMethod()
43
Example of AdapterFinancial application
Legacy application computeValue (float
years, float interest, float amount) New
application amount (float
originalAmount, float numYears, float intRate)

legacyAdaptee
44
Implementation
Class FinancialAdapter extends Financial
principal legacyAdaptee null //
Constructors go here . . . / This method
uses the legacy computeValue() method / float
amount ( float originalAmount, float unmYears,
float intRate) return
legacyAdaptee. computeValue ( originalAmount,
numYears, intRate)
The client could be written with a method
parameterizing Financial such as
Void executeFinancialApplicatioin ( Financial
aFinancial)
It could then be executed with the following
setup statement
executeFinanceApplication ( new
FinancialAdapter () )
All calls to the amount () method of Financial
are passed to the legacy method computeValue().
45
Adapter and Java API
Java listeners as adapters
ActionListner
Result of button press
MyClass myMethod ()
MyButton addActionListener ()
46
Comments on Adapter

• Instead of aggregating requiredClass in Slide 16
  we could inherit from it, as long as the language
  supports multiple-inheritence
• Adapter is often used when we create an
  application using library classes, but where we
  want to retain the flexibility to select
  alternative library classes.