Trusted Components Reuse, Contracts and Patterns Prof. Dr. Bertrand - - PowerPoint PPT Presentation

▶
trusted components
SMART_READER_LITE
LIVE PREVIEW

Trusted Components Reuse, Contracts and Patterns Prof. Dr. Bertrand - - PowerPoint PPT Presentation

Jan 10, 2023 115 likes •668 views

1 Last update: 2 November 2004 Trusted Components Reuse, Contracts and Patterns Prof. Dr. Bertrand Meyer Dr. Karine Arnout Trusted Components: Reuse, Contracts and Patterns - Lecture 14 Chair of Softw are Engineering 2 Lecture 14: Observer,

slide-1
SLIDE 1

Trusted Components: Reuse, Contracts and Patterns - Lecture 14

1

Chair of Softw are Engineering

Last update: 2 November 2004

Trusted Components

Reuse, Contracts and Patterns

  • Prof. Dr. Bertrand Meyer
  • Dr. Karine Arnout
slide-2
SLIDE 2

Trusted Components: Reuse, Contracts and Patterns - Lecture 14

2

Chair of Softw are Engineering

Lecture 14: Observer, Mediator

slide-3
SLIDE 3

Trusted Components: Reuse, Contracts and Patterns - Lecture 14

3

Chair of Softw are Engineering

Agenda for today

Observer pattern Event Library Mediator pattern Mediator Library Observer vs. Mediator

slide-4
SLIDE 4

Trusted Components: Reuse, Contracts and Patterns - Lecture 14

4

Chair of Softw are Engineering

Componentizability classification

2.1 Skeleton 2.1.2 No method 2.1.1 Method 2.3 Some library support 1. Componentizable 2.2 Possible skeleton 2. Non-componentizable 1.3 Newly componentized 1.1 Built-in 1.2 Library- supported 1.3.2 Componentizable but not comprehensive 1.3.1 Fully componentizable 1.3.3 Componentizable but unfaithful 1.3.4 Componentizable but useless Design pattern 2.4 Design idea 1.4 Possible component Prototype Flyweight Observer Mediator Abstract Factory Factory Method Visitor Command Composite Chain of Responsibility Builder Proxy State Strategy Memento Decorator Adapter Template Method Bridge Singleton Iterator Facade Interpreter

slide-5
SLIDE 5

Trusted Components: Reuse, Contracts and Patterns - Lecture 14

5

Chair of Softw are Engineering

Observer pattern

“Define[s] a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically.” [GoF, p 293]

* OBSERVER * SUBJECT + MY_OBSERVER + MY_SUBJECT

update* update+ add_observer* add_observer+ remove_observer* remove_observer+ notify_observers* notify_observers+ subject

  • bservers
slide-6
SLIDE 6

Trusted Components: Reuse, Contracts and Patterns - Lecture 14

6

Chair of Softw are Engineering

Class SUBJECT (1/2)

deferred class SUBJECT inherit ANY redefine default_create end feature {NONE} -- Initialization default_create is

  • - Initialize observers.

do create observers.make end feature -- Observer pattern add_observer (an_observer: OBSERVER) is

  • - Add an_observer to the list of observers.

require not_yet_an_observer: not observers.has (an_observer) do

  • bservers.extend (an_observer)

ensure

  • bserver_added: observers.last = an_observer
  • ne_more: observers.count = old observers.count + 1

end

slide-7
SLIDE 7

Trusted Components: Reuse, Contracts and Patterns - Lecture 14

7

Chair of Softw are Engineering

Class SUBJECT (2/2)

remove_observer (an_observer: OBSERVER) is

  • - Remove an_observer from the list of observers.

require is_an_observer: observers.has (an_observer) do

  • bservers.search (an_observer)
  • bservers.remove

ensure

  • bserver_removed: not observers.has (an_observer)
  • ne_less: observers.count = old observers.count – 1

end notify_observers is

  • - Notify all observers. (Call update on each observer.)

do from observers.start until observers.after loop

  • bservers.item.update
  • bservers.forth

end end

  • bservers: LINKED_LIST [OBSERVER]
  • - List of observers

invariant

  • bservers_not_void: observers /= Void

end

slide-8
SLIDE 8

Trusted Components: Reuse, Contracts and Patterns - Lecture 14

8

