TDDB84: Lecture 5. Singleton, Builder, Proxy, Mediator. fredag 27 september 13
|
|
- Neal Fisher
- 5 years ago
- Views:
Transcription
1 TDDB84: Lecture 5 Singleton, Builder, Proxy, Mediator
2 Creational Abstract Factory Singleton Builder Structural Composite Proxy Bridge Adapter Template method Behavioral Iterator Mediator Chain of responsibility Observer Observer LE3 LE4 LE5 LE6 Creational patterns Structural patterns LA1 LA2 LA3
3 Creational Abstract Factory Singleton Builder Structural Composite Proxy Bridge Adapter Behavioral Template method Iterator Dynamic proxies in C# & Java Mediator Classes ARE objects, and each object can have a class (in Ruby) Chain of responsibility Observer Observer LE3 LE4 LE5 LE6 Creational patterns Structural patterns LA1 LA2 LA3
4 Muddy Cards Compare patterns Fewer examples Present more patterns More UML Lab session staffing/time sharing
5 The assistant role Let me go!
6 The assistant role Let me go!
7 On UML
8 What is this? y.g() y f() X g() Y X1 Y1 Y2
9 Bridge?
10 Builder?
11 Strategy? strategy.g() Context strategy f() Strategy g() Context1 ConcreteStrategy1 ConcreteStrategy2
12 What UML? Arrays.sort(ducks, (arg0, arg1) -> new Integer(arg1.weight).compareTo(arg0.weight))
13 1. What are the relationships between the Strategy and Flyweight patterns? a) They both concern decoupling objects from their dependencies b) Using a Flyweight pattern may also require the Strategy pattern c) Using the Strategy pattern may also result in using the Flyweight pattern d) The Strategy pattern, if implemented with the use of type template parameters, does not necessitate the Flyweight pattern e) You often implement the Flyweight pattern by using the Strategy pattern for object creation f) The Flyweight pattern is a simplified form of the Strategy pattern
14 1. What are the relationships between the Strategy and Flyweight patterns? a) They both concern decoupling objects from their dependencies True. As in the strategy pattern behavior or independent and in the flyweight pattern we implement a kind of factory which decouple object from their dependencies. b) Using a Flyweight pattern may also require the Strategy pattern False. c) Using the Strategy pattern may also result in using the Flyweight pattern True. As behavior (strategy objects) can be implemented as flyweight to enable to share behavior objects, and avoid creating several time the same behavior object. d) The Strategy pattern, if implemented with the use of type template parameters, does not necessitate the Flyweight pattern False. I think that using template parameters doesn't prevent from creating unnecessary new objects. e) You often implement the Flyweight pattern by using the Strategy pattern for object creation False. As strategy pattern is not a creational pattern and enable to use different algorithm and not to create different objects. f) The Flyweight pattern is a simplified form of the Strategy pattern False. UML seems similar (GoF p198, 316) but they don't do the same thing at all, strategy enable to use different algorithm and change them runtime whereas the goal of flyweight pattern is to create new object, if they weren't created before,or to share object if the same object was created before. Correct answers marked
15 1. What are the relationships between the Strategy and Flyweight patterns? a) They both concern decoupling objects from their dependencies True. As in the strategy pattern behavior or independent and in the flyweight pattern we implement a kind of factory which decouple object from their dependencies. b) Using a Flyweight pattern may also require the Strategy pattern False. c) Using the Strategy pattern may also result in using the Flyweight pattern True. As behavior (strategy objects) can be implemented as flyweight to enable to share behavior objects, and avoid creating several time the same behavior object. d) The Strategy pattern, if implemented with the use of type template parameters, does not necessitate the Flyweight pattern False. I think that using template parameters doesn't prevent from creating unnecessary new objects. e) You often implement the Flyweight pattern by using the Strategy pattern for object creation False. As strategy pattern is not a creational pattern and enable to use different algorithm and not to create different objects. f) The Flyweight pattern is a simplified form of the Strategy pattern False. UML seems similar (GoF p198, 316) but they don't do the same thing at all, strategy enable to use different algorithm and change them runtime whereas the goal of flyweight pattern is to create new object, if they weren't created before,or to share object if the same object was created before. Correct answers marked
16 c) Using the Strategy pattern may also result in using the Flyweight pattern Flyweights are light-weight objects with externalized state, useful if supplying multiple strategies to a problem-solving context d) The Strategy pattern, if implemented with the use of type template parameters, does not necessitate the Flyweight pattern Using a template parameter, See C# demo public class TaxCalculation<T>!! where T: TaxStrategy, new()! {!! private static T taxstrategy = Activator.CreateInstance<T>();!! public TaxCalculation ()!! {!!!! public double GetTax(Person p) {!!! return taxstrategy.calculatetax(p.salary);!!!
17 c) Using the Strategy pattern may also result in using the Flyweight pattern Flyweights are light-weight objects with externalized state, useful if supplying multiple strategies to a problem-solving context d) The Strategy pattern, if implemented with the use of type template parameters, does not necessitate the Flyweight pattern Using a template parameter, See C# demo public class TaxCalculation<T>!! where T: TaxStrategy, new()! {!! private static T taxstrategy = Activator.CreateInstance<T>();!! public TaxCalculation ()!! {!!!! public double GetTax(Person p) {!!! return taxstrategy.calculatetax(p.salary);!!!
18 Singleton
19 public class Singleton { private static Singleton instance = new Singleton(); private String name; public String getname() { return name; private Singleton() { [... ]
20 public class Singleton { private static Singleton instance = new Singleton(); private String name; public String getname() { return name; private Singleton() { [... ] private Singleton() { try { // Very expensive job indeed Thread.sleep(100); catch (InterruptedException e) { e.printstacktrace(); name = Math.random() > 0.5? "Jonas" : "Anders";
21 public class Singleton { private static Singleton instance = new Singleton(); private String name; public String getname() { return name; private Singleton() { [... ] private Singleton() { try { // Very expensive job indeed Thread.sleep(100); catch (InterruptedException e) { e.printstacktrace(); name = Math.random() > 0.5? "Jonas" : "Anders"; Our app takes forever to load
22 public class Singleton { private static Singleton instance = new Singleton(); private String name; public String getname() { return name; public static void someothermethod(){ System.out.println("Hi there!"); What about static methods? private Singleton() { [... ] private Singleton() { try { // Very expensive job indeed Thread.sleep(100); catch (InterruptedException e) { e.printstacktrace(); name = Math.random() > 0.5? "Jonas" : "Anders"; Our app takes forever to load
23 Thread t1 = new Thread(new StaticMethodInvocation()); Thread t2 = new Thread(new SingletonLookup()); t0 = System.nanoTime(); t1.start(); t2.start(); try { t1.join(); t2.join(); catch (InterruptedException e) { // TODO Auto-generated catch block e.printstacktrace(); someothermethod invoked Singleton name: Anders Singleton lookup took ns Static method invocation took ns
24 How about now? private static Singleton instance; public static Singleton getinstance() { if (instance == null) { instance = new Singleton(); return instance; someothermethod invoked Static method invocation took ns Singleton name: Anders Singleton lookup took ns
25 What about threads?
26 private Singleton() { try { // Very expensive job indeed Thread.sleep(100); catch (InterruptedException e) { e.printstacktrace(); name = Math.random() > 0.5? "Jonas" : "Anders";
27 private Singleton() { try { // Very expensive job indeed Thread.sleep(100); catch (InterruptedException e) { e.printstacktrace(); name = Math.random() > 0.5? "Jonas" : "Anders"; private static final class SingletonLookup implements Runnable public void run() { System.out.println(MessageFormat.format("Singleton name: {0", Singleton.getInstance().getName())); public static void main(string[] args) { Thread t1 = new Thread(new SingletonLookup()); Thread t2 = new Thread(new SingletonLookup()); t0 = System.nanoTime(); t1.start(); t2.start(); try { t1.join(); t2.join(); catch (InterruptedException e) { // TODO Auto-generated catch block e.printstacktrace(); System.out.println("Singleton name after our threads have run: "+Singleton.getInstance().getName());
28 private Singleton() { try { // Very expensive job indeed Thread.sleep(100); catch (InterruptedException e) { e.printstacktrace(); name = Math.random() > 0.5? "Jonas" : "Anders"; private static final class SingletonLookup implements Runnable public void run() { System.out.println(MessageFormat.format("Singleton name: {0", Singleton.getInstance().getName())); public static void main(string[] args) { Thread t1 = new Thread(new SingletonLookup()); Thread t2 = new Thread(new SingletonLookup()); t0 = System.nanoTime(); t1.start(); t2.start(); try { t1.join(); t2.join(); catch (InterruptedException e) { // TODO Auto-generated catch block e.printstacktrace(); System.out.println("Singleton name after our threads have run: "+Singleton.getInstance().getName());
29 private Singleton() { try { // Very expensive job indeed Thread.sleep(100); catch (InterruptedException e) { e.printstacktrace(); name = Math.random() > 0.5? "Jonas" : "Anders"; private static final class SingletonLookup implements Runnable public void run() { System.out.println(MessageFormat.format("Singleton name: {0", Singleton.getInstance().getName())); public static void main(string[] args) { Thread t1 = new Thread(new SingletonLookup()); Thread t2 = new Thread(new SingletonLookup()); t0 = System.nanoTime(); t1.start(); t2.start(); try { t1.join(); t2.join(); catch (InterruptedException e) { // TODO Auto-generated catch block e.printstacktrace(); System.out.println("Singleton name after our threads have run: "+Singleton.getInstance().getName());
30 private Singleton() { try { // Very expensive job indeed Thread.sleep(100); catch (InterruptedException e) { e.printstacktrace(); name = Math.random() > 0.5? "Jonas" : "Anders"; private static final class SingletonLookup implements Runnable public void run() { System.out.println(MessageFormat.format("Singleton name: {0", Singleton.getInstance().getName())); public static void main(string[] args) { Thread t1 = new Thread(new SingletonLookup()); Thread t2 = new Thread(new SingletonLookup()); t0 = System.nanoTime(); t1.start(); t2.start(); try { t1.join(); t2.join(); catch (InterruptedException e) { // TODO Auto-generated catch block e.printstacktrace(); System.out.println("Singleton name after our threads have run: "+Singleton.getInstance().getName());
31 private Singleton() { try { // Very expensive job indeed Thread.sleep(100); catch (InterruptedException e) { e.printstacktrace(); name = Math.random() > 0.5? "Jonas" : "Anders"; private static final class SingletonLookup implements Runnable public void run() { System.out.println(MessageFormat.format("Singleton name: {0", Singleton.getInstance().getName())); public static void main(string[] args) { Thread t1 = new Thread(new SingletonLookup()); Oops! Thread t2 = new Thread(new SingletonLookup()); t0 = System.nanoTime(); t1.start(); t2.start(); try { t1.join(); Singleton name: Anders t2.join(); Singleton name: Jonas catch (InterruptedException e) { Singleton name after our threads have run: Anders // TODO Auto-generated catch block e.printstacktrace(); System.out.println("Singleton name after our threads have run: "+Singleton.getInstance().getName());
32 public static synchronized Singleton getinstance() { if (instance == null) { instance = new Singleton(); return instance; Singleton name: Anders Singleton name: Anders Singleton lookup took ns Singleton lookup took ns Singleton name after our threads have run: Anders Woohoo!
33 public static synchronized Singleton getinstance() { if (instance == null) { instance = new Singleton(); return instance; Singleton name: Anders Singleton name: Anders Singleton lookup took ns Singleton lookup took ns Singleton name after our threads have run: Anders Woohoo!
34 Singleton as Enum public enum EnumSingleton { INSTANCE; private String name; private int age; public String getname() { return name; public void setname(string name) { this.name = name; public int getage() { return age; public void setage(int age) { this.age = age;
35 Singletons in Ruby Object MetaClass A class A; end Class foo foo = A.new A class A; end
36 Singletons in Ruby Object MetaClass A class A; end Class Singleton Class for foo class << foo; end foo foo = A.new A class A; end
37 Singletons in Ruby Object MetaClass A class A; end Class Singleton Class for foo class << foo; end Singleton Class for A class << A; end foo foo = A.new A class A; end
38 class A end a = A.new class << A def new raise "Illegal!" end end irb(main):014:0> a #<A:0x007f8d6b92bcb0> irb(main):016:0> A.new RuntimeError: Illegal! from (irb):10:in `new' from (irb):16 from /Users/olale/.rvm/rubies/ruby p247/bin/irb:13:in `<main>' Now we have one object, but we cannot produce another of the same class
39 Singleton: consequences
40 Singleton: consequences + Ensures single objects per class
41 Singleton: consequences - + Ensures single objects per class Violates several design principles!
42 Singleton considered dangerous Encapsulate what varies Program to an interface, not to an implementation Favor composition over inheritance Classes should be open for extension but closed for modification Don t call us, we ll call you Depend on abstractions, do not depend on concrete classes Classes should only have one reason to change Strive for loosely-coupled design
43 Singleton considered dangerous Encapsulate what varies Program to an interface, not to an implementation Favor composition over inheritance Classes should be open for extension but closed for modification Don t call us, we ll call you Depend on abstractions, do not depend on concrete classes Classes should only have one reason to change Strive for loosely-coupled design
44 Singleton considered dangerous Encapsulate what varies Program to an interface, not to an implementation Favor composition over inheritance Classes should be open for extension but closed for modification Don t call us, we ll call you Depend on abstractions, do not depend on concrete classes Classes should only have one reason to change Strive for loosely-coupled design
45 Singleton considered dangerous Encapsulate what varies Program to an interface, not to an implementation Favor composition over inheritance Classes should be open for extension but closed for modification Don t call us, we ll call you Depend on abstractions, do not depend on concrete classes Classes should only have one reason to change Strive for loosely-coupled design
46 Builder
47
48 Client Director Builder build() builda() buildb() buildc() getproduct()
49
50
51 Director
52 Client Director
53 Client Director Builder
54 Demo
55 Abstract Factory Client receives a Factory Client requests a product from Factory Client receives an abstract product
56 Abstract Factory Client receives a Factory Client requests a product from Factory Client receives an abstract product Builder Client initializes Director with Builder Client asks Director to build Client requests product from Builder Client receives a builder-specific product
57 Abstract Factory Client receives a Factory Client requests a product from Factory Client receives an abstract product Builder Client initializes Director with Builder Client asks Director to build Client requests product from Builder Client receives a builder-specific product
58 Abstract Factory Client receives a Factory Client requests a product from Factory Client receives an abstract product Builder Client initializes Director with Builder Client asks Director to build Client requests product from Builder Client receives a builder-specific product
59 Abstract Factory Client receives a Factory Client requests a product from Factory Client receives an abstract product Builder Client initializes Director with Builder Client asks Director to build Client requests product from Builder Client receives a builder-specific product
60 Abstract Factory Client receives a Factory Client requests a product from Factory Client receives an abstract product Builder Client initializes Director with Builder Client asks Director to build Client requests product from Builder Client receives a builder-specific product
61 Builder: consequences
62 Builder: consequences + Can control the way objects are created
63 Builder: consequences + Can control the way objects are created + Can produce different products using the same Director
64 Builder: consequences + Can control the way objects are created + Can produce different products using the same Director - Not necessarily a common interface for products
65 Builder: consequences + Can control the way objects are created + Can produce different products using the same Director - - Not necessarily a common interface for products Clients must know how to initialize builders and retrieve products
66 Design principles Encapsulate what varies Program to an interface, not to an implementation Favor composition over inheritance Classes should be open for extension but closed for modification Don t call us, we ll call you Depend on abstractions, do not depend on concrete classes Classes should only have one reason to change Strive for loosely-coupled design
67 Mediator
68 onevent(){ checkcalendar(); checksprinkler(); startcoffee(); //do more stuff onevent(){ checkcalendar(); checkalarm(); //do more stuff onevent(){ checkdayoftheweek(); doshower(); docoffee(); doalarm(); //do more stuff onevent(){ checkcalendar(); checkshower(); checktemperature //do more stuff
69 if(alarmevent)(){ checkcalendar(); checkshower(); checktemp(); //do more stuff if(weekend){ checkweather(); if(trashday){ resetalarm();
70 Demo
71 Mediator vs Observer
72 Mediator: consequences
73 Mediator: consequences - Creates a complex single point of failure
74 Mediator: consequences - + The Mediator and its colleagues can be varied independently Creates a complex single point of failure
75 Mediator: consequences - + The Mediator and its colleagues can be varied independently + Replaces N-M relationships with 1-M relationships with the Mediator in the middle Creates a complex single point of failure
76 Mediator: consequences - + The Mediator and its colleagues can be varied independently + Replaces N-M relationships with 1-M relationships with the Mediator in the middle + Centralizes interaction management Creates a complex single point of failure
77 Proxy
78
79 ! public class Person: DomainObject! {!! public String Name { get; set;!! public String Age { get; set;!! public virtual ICollection<Employment> Employments { get; set;!!! Person! public class Employment: DomainObject! {!! public virtual Person Person { get; set;!! public DateTime StartDate { get; set;!! public DateTime EndDate { get; set;! Id Name Age 1 Ola 34 2 Lisa 31 Employment Id StartDate EndDate PersonId
80 1!!! var people = GenericDAO<Person>.Get();!!! people.should ().NotBeEmpty ();!!! Data Access Layer Retrieve records from the table Person and map them to objects 2 people.first ().Employments.Should ().NotBeNull (); Intercept method calls to access the property Employments (get_employments) and fetch the related Employments records for the current Person object All ORM layers support this
81 public class LazyLoadingInterceptor<T>:BaseInterceptor,IInterceptor where T:class, new() { private static string GetPropertyName(string gettername) { return gettername.remove(0,4); public void Intercept(IInvocation invocation) { object proxy=invocation.proxy; // Get the target property access method var target=invocation.methodinvocationtarget; string propertyname=getpropertyname(target.name); if(target.name.startswith("get_")) { Prefetcher<T>.FetchRelatedProperty(new List<T>() { proxy as T,typeof(T).GetProperty(propertyName)); invocation.proceed(); Castle DynamicProxy
82 Demo
83 Java: InvocationHandler package headfirst.proxy.javaproxy; return (PersonBean) Proxy.newProxyInstance( person.getclass().getclassloader(), person.getclass().getinterfaces(), new NonOwnerInvocationHandler(person));
84 Ruby: method_missing class A end def initialize end def foo "foo" end def bar "bar" end def end class AProxy end def = a end def method_missing(m,*args) p "calling #{m on end
85 Ruby: method_missing class A def initialize end def foo "foo" end end def bar "bar" end def end irb(main):067:0> irb(main):068:0> proxy.foo "calling foo on original_object" "foo" class AProxy end def = a end def method_missing(m,*args) p "calling #{m on end
86 Proxy: consequences
87 Proxy: consequences - Depending on the implementation, proxies may incur an overhead cost for method calls
88 Proxy: consequences - - Depending on the implementation, proxies may incur an overhead cost for method calls Depending on the implementation, proxies may require that all proxied objects implement interfaces (in Java)
89 Proxy: consequences + Allows expensive objects to be referenced before they are fully initialized - - Depending on the implementation, proxies may incur an overhead cost for method calls Depending on the implementation, proxies may require that all proxied objects implement interfaces (in Java)
90 Proxy: consequences + Allows expensive objects to be referenced before they are fully initialized + Can transparently extend objects with new aspects such as access control, logging, method call forwarding, lazy loading - - Depending on the implementation, proxies may incur an overhead cost for method calls Depending on the implementation, proxies may require that all proxied objects implement interfaces (in Java)
91 Singleton, Builder, Proxy, Mediator Summary
92 Next seminar
TDDB84. Summary & wrap-up & some tips & some design patterns & some other stuff. tisdag 20 oktober 15
TDDB84 Summary & wrap-up & some tips & some design patterns & some other stuff Agenda Course goals, expectations Writing papers: FAQ Design Patterns revisited Course summary Life after the course Course
More informationTDDB84: Lecture 09. SOLID, Language design, Summary. fredag 11 oktober 13
TDDB84: Lecture 09 SOLID, Language design, Summary SOLID Single responsibility principle Open/closed principle Liskov substitution principle Interface segregation principle Depency inversion principle
More informationTDDB84: Lecture 6. Adapter, Bridge, Observer, Chain of Responsibility, Memento, Command. fredag 4 oktober 13
TDDB84: Lecture 6 Adapter, Bridge, Observer, Chain of Responsibility, Memento, Command Creational Abstract Factory Singleton Builder Structural Composite Proxy Bridge Adapter Template method Behavioral
More informationThe Strategy Pattern Design Principle: Design Principle: Design Principle:
Strategy Pattern The Strategy Pattern defines a family of algorithms, encapsulates each one, and makes them interchangeable. Strategy lets the algorithm vary independently from clients that use it. Design
More informationTDDB84. Lecture 2. fredag 6 september 13
TDDB84 Lecture 2 Yes, you can bring the books to the exam Creational Factory method Structural Decorator Behavioral LE2 Creational Abstract Factory Singleton Builder Structural Composite Proxy Bridge Adapter
More informationTDDB84 Design Patterns Lecture 06
Lecture 06 Mediator, Adapter, Bridge Peter Bunus Dept of Computer and Information Science Linköping University, Sweden petbu@ida.liu.se The Mediator Peter Bunus 2 1 Peter Bunus 3 The Mediator Non Software
More informationObject Oriented Methods with UML. Introduction to Design Patterns- Lecture 8
Object Oriented Methods with UML Introduction to Design Patterns- Lecture 8 Topics(03/05/16) Design Patterns Design Pattern In software engineering, a design pattern is a general repeatable solution to
More informationTDDB84: Lecture 7. State, Visitor, Interpreter, DSL. fredag 4 oktober 13
TDDB84: Lecture 7 State, Visitor, Interpreter, DSL Creational Prototype SOLID Structural Facade Flyweight Behavioral State Visitor Interpreter Summary The exam LE7 LE8 LE9 Several different patterns GUI
More informationDESIGN PATTERN - INTERVIEW QUESTIONS
DESIGN PATTERN - INTERVIEW QUESTIONS http://www.tutorialspoint.com/design_pattern/design_pattern_interview_questions.htm Copyright tutorialspoint.com Dear readers, these Design Pattern Interview Questions
More informationAn Introduction to Patterns
An Introduction to Patterns Robert B. France Colorado State University Robert B. France 1 What is a Pattern? - 1 Work on software development patterns stemmed from work on patterns from building architecture
More informationCS 556 Distributed Systems
CS 556 Distributed Systems Tutorial on 4 Oct 2002 Threads A thread is a lightweight process a single sequential flow of execution within a program Threads make possible the implementation of programs that
More informationDesign Patterns. Dr. Rania Khairy. Software Engineering and Development Tool
Design Patterns What are Design Patterns? What are Design Patterns? Why Patterns? Canonical Cataloging Other Design Patterns Books: Freeman, Eric and Elisabeth Freeman with Kathy Sierra and Bert Bates.
More information7. MULTITHREDED PROGRAMMING
7. MULTITHREDED PROGRAMMING What is thread? A thread is a single sequential flow of control within a program. Thread is a path of the execution in a program. Muti-Threading: Executing more than one thread
More informationGOF Patterns Applied
www.teamsoftinc.com GOF Patterns Applied Kirk Knoernschild TeamSoft, Inc. www.teamsoftinc.com http://techdistrict.kirkk.com http://www.kirkk.com pragkirk@kirkk.com GOF Patterns in Java Pattern Review The
More informationExam in TDDB84: Design Patterns,
Exam in TDDB84: Design Patterns, 2014-10-24 14-18 Information Observe the following, or risk subtraction of points: 1) Write only the answer to one task on one sheet. Use only the front side of the sheets
More informationThe GoF Design Patterns Reference
The GoF Design Patterns Reference Version.0 / 0.0.07 / Printed.0.07 Copyright 0-07 wsdesign. All rights reserved. The GoF Design Patterns Reference ii Table of Contents Preface... viii I. Introduction....
More informationDesign Patterns. Manuel Mastrofini. Systems Engineering and Web Services. University of Rome Tor Vergata June 2011
Design Patterns Lecture 1 Manuel Mastrofini Systems Engineering and Web Services University of Rome Tor Vergata June 2011 Definition A pattern is a reusable solution to a commonly occurring problem within
More informationTDDB84 Design Patterns Lecture 05. Builder, Singleton, Proxy. pelab
Lecture 05 Builder, Singleton, Proxy Peter Bunus Dept of Computer and Information Science Linköping University, Sweden petbu@ida.liu.se The Constitution of Software Architects Encapsulate what varies.
More informationCSE 70 Final Exam Fall 2009
Signature cs70f Name Student ID CSE 70 Final Exam Fall 2009 Page 1 (10 points) Page 2 (16 points) Page 3 (22 points) Page 4 (13 points) Page 5 (15 points) Page 6 (20 points) Page 7 (9 points) Page 8 (15
More informationObject Oriented Paradigm
Object Oriented Paradigm Ming-Hwa Wang, Ph.D. Department of Computer Engineering Santa Clara University Object Oriented Paradigm/Programming (OOP) similar to Lego, which kids build new toys from assembling
More informationTrusted Components. Reuse, Contracts and Patterns. Prof. Dr. Bertrand Meyer Dr. Karine Arnout
1 Last update: 2 November 2004 Trusted Components Reuse, Contracts and Patterns Prof. Dr. Bertrand Meyer Dr. Karine Arnout 2 Lecture 5: Design patterns Agenda for today 3 Overview Benefits of patterns
More informationEPL 603 TOPICS IN SOFTWARE ENGINEERING. Lab 6: Design Patterns
EPL 603 TOPICS IN SOFTWARE ENGINEERING Lab 6: Design Patterns Links to Design Pattern Material 1 http://www.oodesign.com/ http://www.vincehuston.org/dp/patterns_quiz.html Types of Design Patterns 2 Creational
More informationDesign Patterns. SE3A04 Tutorial. Jason Jaskolka
SE3A04 Tutorial Jason Jaskolka Department of Computing and Software Faculty of Engineering McMaster University Hamilton, Ontario, Canada jaskolj@mcmaster.ca November 18/19, 2014 Jason Jaskolka 1 / 35 1
More informationThreads Chate Patanothai
Threads Chate Patanothai Objectives Knowing thread: 3W1H Create separate threads Control the execution of a thread Communicate between threads Protect shared data C. Patanothai Threads 2 What are threads?
More informationDesign Pattern. CMPSC 487 Lecture 10 Topics: Design Patterns: Elements of Reusable Object-Oriented Software (Gamma, et al.)
Design Pattern CMPSC 487 Lecture 10 Topics: Design Patterns: Elements of Reusable Object-Oriented Software (Gamma, et al.) A. Design Pattern Design patterns represent the best practices used by experienced
More informationCHAPTER 6: CREATIONAL DESIGN PATTERNS
CHAPTER 6: CREATIONAL DESIGN PATTERNS SESSION III: BUILDER, PROTOTYPE, SINGLETON Software Engineering Design: Theory and Practice by Carlos E. Otero Slides copyright 2012 by Carlos E. Otero For non-profit
More informationCS 349 / SE 382 Design Patterns. Professor Michael Terry January 21, 2009
CS 349 / SE 382 Design Patterns Professor Michael Terry January 21, 2009 Today s Agenda More demos! Design patterns CS 349 / SE 382 / 2 Announcements Assignment 1 due Monday at 5PM! CS 349 / SE 382 / 3
More informationUsing Design Patterns in Java Application Development
Using Design Patterns in Java Application Development ExxonMobil Research & Engineering Co. Clinton, New Jersey Michael P. Redlich (908) 730-3416 michael.p.redlich@exxonmobil.com About Myself Degree B.S.
More informationDesign Patterns. (and anti-patterns)
Design Patterns (and anti-patterns) Design Patterns The Gang of Four defined the most common object-oriented patterns used in software. These are only the named ones Lots more variations exist Design Patterns
More informationThe Singleton Pattern. Design Patterns In Java Bob Tarr
The Singleton Pattern Intent Ensure a class only has one instance, and provide a global point of access to it Motivation Sometimes we want just a single instance of a class to exist in the system For example,
More informationA few important patterns and their connections
A few important patterns and their connections Perdita Stevens School of Informatics University of Edinburgh Plan Singleton Factory method Facade and how they are connected. You should understand how to
More informationPlan. A few important patterns and their connections. Singleton. Singleton: class diagram. Singleton Factory method Facade
Plan A few important patterns and their connections Perdita Stevens School of Informatics University of Edinburgh Singleton Factory method Facade and how they are connected. You should understand how to
More informationSDC Design patterns GoF
SDC Design patterns GoF Design Patterns The design pattern concept can be viewed as an abstraction of imitating useful parts of other software products. The design pattern is a description of communicating
More informationTuesday, October 4. Announcements
Tuesday, October 4 Announcements www.singularsource.net Donate to my short story contest UCI Delta Sigma Pi Accepts business and ICS students See Facebook page for details Slide 2 1 Design Patterns Design
More informationNote: Each loop has 5 iterations in the ThreeLoopTest program.
Lecture 23 Multithreading Introduction Multithreading is the ability to do multiple things at once with in the same application. It provides finer granularity of concurrency. A thread sometimes called
More informationProduced by. Design Patterns. MSc in Communications Software. Eamonn de Leastar
Design Patterns MSc in Communications Software Produced by Eamonn de Leastar (edeleastar@wit.ie) Department of Computing, Maths & Physics Waterford Institute of Technology http://www.wit.ie http://elearning.wit.ie
More informationCSCD01 Engineering Large Software Systems. Design Patterns. Joe Bettridge. Winter With thanks to Anya Tafliovich
CSCD01 Engineering Large Software Systems Design Patterns Joe Bettridge Winter 2018 With thanks to Anya Tafliovich Design Patterns Design patterns take the problems consistently found in software, and
More informationCS342: Software Design. November 21, 2017
CS342: Software Design November 21, 2017 Runnable interface: create threading object Thread is a flow of control within a program Thread vs. process All execution in Java is associated with a Thread object.
More informationExercise Session Week 8
Chair of Software Engineering Java and C# in Depth Carlo A. Furia, Marco Piccioni, Bertrand Meyer Exercise Session Week 8 Quiz 1: What is printed? (Java) class MyTask implements Runnable { public void
More informationSoftware Design Patterns. Aliaksei Syrel
Software Design Patterns Aliaksei Syrel 1 Pattern types Creational Patterns Behavioural Patterns Structural Patterns 2 Creational Patterns Creational design patterns deal with object creation mechanisms,
More informationLecture 35. Threads. Reading for next time: Big Java What is a Thread?
Lecture 35 Threads Reading for next time: Big Java 21.4 What is a Thread? Imagine a Java program that is reading large files over the Internet from several different servers (or getting data from several
More informationUnit 4. Thread class & Runnable Interface. Inter Thread Communication
Unit 4 Thread class & Runnable Interface. Inter Thread Communication 1 Multithreaded Programming Java provides built-in support for multithreaded programming. A multithreaded program contains two or more
More informationPrinciples of Object Oriented Programming. Lecture 4
Principles of Object Oriented Programming Lecture 4 Object-Oriented Programming There are several concepts underlying OOP: Abstract Types (Classes) Encapsulation (or Information Hiding) Polymorphism Inheritance
More informationChair of Software Engineering. Java and C# in Depth. Prof. Dr. Bertrand Meyer. Exercise Session 8. Nadia Polikarpova
Chair of Software Engineering Java and C# in Depth Prof. Dr. Bertrand Meyer Exercise Session 8 Nadia Polikarpova Quiz 1: What is printed? (Java) class MyTask implements Runnable { «Everything is ok! public
More informationUNIT I Introduction to Design Patterns
SIDDHARTH GROUP OF INSTITUTIONS :: PUTTUR Siddharth Nagar, Narayanavanam Road 517583 QUESTION BANK (DESCRIPTIVE) Subject with Code : Design Patterns(9F00505c) Year & Sem: III-MCA I-Sem Course : MCA Regulation:
More informationExercise Session Week 8
Chair of Software Engineering Java and C# in Depth Carlo A. Furia, Marco Piccioni, Bertrand Meyer Exercise Session Week 8 Java 8 release date Was early September 2013 Currently moved to March 2014 http://openjdk.java.net/projects/jdk8/milestones
More informationOverview. CMSC 330: Organization of Programming Languages. Concurrency. Multiprocessors. Processes vs. Threads. Computation Abstractions
CMSC 330: Organization of Programming Languages Multithreaded Programming Patterns in Java CMSC 330 2 Multiprocessors Description Multiple processing units (multiprocessor) From single microprocessor to
More informationMultithreaded Programming
Multithreaded Programming Multithreaded programming basics Concurrency is the ability to run multiple parts of the program in parallel. In Concurrent programming, there are two units of execution: Processes
More informationThe Continuing Adventures of Java Puzzlers: Tiger Traps
The Continuing Adventures of Java Puzzlers: Tiger Traps Joshua Bloch and Neal Gafter Google Inc. TS-1188 2006 JavaOne SM Conference Session TS-1188 Introduction Eight more Java platform puzzles Short program
More informationObject-oriented Software Design Patterns
Object-oriented Software Design Patterns Concepts and Examples Marcelo Vinícius Cysneiros Aragão marcelovca90@inatel.br Topics What are design patterns? Benefits of using design patterns Categories and
More informationG51PGP Programming Paradigms. Lecture 009 Concurrency, exceptions
G51PGP Programming Paradigms Lecture 009 Concurrency, exceptions 1 Reminder subtype polymorphism public class TestAnimals public static void main(string[] args) Animal[] animals = new Animal[6]; animals[0]
More informationCSCI 136 Written Exam #2 Fundamentals of Computer Science II Spring 2015
CSCI 136 Written Exam #2 Fundamentals of Computer Science II Spring 2015 Name: This exam consists of 6 problems on the following 6 pages. You may use your double- sided hand- written 8 ½ x 11 note sheet
More informationMichele Van Dyne MUS 204B https://katie.mtech.edu/classes/csci136. Concurrency Issues
Michele Van Dyne MUS 204B mvandyne@mtech.edu https://katie.mtech.edu/classes/csci136 Concurrency Issues Multi-threaded programs Multiple simultaneous paths of execution Seemingly at once (single core)
More informationSystem Programming. Practical Session 4: Threads and Concurrency / Safety
System Programming Practical Session 4: Threads and Concurrency / Safety Using Threads - All the computer programs you've seen so far were sequential only one thing was performed at any given time - Sometimes
More informationUNIT I Introduction to Design Patterns
SIDDHARTH GROUP OF INSTITUTIONS :: PUTTUR Siddharth Nagar, Narayanavanam Road 517583 QUESTION BANK (DESCRIPTIVE) Subject with Code : Design Patterns (16MC842) Year & Sem: III-MCA I-Sem Course : MCA Regulation:
More informationCSCD01 Engineering Large Software Systems. Design Patterns. Joe Bettridge. Winter With thanks to Anya Tafliovich
CSCD01 Engineering Large Software Systems Design Patterns Joe Bettridge Winter 2018 With thanks to Anya Tafliovich Design Patterns Design patterns take the problems consistently found in software, and
More informationApplying the Observer Design Pattern
Applying the Observer Design Pattern Trenton Computer Festival Professional Seminars Michael P. Redlich (908) 730-3416 michael.p.redlich@exxonmobil.com About Myself Degree B.S. in Computer Science Rutgers
More informationApplying Some Gang of Four Design Patterns CSSE 574: Session 5, Part 3
Applying Some Gang of Four Design Patterns CSSE 574: Session 5, Part 3 Steve Chenoweth Phone: Office (812) 877-8974 Cell (937) 657-3885 Email: chenowet@rose-hulman.edu Gang of Four (GoF) http://www.research.ibm.com/designpatterns/pubs/ddj-eip-award.htm
More informationOODP Session 4. Web Page: Visiting Hours: Tuesday 17:00 to 19:00
OODP Session 4 Session times PT group 1 Monday 18:00 21:00 room: Malet 403 PT group 2 Thursday 18:00 21:00 room: Malet 407 FT Tuesday 13:30 17:00 room: Malet 404 Email: oded@dcs.bbk.ac.uk Web Page: http://www.dcs.bbk.ac.uk/~oded
More informationDesign patterns. OOD Lecture 6
Design patterns OOD Lecture 6 Next lecture Monday, Oct 1, at 1:15 pm, in 1311 Remember that the poster sessions are in two days Thursday, Sep 27 1:15 or 3:15 pm (check which with your TA) Room 2244 + 2245
More informationClass, Variable, Constructor, Object, Method Questions
Class, Variable, Constructor, Object, Method Questions http://www.wideskills.com/java-interview-questions/java-classes-andobjects-interview-questions https://www.careerride.com/java-objects-classes-methods.aspx
More informationModule - 4 Multi-Threaded Programming
Terminologies Module - 4 Multi-Threaded Programming Process: A program under execution is called as process. Thread: A smallest component of a process that can be executed independently. OR A thread is
More informationCSCI 136 Written Exam #1 Fundamentals of Computer Science II Spring 2012
CSCI 136 Written Exam #1 Fundamentals of Computer Science II Spring 2012 Name: This exam consists of 5 problems on the following 8 pages. You may use your double- sided hand- written 8 ½ x 11 note sheet
More informationCPSC 310 Software Engineering. Lecture 11. Design Patterns
CPSC 310 Software Engineering Lecture 11 Design Patterns Learning Goals Understand what are design patterns, their benefits and their drawbacks For at least the following design patterns: Singleton, Observer,
More informationConcurrency. CSCI 136: Fundamentals of Computer Science II Keith Vertanen
Concurrency http://csunplugged.org/routing-and-deadlock CSCI 136: Fundamentals of Computer Science II Keith Vertanen Overview Multi-threaded programs Multiple simultaneous paths of execution Seemingly
More informationDesign patterns. Jef De Smedt Beta VZW
Design patterns Jef De Smedt Beta VZW Who Beta VZW www.betavzw.org Association founded in 1993 Computer training for the unemployed Computer training for employees (Cevora/Cefora) 9:00-12:30 13:00-16:00
More informationIntroduction to Software Engineering: Object Design I Reuse & Patterns
Introduction to Software Engineering: Object Design I Reuse & Patterns John T. Bell Department of Computer Science University of Illinois, Chicago Based on materials from Bruegge & DuToit 3e, Chapter 8,
More informationDesign Patterns. An introduction
Design Patterns An introduction Introduction Designing object-oriented software is hard, and designing reusable object-oriented software is even harder. Your design should be specific to the problem at
More informationCS61B, Spring 2003 Discussion #17 Amir Kamil UC Berkeley 5/12/03
CS61B, Spring 2003 Discussion #17 Amir Kamil UC Berkeley 5/12/03 Topics: Threading, Synchronization 1 Threading Suppose we want to create an automated program that hacks into a server. Many encryption
More informationDesign Patterns Reid Holmes
Material and some slide content from: - Head First Design Patterns Book - GoF Design Patterns Book Design Patterns Reid Holmes GoF design patterns $ %!!!! $ "! # & Pattern vocabulary Shared vocabulary
More informationDesign Patterns: Structural and Behavioural
Design Patterns: Structural and Behavioural 3 April 2009 CMPT166 Dr. Sean Ho Trinity Western University See also: Vince Huston Review last time: creational Design patterns: Reusable templates for designing
More informationbe used for more than one use case (for instance, for use cases Create User and Delete User, one can have one UserController, instead of two separate
UNIT 4 GRASP GRASP: Designing objects with responsibilities Creator Information expert Low Coupling Controller High Cohesion Designing for visibility - Applying GoF design patterns adapter, singleton,
More informationCSC207H: Software Design Lecture 6
CSC207H: Software Design Lecture 6 Wael Aboelsaadat wael@cs.toronto.edu http://ccnet.utoronto.ca/20075/csc207h1y/ Office: BA 4261 Office hours: R 5-7 Acknowledgement: These slides are based on material
More information1 Software Architecture
Some buzzwords and acronyms for today Software architecture Design pattern Separation of concerns Single responsibility principle Keep it simple, stupid (KISS) Don t repeat yourself (DRY) Don t talk to
More informationSingleton Pattern Creational
Singleton Pattern Creational Intent» Ensure a class has only one instance» Provide a global point of access Motivation Some classes must only have one instance file system, window manager Applicability»
More informationConcurrency. Fundamentals of Computer Science
Concurrency http://csunplugged.org/routing-and-deadlock Fundamentals of Computer Science Outline Multi-threaded programs Multiple simultaneous paths of execution Seemingly at once (single core) Actually
More informationSocket attaches to a Ratchet. 2) Bridge Decouple an abstraction from its implementation so that the two can vary independently.
Gang of Four Software Design Patterns with examples STRUCTURAL 1) Adapter Convert the interface of a class into another interface clients expect. It lets the classes work together that couldn't otherwise
More informationCSCI 136 Written Exam #1 Fundamentals of Computer Science II Spring 2012
CSCI 136 Written Exam #1 Fundamentals of Computer Science II Spring 2012 Name: This exam consists of 5 problems on the following 8 pages. You may use your double- sided hand- written 8 ½ x 11 note sheet
More informationLectures 24 and 25 Introduction to Architectural Styles and Design Patterns
Lectures 24 and 25 Introduction to Architectural Styles and Design Patterns Software Engineering ITCS 3155 Fall 2008 Dr. Jamie Payton Department of Computer Science University of North Carolina at Charlotte
More informationModellistica Medica. Maria Grazia Pia, INFN Genova. Scuola di Specializzazione in Fisica Sanitaria Genova Anno Accademico
Modellistica Medica Maria Grazia Pia INFN Genova Scuola di Specializzazione in Fisica Sanitaria Genova Anno Accademico 2002-2003 Lezione 9 OO modeling Design Patterns Structural Patterns Behavioural Patterns
More informationDesign Patterns. Structural Patterns. Oliver Haase
Design Patterns Structural Patterns Oliver Haase 1 Purpose Structural patterns describe how to compose classes (incl. interfaces) and objects to get larger structures. Class based structural patterns use
More informationI, J. Key-value observing (KVO), Label component, 32 text property, 39
Index A Abstract factory pattern, 207 concrete factory, 213 examples in Cocoa, 227 groups of objects, 212 implementing, 213 abstract factories, 214 concrete factories, 214 215 operations, 212 213 pitfalls,
More informationJava s Implementation of Concurrency, and how to use it in our applications.
Java s Implementation of Concurrency, and how to use it in our applications. 1 An application running on a single CPU often appears to perform many tasks at the same time. For example, a streaming audio/video
More informationWhat is Design Patterns?
Paweł Zajączkowski What is Design Patterns? 1. Design patterns may be said as a set of probable solutions for a particular problem which is tested to work best in certain situations. 2. In other words,
More informationMore Patterns. Acknowledgement: Head-first design patterns
More Patterns Acknowledgement: Head-first design patterns Chain of Responsibility Acknowledgement: Head-first design patterns Problem Scenario: Paramount Pictures has been getting more email than they
More informationTecniche di Progettazione: Design Patterns
Tecniche di Progettazione: Design Patterns GoF: Builder, Chain Of Responsibility, Flyweight 1 Design patterns, Laura Semini, Università di Pisa, Dipartimento di Informatica. Builder 2 Design patterns,
More informationPrinciples of Software Construction: Concurrency, Part 2
Principles of Software Construction: Concurrency, Part 2 Josh Bloch Charlie Garrod School of Computer Science 1 Administrivia Homework 5a due now Homework 5 framework goals: Functionally correct Well documented
More informationChain of Responsibility Pattern
Chain of Responsibility Pattern As the name suggests, the chain of responsibility pattern creates a chain of receiver objects for a request. This pattern decouples sender and receiver of a request based
More informationCMSC 132: Object-Oriented Programming II
CMSC 132: Object-Oriented Programming II Synchronization in Java Department of Computer Science University of Maryland, College Park Multithreading Overview Motivation & background Threads Creating Java
More informationEINDHOVEN UNIVERSITY OF TECHNOLOGY
EINDHOVEN UNIVERSITY OF TECHNOLOGY Department of Mathematics & Computer Science Exam Programming Methods, 2IP15, Wednesday 17 April 2013, 09:00 12:00 TU/e THIS IS THE EXAMINER S COPY WITH (POSSIBLY INCOMPLETE)
More informationMultitasking Multitasking allows several activities to occur concurrently on the computer. A distinction is usually made between: Process-based multit
Threads Multitasking Multitasking allows several activities to occur concurrently on the computer. A distinction is usually made between: Process-based multitasking Thread-based multitasking Multitasking
More informationINF 212 ANALYSIS OF PROG. LANGS CONCURRENCY. Instructors: Crista Lopes Copyright Instructors.
INF 212 ANALYSIS OF PROG. LANGS CONCURRENCY Instructors: Crista Lopes Copyright Instructors. Basics Concurrent Programming More than one thing at a time Examples: Network server handling hundreds of clients
More informationCSCI 136 Written Exam #1 Fundamentals of Computer Science II Spring 2015
CSCI 136 Written Exam #1 Fundamentals of Computer Science II Spring 2015 Name: This exam consists of 5 problems on the following 7 pages. You may use your double- sided hand- written 8 ½ x 11 note sheet
More informationA Reconnaissance on Design Patterns
A Reconnaissance on Design Patterns M.Chaithanya Varma Student of computer science engineering, Sree Vidhyanikethan Engineering college, Tirupati, India ABSTRACT: In past decade, design patterns have been
More informationSingle processor CPU. Memory I/O
Lec 17 Threads Single processor CPU Memory I/O Multi processes Eclipse PPT iclicker Multi processor CPU CPU Memory I/O Multi-core Core Core Core Core Processor Memory I/O Logical Cores Multi-threaded
More informationSoftware Quality Management
2004-2005 Marco Scotto (Marco.Scotto@unibz.it) Course Outline Creational Patterns Singleton Builder 2 Design pattern space Purpose Creational Structural Behavioral Scope Class Factory Method Adapter Interpreter
More informationCOSC 3351 Software Design. Design Patterns Behavioral Patterns (I)
COSC 3351 Software Design Design Patterns Behavioral Patterns (I) Spring 2008 Purpose Creational Structural Behavioral Scope Class Factory Method Adapter(class) Interpreter Template Method Object Abstract
More informationSoftware Design COSC 4353/6353 D R. R A J S I N G H
Software Design COSC 4353/6353 D R. R A J S I N G H Design Patterns What are design patterns? Why design patterns? Example DP Types Toolkit, Framework, and Design Pattern A toolkit is a library of reusable
More informationPart IV Other Systems: I Java Threads
Part IV Other Systems: I Java Threads Spring 2019 C is quirky, flawed, and an enormous success. 1 Dennis M. Ritchie Java Threads: 1/6 Java has two ways to create threads: Create a new class derived from
More informationJava Threads Vs Processes. CS Concurrent Programming. Java Threads. What can a thread do? Java Concurrency
Java Threads Vs Processes CS6868 - Concurrent Programming Java Concurrency V. Krishna Nandivada Typically each instance of JVM creates a single process. Each process creates one or more threads. Main thread
More information