Chair of Softw are Engineering

Class OBSERVER

deferred class OBSERVER feature -- Observer pattern update is

  • - Update observer according to the state of
  • - the subject it is subscribed to.

deferred end end

slide-9
SLIDE 9

Trusted Components: Reuse, Contracts and Patterns - Lecture 14

9

Chair of Softw are Engineering

Book library example (1/4)

class LIBRARY inherit SUBJECT redefine default_create end feature {NONE} -- Initialization default_create is

  • - Create and initialize the library with an empty
  • - list of books.

do Precursor {SUBJECT} create books.make end

slide-10
SLIDE 10

Trusted Components: Reuse, Contracts and Patterns - Lecture 14

10

Chair of Softw are Engineering

Book library example (2/4)

feature -- Access books: LINKED_LIST [BOOKS]

  • - Books currently in the library

feature -- Element change add_book (a_book: BOOK) is

  • - Add a_book to the list of books and notify all library observers.

require a_book_not_void: a_book /= Void not_yet_in_library: not books.has (a_book) do books.extend (a_book) notify_observers ensure

  • ne_more: books.count = old books.count + 1

book_added: books.last = a_book end ... invariant books_not_void: books /= Void no_void_book: not books.has (Void) end

slide-11
SLIDE 11

Trusted Components: Reuse, Contracts and Patterns - Lecture 14

11

Chair of Softw are Engineering

Book library example (3/4)

class APPLICATION inherit OBSERVER renam e update as display_book redefine default_create end feature {NONE} -- Initialization default_create is

  • - Initialize library and subscribe current application as
  • - library observer.

do create library library.add_observer (Current) end …

slide-12
SLIDE 12

Trusted Components: Reuse, Contracts and Patterns - Lecture 14

12

Chair of Softw are Engineering

Book library example (4/4)

feature -- Observer pattern library: LIBRARY

  • - Subject to observe

display_book is

  • - Display title of last book added to library.

do print (library.books.last.title) end invariant library_not_void: library /= Void consistent: library.observers.has (Current) end

slide-13
SLIDE 13

Trusted Components: Reuse, Contracts and Patterns - Lecture 14

13

Chair of Softw are Engineering

A typical SUBJECT

Redundancy: → Hardly maintainable

→ Not reusable

class MY_DATA inherit SUBJECT feature -- Observer pattern add is

  • - Add Current to data to be observed.

do

  • - Do something.

notify_observers end remove is

  • - Remove Current from data to be observed.

do

  • - Do something.

notify_observers end end

slide-14
SLIDE 14

Trusted Components: Reuse, Contracts and Patterns - Lecture 14

14

Chair of Softw are Engineering

Drawbacks of the Observer

The subject knows its observers No information passing from subject to observer when an event occurs (in the “pull” version) An observer can register to at most one subject (in the “pull” version) Could pass the SUBJECT as argument to update but would yield many assignment attempts to distinguish between the different SUBJECTs.

slide-15
SLIDE 15

Trusted Components: Reuse, Contracts and Patterns - Lecture 14

15

Chair of Softw are Engineering

Observer in Java

In java.util, interface Observer and class Observable →Rarely used for lack of multiple inheritance (subjects must inherit from Observable) Common scheme (e.g. Java Swing, AWT): event-based implementation Subjects define the registration methods: void addXxxListener (XxxListener l) void removeXxxListener (XxxListener l) Whenever a property being observed changes, the subject iterates over its listeners and calls the method defined by the XxxListener interface

slide-16
SLIDE 16

Trusted Components: Reuse, Contracts and Patterns - Lecture 14

16

Chair of Softw are Engineering

Observer in Smalltalk

  • Smalltalk supports the Observer pattern in the kernel library:

class Object, shared by all objects, has messages (features) for both observer and subject objects. update: anAspectSymbol update: anAspectSymbol w ith: aParameter update: anAspectSymbol w ith: aParameter from : aSender // Receive an update message from a Model (Subject). changed changed: anAspectSymbol changed: anAspectSymbol w ith: aParameter // Receiver changed. addDependent: anObject removeDependent: anObject dependents // Return collection of all dependents.

slide-17
SLIDE 17

Trusted Components: Reuse, Contracts and Patterns - Lecture 14

17

Chair of Softw are Engineering

Agenda for today

Observer pattern Event Library Mediator pattern Mediator Library Observer vs. Mediator

slide-18
SLIDE 18

Trusted Components: Reuse, Contracts and Patterns - Lecture 14

18

Chair of Softw are Engineering

Event Library

  • Basically:
  • One generic class: EVENT_TYPE
  • Two features: publish and subscribe
  • For example: A button my_button that reacts in a

way defined in my_procedure when clicked (event mouse_click):

slide-19
SLIDE 19

Trusted Components: Reuse, Contracts and Patterns - Lecture 14

19

Chair of Softw are Engineering

Example using the Event Library

  • The publisher (“subject”) creates an event type object:

mouse_click: EVENT_TYPE [TUPLE [INTEGER, INTEGER]] is

  • - Mouse click event type
  • nce

create Result ensure mouse_click_not_void: Result /= Void end

  • The publisher triggers the event:

mouse_click.publish ([x_positition, y_position])

  • The subscribers (“observers”) subscribe to events:

my_button.mouse_click.subscribe (agent my_procedure)

slide-20
SLIDE 20

Trusted Components: Reuse, Contracts and Patterns - Lecture 14

20

Chair of Softw are Engineering

Subscriber variants

click.subscribe (agent my_procedure) my_button.click.subscribe (agent my_procedure) click.subscribe (agent your_procedure (a, ?, ?, b)) click.subscribe (agent other_object.other_procedure)

slide-21
SLIDE 21

Trusted Components: Reuse, Contracts and Patterns - Lecture 14

21

Chair of Softw are Engineering

Publisher, subscriber, subscribed object (1/2)

Publisher: Responsible for triggering (“publishing”)

  • events. (Corresponds to the subject of the

Observer pattern.) Subscribed object: Notified whenever an event (of the event type they are subscribed to) is

  • published. (Corresponds to the observer of the

Observer pattern.) Subscriber: Registers subscribed objects to a given event type. (Corresponds to the class, which registers the observers to the subjects.)

slide-22
SLIDE 22

Trusted Components: Reuse, Contracts and Patterns - Lecture 14

22

Chair of Softw are Engineering

Publisher, subscriber, subscribed object (2/2)

Subscriber (APPLICATION) Subscribed objects Publishers

Subscribes

  • bjects to

events

slide-23
SLIDE 23

Trusted Components: Reuse, Contracts and Patterns - Lecture 14

23

Chair of Softw are Engineering

Book library example with the Event Library (1/2)

class LIBRARY … feature -- Access books: LINKED_LIST [BOOK]

  • - Books in library

feature -- Event type book_event: EVENT_TYPE [TUPLE [BOOK]]

  • - Event associated with attribute books
slide-24
SLIDE 24

Trusted Components: Reuse, Contracts and Patterns - Lecture 14

24

Chair of Softw are Engineering

Book library example with the Event Library (2/2)

feature -- Element change add_book (a_book: BOOK) is

  • - Add a_book to the list of books and
  • - publish book_event.

require a_book_not_void: a_book /= Void not_yet_in_library: not books.has (a_book) do books.extend (a_book) book_event.publish ([a_book]) ensure

  • ne_more: books.count = old books.count + 1

book_added: books.last = a_book end invariant books_not_void: books /= Void book_event_not_void: book_event /= Void end

slide-25
SLIDE 25

Trusted Components: Reuse, Contracts and Patterns - Lecture 14

25

Chair of Softw are Engineering

Observer pattern vs. Event Library

In case of an existing class MY_CLASS: With the Observer pattern: Need to write a descendant of OBSERVER and MY_CLASS ⇒ Useless multiplication of classes With the Event Library: Can reuse the existing routines directly as agents E.g. EiffelVision vs. EiffelVision2

slide-26
SLIDE 26

Trusted Components: Reuse, Contracts and Patterns - Lecture 14

26

Chair of Softw are Engineering

Observer: Componentization outcome

  • Completeness

All cases of the Observer pattern (and more)

  • Usefulness

Easy-to-use, extendible Event-driven programming Already used in practice (JMLC paper, ESDL)

  • Faithfulness

Agents instead of inheritance

  • Type-safety

Type-safe (constrained genericity, agents)

  • Performance

Same order as the Observer pattern

  • Extended applicability

Event-driven programming in general

slide-27
SLIDE 27

Trusted Components: Reuse, Contracts and Patterns - Lecture 14

27

Chair of Softw are Engineering

Agenda for today

Observer pattern Event Library Mediator pattern Mediator Library Observer vs. Mediator

slide-28
SLIDE 28

Trusted Components: Reuse, Contracts and Patterns - Lecture 14

28

Chair of Softw are Engineering

Componentizability classification

2.1 Skeleton 2.1.2 No method 2.1.1 Method 2.3 Some library support 1. Componentizable 2.2 Possible skeleton 2. Non-componentizable 1.3 Newly componentized 1.1 Built-in 1.2 Library- supported 1.3.2 Componentizable but not comprehensive 1.3.1 Fully componentizable 1.3.3 Componentizable but unfaithful 1.3.4 Componentizable but useless Design pattern 2.4 Design idea 1.4 Possible component Prototype Flyweight Observer Mediator Abstract Factory Factory Method Visitor Command Composite Chain of Responsibility Builder Proxy State Strategy Memento Decorator Adapter Template Method Bridge Singleton Iterator Facade Interpreter

slide-29
SLIDE 29

Trusted Components: Reuse, Contracts and Patterns - Lecture 14

29

Chair of Softw are Engineering

Mediator pattern

“Define[s] an object that encapsulates how a set of objects interact. Mediator promotes loose coupling by keeping objects from referring to each other explicitly, and it lets you vary their interaction independently.” [GoF, p 273]

COLLEAGUE COLLEAGUE COLLEAGUE COLLEAGUE COLLEAGUE COLLEAGUE MEDIATOR COLLEAGUE COLLEAGUE COLLEAGUE COLLEAGUE COLLEAGUE COLLEAGUE

Send and receive requests “Anarchy” style “Monarchy” style

slide-30
SLIDE 30

Trusted Components: Reuse, Contracts and Patterns - Lecture 14

30

Chair of Softw are Engineering

Mediator pattern

* MEDIATOR + MY_MEDIATOR * COLLEAGUE + COLLEAGUE_1 + COLLEAGUE_2

mediator colleague_1 colleague_2 notify_mediator update_colleagues

slide-31
SLIDE 31

Trusted Components: Reuse, Contracts and Patterns - Lecture 14

31

Chair of Softw are Engineering

Class MY_MEDIATOR (1/2)

class MY_MEDIATOR inherit MEDIATOR create make feature {NONE} -- Initialization make is

  • - Create colleague_1 and colleague_2.

do create colleague_1.make (Current) create colleague_2.make (Current) end feature -- Access colleague_1: COLLEAGUE_1

  • - First colleague of mediator

colleague_2: COLLEAGUE_2

  • - Second colleague of mediator
slide-32
SLIDE 32

Trusted Components: Reuse, Contracts and Patterns - Lecture 14

32

Chair of Softw are Engineering

Class MY_MEDIATOR (2/2)

feature -- Basic operations update_colleagues (a_colleague: COLLEAGUE) is

  • - Update colleagues because a_colleague changed.

do if a_colleague = colleague_1 then colleague_2.do_something_2 elseif a_colleague = colleague_2 then colleague_1.do_something_1 else

  • - Colleague not known

end end invariant colleague_1_not_void: colleague_1 /= Void colleague_2_not_void: colleague_2 /= Void end

slide-33
SLIDE 33

Trusted Components: Reuse, Contracts and Patterns - Lecture 14

33

Chair of Softw are Engineering

Class COLLEAGUE (1/2)

deferred class COLLEAGUE feature {NONE} -- Initialization make (a_mediator: like mediator) is

  • - Set mediator to a_mediator.

require a_mediator_not_void: a_mediator /= Void do mediator := a_mediator ensure mediator_set: mediator = a_mediator end feature -- Access mediator: MEDIATOR

  • - Mediator
slide-34
SLIDE 34

Trusted Components: Reuse, Contracts and Patterns - Lecture 14

34

Chair of Softw are Engineering

Class COLLEAGUE (2/2)

feature -- Mediator pattern notify_mediator is

  • - Notify mediator that Current has changed.

do mediator.update_colleagues (Current) end invariant mediator_not_void: mediator /= Void end

slide-35
SLIDE 35

Trusted Components: Reuse, Contracts and Patterns - Lecture 14

35

Chair of Softw are Engineering

Class COLLEAGUE_1

class COLLEAGUE_1 inherit COLLEAGUE create make feature -- Basic operations change_1 is

  • - Change something on Current.

do

  • - Do something that changes Current's state.

notify_mediator end do_something_1 is

  • - Do something.

do … end end Event Library Similar to the Observer pattern

slide-36
SLIDE 36

Trusted Components: Reuse, Contracts and Patterns - Lecture 14

36

Chair of Softw are Engineering

Original Mediator pattern

* MEDIATOR + MY_MEDIATOR * COLLEAGUE + COLLEAGUE_1 + COLLEAGUE_2

mediator colleague_1 colleague_2 notify_mediator update_colleagues

slide-37
SLIDE 37

Trusted Components: Reuse, Contracts and Patterns - Lecture 14

37

Chair of Softw are Engineering

Mediator pattern with the Event Library

+ MEDIATOR MY_MEDIATOR * COLLEAGUE + COLLEAGUE_1 + COLLEAGUE_2

mediator colleague_1 colleague_2

EVENT_TYPE [EVENT_DATA -> TUPLE]

event_1 event_2 mediator event_library

slide-38
SLIDE 38

Trusted Components: Reuse, Contracts and Patterns - Lecture 14

38

Chair of Softw are Engineering

Class COLLEAGUE_1

class COLLEAGUE_1 inherit COLLEAGUE … feature -- Basic operations change_1 is

  • - Change something on Current.

do

  • - Do something that changes Current's state.

event_1.publish ([]) end … end

slide-39
SLIDE 39

Trusted Components: Reuse, Contracts and Patterns - Lecture 14

39

Chair of Softw are Engineering

Class MEDIATOR

class MEDIATOR create make feature {NONE} -- Initialization make is

  • - Create colleague_1 and colleague_2.

do create colleague_1.make (Current) create colleague_2.make (Current) colleague_1.event_1.subscribe ( agent colleague_2.do_something_2) colleague_2.event_2.subscribe ( agent colleague_1.do_something_1) end … end

slide-40
SLIDE 40

Trusted Components: Reuse, Contracts and Patterns - Lecture 14

40

Chair of Softw are Engineering

Agenda for today

Observer pattern Event Library Mediator pattern Mediator Library Observer vs. Mediator

slide-41
SLIDE 41

Trusted Components: Reuse, Contracts and Patterns - Lecture 14

41

Chair of Softw are Engineering

Mediator Library (1/4)

class interface MEDIATOR [G −> COLLEAGUE] create make

  • - Initialize colleagues.

feature -- Access colleagues: LINKED_LIST [G]

  • - Colleagues of mediator

feature -- Element change extend (a_colleague: G)

  • - Extend colleagues with a_colleague.
  • - Update event subscription of colleagues.

require a_colleague_not_void: a_colleague /= Void not_a_colleague: not colleagues.has (a_colleague) ensure

  • ne_more: colleagues.count = old colleagues.count + 1

is_last: colleagues.last = a_colleague subscribed: colleagues.for_all (agent is_colleague_subscribed)

slide-42
SLIDE 42

Trusted Components: Reuse, Contracts and Patterns - Lecture 14

42

Chair of Softw are Engineering

Mediator Library (2/4)

remove (a_colleague: G) is

  • - Remove a_colleague from colleagues.
  • - Update event subscription of remaining colleagues.

require a_colleague_not_void: a_colleague /= Void has_colleague: colleagues.has (a_colleague) ensure

  • ne_less: colleagues.count = old colleagues.count − 1

not_has_colleague: not colleagues.has (a_colleague) unsubscribed: a_colleague.unsubscribed invariant colleagues_not_void: colleagues /= Void no_void_colleague: not colleagues.has (Void) end

slide-43
SLIDE 43

Trusted Components: Reuse, Contracts and Patterns - Lecture 14

43

Chair of Softw are Engineering

Mediator Library (3/4)

deferred class interface COLLEAGUE feature {NONE} -- Initialization make (a_mediator: like mediator) is

  • - Set mediator to a_mediator.

require a_mediator_not_void: a_mediator /= Void ensure mediator_set: mediator = a_mediator feature -- Access mediator: MEDIATOR [COLLEAGUE]

  • - Mediator

event: EVENT_TYPE [TUPLE]

  • - Event
slide-44
SLIDE 44

Trusted Components: Reuse, Contracts and Patterns - Lecture 14

44

Chair of Softw are Engineering

Mediator Library (4/4)

feature -- Basic operations change is

  • - Do something that changes current colleague's
  • - state.

do do_change event.publish ([]) end … invariant mediator_not_void: mediator /= Void event_not_void: event /= Void end

slide-45
SLIDE 45

Trusted Components: Reuse, Contracts and Patterns - Lecture 14

45

Chair of Softw are Engineering

Book library example with the Mediator Library (1/2)

class USER inherit COLLEAGUE create make feature -- Status report may_borrow: BOOLEAN

  • - May user borrow books from the library?

feature -- Element change do_something is

  • - Set may_borrow to False.

do may_borrow := False ensure then may_not_borrow: not may_borrow end

slide-46
SLIDE 46

Trusted Components: Reuse, Contracts and Patterns - Lecture 14

46

Chair of Softw are Engineering

Book library example with the Mediator Library (2/2)

feature {NONE} -- Implementation do_change is

  • - Borrow a book from the library.

do if may_borrow then

  • - Borrow a book from the library.

end end end

slide-47
SLIDE 47

Trusted Components: Reuse, Contracts and Patterns - Lecture 14

47

Chair of Softw are Engineering

Mediator: Componentization outcome

  • Completeness

All cases of the Mediator pattern

  • Usefulness

Reusable Easy-to-use (Event Library)

  • Faithfulness

Different from a traditional implementation of Mediator Similar to an implementation of Mediator using the Event Library (with genericity)

  • Type-safety

Type-safe (constrained genericity, agents)

  • Performance

Same order as the Mediator pattern

  • Extended applicability

No more cases

slide-48
SLIDE 48

Trusted Components: Reuse, Contracts and Patterns - Lecture 14

48

Chair of Softw are Engineering

Agenda for today

Observer pattern Event Library Mediator pattern Mediator Library Observer vs. Mediator

slide-49
SLIDE 49

Trusted Components: Reuse, Contracts and Patterns - Lecture 14

49

Chair of Softw are Engineering

Mediator Library vs. Event Library (1/3)

Mediator pattern: Every colleague “observes” all

  • ther colleagues

→ A particular use of the Event Library Mediator Library: Removes from clients the burden

  • f (un)registering colleagues when a new colleague

is added (removed) → Moved to the MEDIATOR Mediator Library encapsulates a common use of the Event Library to facilitate the programmers’

  • job. It relies on the Event Library.
slide-50
SLIDE 50

Trusted Components: Reuse, Contracts and Patterns - Lecture 14

50

Chair of Softw are Engineering

Mediator Library vs. Event Library (2/3)

With the Event Library:

CLIENT COLLEAGUE COLLEAGUE COLLEAGUE COLLEAGUE COLLEAGUE COLLEAGUE

slide-51
SLIDE 51

Trusted Components: Reuse, Contracts and Patterns - Lecture 14

51

Chair of Softw are Engineering

Mediator Library vs. Event Library (3/3)

With the Mediator Library:

COLLEAGUE COLLEAGUE COLLEAGUE COLLEAGUE COLLEAGUE COLLEAGUE MEDIATOR CLIENT

slide-52
SLIDE 52

Trusted Components: Reuse, Contracts and Patterns - Lecture 14

52

Chair of Softw are Engineering

Complementary material

  • From Patterns to Components:

Chapter 7: Observer and Mediator

  • About the Event Library and Event-Driven programming:

http://se.inf.ethz.ch/people/arnout/publications/arslan_ni enaltowski_arnout_jmlc_2003_event_library.pdf http://www.inf.ethz.ch/~meyer/ongoing/events.pdf

  • Further reading:

Erich Gamma: Design Patterns, Addison-Wesley, 1995. (Observer, p 293-304; Mediator, p 283-292) David Geary. “An inside view of Observer”, JavaWorld,

  • 2003. http://www.javaworld.com/javaworld/jw-03-

2003/jw-0328-designpatterns.html

slide-53
SLIDE 53

Trusted Components: Reuse, Contracts and Patterns - Lecture 14

53

Chair of Softw are Engineering

End of lecture 14