DOCSLIB.ORG

Design Patterns Erich Gamma IBM Distinguished Engineer IBM Rational Research Lab Zurich Erich [email protected]

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Design Patterns Erich Gamma IBM Distinguished Engineer IBM Rational Research Lab Zurich Erich Gamma@Ch.Ibm.Com Design Patterns Erich Gamma IBM Distinguished Engineer IBM Rational Research Lab Zurich [email protected] 2 outline . past . patterns in action . patterns today . next 3 a fifteen year old thought experiment imagine that you are struggling with a • you have spent days on the problem difficult software design • there was no obvious answer problem …in frustration and desperation you reach up to your bookshelf or google .... • presents design problems, issues, and solutions in a commonly ... and find the answer in understood and shared language The Software • captures experience and expertise of designers Architecture Handbook • provides a common and agreed position of what constitutes good and bad design unfortunately the handbook does not exist but raises some • what should such a handbook contain and not contain? interesting questions • Who would use it? How would they use it? about what it might look • how could readers can best absorb the content and put into it into like practice? See also http://www.handbookofsoftwarearchitecture.com created by Grady Booch 4 towards the goal ? • http:// www.handbookofsoftwarearchitecture.co m initiated by Grady Booch The Handbook of Software Architecture is a concise reference on the design of software-intensive systems. Written for software architects, developers, and project managers, the Handbook presents the fundamentals of software architecture, covering contemporary best practices for specifying, visualizing, documenting, governing, and evolving a system's significant design decisions. The center of this work presents the as-built architecture of a variety of software- intensive systems selected from across the industry and from across the world. 5 clues from other disciplines mechanical engineering furniture and timber architecture handbooks framing handbooks “I have drawn up definite rules to “Mechanisms of Modern "If you combine technique and enable you to have personal Engineering Design”: Ivan knowledge of the material, will knowledge of the quality both of Artobolevsky 1947 automatically design around the existing buildings and of those construction, and not construct which are yet to be constructed." around the design. ... as ... construction becomes second "A temple is called IN ANTIS, nature when you are designing." when it has antæ or pilasters in front of the walls which Tage Frid enclose ..." Marcus Vitruvius Pollio “De Architectura Libri Decem" 27 BC 6 capturing and describing good design describe • captures commonly occurring solutions to commonly problems that occur again and again recurring designs • helps avoid design déjà vu • provides guidelines when to use and when not grounded in real practice • captures “why” decisions, design alternatives, rationale • provides design alternatives and describes not just descriptive relative merits and trade-offs • provides implementation hints extracts essence of design • provides freedom to adapt to particular context A Pattern is a way to capture recurring designs in such a way that Design Patterns others can readily acquire and use the knowledge and experience 7 a design patterns inspiration . The iPhone SDK is based on the NeXTStep object-oriented frameworks . Existed before we wrote Design Patterns 15 years ago . Source of inspiration for several design pattern variations for: Adapter, Bridge, Proxy, Observer and Chain of Responsibility good design survives 8 early steps - recurring patterns in object- oriented designs Initial Focus on Object Oriented Design First dozen of patterns reverse architected from ET++ (91) Jim Coplien’s catalog of C++ idioms (91) John Vlissides, Ralph Johnson, Richard Helm, Erich Gamma get together between (90-92) to write Design Patterns • Smalltalk, C++ focus • first version of catalog • 23 pages long • only experts understand it: • “oh, I’ve done that” • Inspirations from Smalltalk, InterViews, NeXTStep, ET++ Design Patterns published October 1994 9 eclipse . introduced . pattern variations . XML based configuration . extension points, lazy loading . API focus . evolution patterns 10 eclipse pattern variations . XML based configuration for extending the system plugin.xml <action toolbarPath=“search" icon="icons/opentype.gif“ toolTip=“Open Type” class="org.eclipse.jdt.OpenTypeAction"/> lazily instantiated using reflection org/eclipse/jdt/OpenTypeAction.class contribution implementation 11 APIs first . APIs don’t just happen; we need to design them . specifications with precisely defined behavior . what you can assume (and what you cannot) . it works ≠ API compliant . documented classes ≠ API . must have at least one client involved, preferably more 12 API evolution patterns . compatibility layer . I*2 extensions interfaces public interface IActionDelegate { … } // original interface public interface IActionDelegate2 extends IActionDelegate { void dispose(); } if (d instanceof IActionDelegate2) { IActionDelegate2 d2 = (IActionDelegate2) d; d2.dispose(); // call new method } . extension object pattern: IAdaptable 13 Extension Object Pattern: IAdaptable . adding interfaces to existing types . Interface negotiation <extension point="org.eclipse.core.runtime.adapters"> <factory class="org.eclipse.jdt.internal.ui.JavaElementAdapterFactory" adaptableType="org.eclipse.jdt.core.IJavaElement"> <adapter type="org.eclipse.ui.IPersistableElement"/> … </factory> 14 JUnit . A simple framework . Design pattern dense . Simplified using annotation/attribute based programming 15 JUnit3 ⇒ JUnit4 Test Composite:Component run(TestResult) . thinned framework for the client (inspiration from NUnit) Command TestCase TestSuite Composite Template Method run(TestResult) run(TestResult) “replaced” inheritance with fTests runTest() addTest(Test) setUp() annotations TestResult tearDown() Composite: Leaf Collecting Parameter fName Pluggable Adapter MoneyTest MoneyTest Command @Before setUp() setUp() @Test simpleAdd() testSimpleAdd() @Test mixedAdd() testMixedAdd() JUnit3 JUnit4 outline . past . patterns in action . patterns today . next 17 scope of patterns has broadened 70's 80's 90's 2000's Today Topics Buildings & Architecture Requirements Analysis OOPSL ECOOP Software Design A BOF Architecture System Design Programming Conferences J2EE, .NET Organisation Real-time, Embedded Project Management, Organisation Source: Amazon,com, Hillside.net 16 years of growth 18 patterns today - useful, used, useable . useful - patterns enable to repeat a successful design done by someone else . between 'if-then-else" and layering, decoupling . a good pattern is convincing . non-obvious solution ⇒ surprise its users, experts “I’ve done that” . used - recurring phenomenon . used in discussions, in code and documentation to talk about design . APIs and libraries . usable major. include contribution coding is communication details, support of commonly many variations occurring design problems and solutions 19 patterns community . the active pattern community was and is a key element to the success of patterns . the pattern community has its own culture . writer’s workshop . shepherding work . published as “Pattern Languages of Program Design” . 9 regular conferences on 5 continents . ChiliPLoP, EuroPLoP, VikingPLoP, KoalaPLoP, SugarLoaf PLoP,… . 5 volumes of “pattern languages of program design” ⇒ patterns continue to flourish ⇒ new leaders are emerging 20 patterns & design . refactor to patterns . patterns not measure of goodness . some patterns are cool, but this doesn't make them more relevant . patterns used for . variability management . decoupling . dependency management patterns a means to an end, not the end 21 patterns & complexity . each pattern makes a system a little bit more complex . software infrastructures are getting more and more complex… . using lots of unnecessary patterns makes a system so complex that it becomes unmanageable this isn't the patterns fault… but … we have never discussed when to remove a pattern from a system 22 dangerous patterns . Mediator . supposed to be used to allow colleagues to be reusable . is often used to allow programmers to continue to be procedural. Singleton . supposed to be used to encapsulate global state when it cannot be eliminated . is often used as a justification of global state adding global state is easy – removing it hard! 23 what the students are saying about patterns . “we had them all…” . Erich Gamma is considered the enemy by many CS students . patterns are supposed to solve real software engineering problems (or something; what do I know?) . I spent most of the time trying to figure out what "Chocolate Factory" and various bizarre chocolate eating habits that border on obsessive-compulsive disorder had to do with the Abstract Factory and Singleton design patterns have we solved how to teach patterns? 24 feedback: “voting off the island” . OOPSLA workshop 2004*: people voted on the patterns to indicate which ones they felt needed deletion in the current form . four patterns were voted off . Factory Method – confusion with Factory . Bridge . Flyweight . Interpreter . reason: people felt they were sufficiently uncommon . split decisions . Singleton . Chain of Responsibility * http://martinfowler.com/bliki/OOPSLA2004.html 25 feedback “while the book is still essential reading for anyone in the OO space, there's much that could be done to modernize it” -- Martin Fowler “there is more to both OO design and patterns than is achieved or intended by the Gang of Four” -- Frank Buschmann, Kevlin Henney “Beyond the Gang of Four” I totally agree!! 26 outline . past . patterns
Load more

Recommended publications
  • Automatically Detecting ORM Performance Anti-Patterns on C# Applications Tuba Kaya Master's Thesis 23–09-2015
    Automatically Detecting ORM Performance Anti-Patterns on C# Applications Tuba Kaya Master's Thesis 23–09-2015 Master Software Engineering University of Amsterdam Supervisors: Dr. Raphael Poss (UvA), Dr. Giuseppe Procaccianti (VU), Prof. Dr. Patricia Lago (VU), Dr. Vadim Zaytsev (UvA) i Abstract In today’s world, Object Orientation is adopted for application development, while Relational Database Management Systems (RDBMS) are used as default on the database layer. Unlike the applications, RDBMSs are not object oriented. Object Relational Mapping (ORM) tools have been used extensively in the field to address object-relational impedance mismatch problem between these object oriented applications and relational databases. There is a strong belief in the industry and a few empirical studies which suggest that ORM tools can cause decreases in application performance. In this thesis project ORM performance anti-patterns for C# applications are listed. This list has not been provided by any other study before. Next to that, a design for an ORM tool agnostic framework to automatically detect these anti-patterns on C# applications is presented. An application is developed according to the designed framework. With its implementation of analysis on syntactic and semantic information of C# applications, this application provides a foundation for researchers wishing to work further in this area. ii Acknowledgement I would like to express my gratitude to my supervisor Dr. Raphael Poss for his excellent support through the learning process of this master thesis. Also, I like to thank Dr. Giuseppe Procaccianti and Prof. Patricia Lago for their excellent supervision and for providing me access to the Green Lab at Vrije Universiteit Amsterdam.
    [Show full text]
  • Experimental Algorithmics from Algorithm Desig
    Lecture Notes in Computer Science 2547 Edited by G. Goos, J. Hartmanis, and J. van Leeuwen 3 Berlin Heidelberg New York Barcelona Hong Kong London Milan Paris Tokyo Rudolf Fleischer Bernard Moret Erik Meineche Schmidt (Eds.) Experimental Algorithmics From Algorithm Design to Robust and Efficient Software 13 Volume Editors Rudolf Fleischer Hong Kong University of Science and Technology Department of Computer Science Clear Water Bay, Kowloon, Hong Kong E-mail: [email protected] Bernard Moret University of New Mexico, Department of Computer Science Farris Engineering Bldg, Albuquerque, NM 87131-1386, USA E-mail: [email protected] Erik Meineche Schmidt University of Aarhus, Department of Computer Science Bld. 540, Ny Munkegade, 8000 Aarhus C, Denmark E-mail: [email protected] Cataloging-in-Publication Data applied for A catalog record for this book is available from the Library of Congress. Bibliographic information published by Die Deutsche Bibliothek Die Deutsche Bibliothek lists this publication in the Deutsche Nationalbibliografie; detailed bibliographic data is available in the Internet at <http://dnb.ddb.de> CR Subject Classification (1998): F.2.1-2, E.1, G.1-2 ISSN 0302-9743 ISBN 3-540-00346-0 Springer-Verlag Berlin Heidelberg New York This work is subject to copyright. All rights are reserved, whether the whole or part of the material is concerned, specifically the rights of translation, reprinting, re-use of illustrations, recitation, broadcasting, reproduction on microfilms or in any other way, and storage in data banks. Duplication of this publication or parts thereof is permitted only under the provisions of the German Copyright Law of September 9, 1965, in its current version, and permission for use must always be obtained from Springer-Verlag.
    [Show full text]
  • ADPLUS, 307–308 Aggregate Method, 260 ASP.NET MVC Index View, 180 in .NET 4.0 APM, 183 Asynccontroller, 181 EAP, 181 Indexasyn
    Index A page lifecycle, 166 synchronous WebForms implementation, 167 ADPLUS, 307–308 Async and await keywords Aggregate method, 260 asynchronous web page word count, 137 ASP.NET MVC CalculateMeaningOfLifeAsync method, 135 Index View, 180 catch block, 136 in .NET 4.0 coercing result, 135 APM, 183 keyword performance, 136 AsyncController, 181 mechanics EAP, 181 awaiter implementation, 146 IndexAsync implementation, 182 GetAwaiter method, 146 IndexCompleted method INotifyCompletion interface, 146 implementation, 182 TickTockAsync method, 145, 147 Multiple Async I/O Operations, 183 reserved word language, 135 in .NET 4.5, 184 return type method, 135 Synchronous Controller, 179 SynchronizationContext, 137 ASP.NET Web API synchronous structure, 134 in .NET 4.0, 186 synchronous web page word count, 136 in .NET 4.5, 187 task delay Synchronous, 185 synchronous back off and retry, 140 ASP.NET WebForms thread efficient back off and retry, 140 AuthorRepository implementation, 167 task effects, 137 GetAuthors method, 167 Task.WhenAll in .NET 4.0 downloading documents one by one, 141 Begin method implementation, 171 download many documents Complex Async Page, 174 asynchronous, 141 End method implementation, 172 error handling, 142 error handling, 175 Task.WhenAny IAsyncResult, 172 task code, 143 lifecycle, 170 UI updation, 143 marking, 170 winning task, 143 registering, 171 UI event handler, 133 in .NET 4.5 UI responsive goal, 134 async and await, 178 UI thread RegisterAsyncTask method, 177 API ways, 139 Task.WhenAll, 178 asynchronously loading web
    [Show full text]
  • Bowling Game Kata .NET
    6 Design Patterns to Improve Your Web Apps Steve Smith (@ardalis) [email protected] Ardalis.com Podcast: WeeklyDevTips.com Design Patterns http://flic.kr/p/8XgqKu Stages of Learning Stage Zero - Ignorance Stage One - Awakening Stage Two - Overzealous Stage Three – Mastery http://flic.kr/p/6StgW5 Language http://flic.kr/p/6UpMt9 Design Patterns Iterator Unit of Work Composite Specification Most Useful (for web app design) .(Singleton) .Strategy .Repository .Proxy / Decorator .Command .Builder .Null Object Singleton: Intent .Ensure a class has only one instance .Make the class itself responsible for keeping track of its sole instance .“There can be only one” Singleton Structure (not thread-safe) Singleton Structure (thread-safe and fast) Source: http://csharpindepth.com/Articles/General/Singleton.aspx Singleton Consequences . The default implementation is not thread-safe Avoid in multi-threaded environments Avoid in web server scenarios (e.g. ASP.NET) . Introduce tight coupling among collaborating classes Some commercial tools can be used to mock and . Singletons are notoriously difficult to test test Singletons Commonly regarded as an anti-pattern But why would you intentionally write code you can only test with certain premium tools? Singleton Consequences .Violate the Single Responsibility Principle Class is responsible for managing its instances as well as whatever it does .Using an IOC Container it is straightforward to avoid the coupling and testability issues Managing Object Lifetime Using an IOC Container (StructureMap) Object Lifetime in ASP.NET Core public void ConfigureServices(IServiceCollection services) { services.AddMvc(); // you don’t need to implement singleton behavior in class! services.AddSingleton<ISomeService>(); } Singleton behavior is fine and often desirable.
    [Show full text]
  • Introduction to Microservices Architecture Training
    Specialized - Introduction to Microservices Architecture Training Code: WA2755 Length: 2 days URL: View Online This training course will help the attendees understand the value proposition and technical aspects of microservices. You will learn about the pros and cons of breaking up the monolithic type of applications prevalent in the enterprise space and converting them into microservices-based solutions. Detailed analysis of some of the common patterns and motivation for using them in microservices architecture is also provided. Who Can Benefit IT Architects, Software Designers, Developers. Prerequisites Foundational knowledge of programming and software design principles. Course Details Outline of Introduction to Microservices Architecture Training Chapter 1. Breaking Up Monoliths – Pros and Cons Traditional Monolithic Applications and Their Place Disadvantages of Monoliths Developer's Woes Architecture Modernization Architecture Modernization Challenges Microservices Architecture is Not a Silver Bullet! What May Help? In-Class Discussion Summary Chapter 2. Microservices What is a "Microservice"? Unix Analogy Principles of Microservices Services within an SOA vs Microservices Properties and Attributes of Microservices Benefits of Using Microservices The Two-Pizza Teams Beware of Microservices Cons Anti-Pattern: Nanoservices The Twelve-Factor App Methodology The Select Factors Serverless Computing Microservices – Operational Aspects Summary Chapter 3. Microservices Architecture Defined The Microservices Architecture SOA Promises and Expectations Microservices Architecture vs SOA The ESB Connection Microservices Architecture Benefits Microservices Architecture Choices and Attributes Example: On-Line Banking Solution Based on MsA Distributed Computing Challenges Replaceable Component Architecture The Actor Model MapReduce Distributed Computing Framework Hadoop's MapReduce Word Count Job Example What Can Make a Microservices Architecture Brittle? 4+1 Architectural View Model Summary Chapter 4.
    [Show full text]
  • Distributed Architecture, Interaction, and Data Models
    DST Summer 2018, Lecture 1 Distributed Architecture, Interaction, and Data Models Hong-Linh Truong Faculty of Informatics, TU Wien [email protected] http://www.infosys.tuwien.ac.at/staff/truong Twitter: @linhsolar DST 2018 1 Ack: Some slides are based on previous lectures in SS 2013-2015 DST 2018 2 Outline . Overview . Key design concepts . Architecture styles and Interaction Models . Data models . Optimizing interactions . Summary DST 2018 3 DST Lectures versus Labs . Cover some important topics in the current state-of-the-art of distributed systems technologies . We have focusing topics . Few important parts of the techniques for your labs . Most techniques you will learn by yourself . Stay in the concepts: no specific implementation or programming languages DST 2018 4 DST Lectures versus Labs . It is not about Java or Enterprise Java Beans! . The technologies you learn in the lectures are for different applications/systems DST 2018 5 Have some programming questions? Or send the questions to the tutors DST 2018 6 Where is our focus? Backend versus front-end Full stack developer Figure source - Figure source - https://medium.com/dev- https://www.upwork.com/hiring/development/a bits/why-full-stack-development-is-too-good- -beginners-guide-to-back-end-development/ for-you-in-2017-3fd6fe207b34 DST topics: DST topics: Non DST Backend services in multi- Communications topics cloud environments with Front-end Front-end DST 2018 7 TRENDS & KEY DESIGN CONCEPTS DST 2018 8 Rapid changes in application requirements and technologies for distributed applications . On-premise servers public clouds and on-premise clouds . Static, small infrastructures large-scale virtualized dynamic infrastructures .
    [Show full text]
  • Design Pattern in OO ABL.Pdf
    Design Pattern in OO ABL Klaus Erichsen, IAP GmbH Introduction This PDF is the compiled and reworked version of a series of 3 blog entries. It will have a look on 7 Object Oriented Design Pattern in the context of the OpenEdge OO ABL. The original blog entries and the whole sample source code are available on line, see links at end of this PDF. Wikipedia says: ‘In software engineering, a software design pattern is a general, reusable solution to a commonly occurring problem within a given context in software design.’ Patterns are conceptual work, the idea has been known to the public ever since the publication of the book ‘Design Patterns: Elements of Reusable Object-Oriented Software’, in 1995. In a larger project, design patterns help to keep the code reusable, readable, and to avoid problems in the long term. This article will describe how to implement some of the patterns in OpenEdge Object Oriented ABL – shortly named OO ABL. The chosen patterns are very common and often used. The view to the patterns is driven by daily, practical work. Design Pattern in OO ABL Table of Contents Pattern 1 – Builder (Creational Pattern)................................................................................3 Pattern 2 – Singleton (Creational Pattern).............................................................................7 Pattern 3 – Multiton (Creational Pattern)..............................................................................9 Pattern 4 – Lazy Loading (Creational Pattern)....................................................................12
    [Show full text]
  • Jboss Administration and Development
    Edition 1 Date: 2004-05-21, 4:04:58 PM ADRIAN BROCK The JBoss Group JBoss Tuning PAGE ii ADRIAN BROCK AND THE JBOSS GROUP JBoss Tuning © JBoss Group, LLC 2520 Sharondale Dr. Atlanta, GA 30305 USA [email protected] Page ii PAGE iii Table of Contents Preface............................................................................................................... viii Forward ........................................................................................................................................ viii About the Authors.......................................................................................................................... viii Acknowledgments .......................................................................................................................... viii 0. Introduction................................................................................................B—1 What this Book Covers ................................................................................................................ B—1 Organization............................................................................................................................... B—1 1. Concepts .......................................................................................................... 3 Aims ............................................................................................................................................... 3 Guaranteed Response Time ..............................................................................................................................3
    [Show full text]
  • Design-Pattern-Questions
    Java Design pattern interview questions codespaghetti.com/java-design-pattern-interview-questions/ Design Patterns Java Design Pattern Interview Questions, Programs and Examples. Table of Contents: CHAPTER 1: Singleton Pattern Interview Questions CHAPTER 2: Factory Pattern Interview Questions CHAPTER 3: Builder Pattern Interview Questions CHAPTER 4: Proxy Pattern Interview Questions CHAPTER 5: Decorator Pattern Interview Questions Top Five Java Design Pattern Interview Questions What Are Advantages of Design Patterns? A design patterns are well-proved solution for solving the specific problem. The benefit of design patterns lies in reusability and extensibility of the already developed applications. Design patterns use object-oriented concepts like decomposition, inheritance and polymorphism. They provide the solutions that help to define the system architecture. 1/18 What Are Disadvantages of Design Patterns? Design Patterns do not lead to direct code reuse. Design Patterns are deceptively simple. Teams may suffer from patterns overload. Integrating design patterns into a software development process is a human-intensive activity. Singleton Design Pattern Interview Questions What does singleton Design Pattern do It ensures that a class has only one instance, and provides a global point of access to it. When to use Singleton? Use the Singleton when There must be exactly one instance of a class, and it must be accessible to clients from a well-known access point when the sole instance should be extensible by subclassing, and clients should be able to use an extended instance without modifying their code Typical Use Cases The logging class Managing a connection to a database File manager Real world examples of singleton java.lang.Runtime#getRuntime() java.awt.Desktop#getDesktop() java.lang.System#getSecurityManager() 2/18 Disadvantages of singleton Violates Single Responsibility Principle (SRP) by controlling their own creation and lifecycle.
    [Show full text]
  • High Performance Spring Programming
    International Journal of Computer ScienceSciencessss and Engineering Open Access Research Paper Volume-2, Issue-8 E-ISSN: 2347-2693 High Performance Spring Programming Vamsi Krishna Myalapalli Open Text Corporation, Mind Space IT Park, Hi-Tec City, Hyderabad, India www.ijcaonline.org Received: 02/07/ 2014 Revised: 22/07/ 2014 Accepted: 17/08/ 2014 Published: 31 /08/ 2014 Abstract —In the contemporary world Spring Application Framework is the most prevalently used application framework due to its IoC (Inversion of Control) property. Many of the Spring developers simply do programming with less concern towards optimized processing. Though Spring Framework offers sundry ways of programming techniques to reach the same end, certain practices are pre requisite to ensure that consequences will be prolific. This paper proposes miscellaneous, simple, reliable, flexible and easy techniques to make programs more efficient. The exploration in this paper would serve as a benchmarking tool for assessing best programming practices. Experimental results of analysis designate that maintainability, flexibility and reusability are enhanced. Keywords—Spring Best Practices; Spring Tuning; Spring Tactics; Spring Core; Spring Framework Tactics; Efficient Spring Practices. I. INTRODUCTION e) Enhanced Testability. The Spring Framework is an open source application f) Fosters good Application Design. framework created to simplify the development of enterprise Java software. The framework achieves this goal by providing developers with a component model and a set of simplified and consistent APIs that effectively insulate developers from the complexity and error-prone boilerplate code required to create complex applications. The Core of the Spring Framework is its IoC (Inversion of Control) container, which offers a reliable means of configuring and managing Java objects using reflection.
    [Show full text]
  • Design Patterns
    2 Design Patterns Now let’s move from concrete object-oriented implementations to some more abstract concepts, beginning with design patterns. Design patterns have been all the rage for the past several years, and who has not felt a little unsure of themselves when someone says, “You don’t know what the Memento pattern is?” In all honesty, I do not. I pulled it out of the air from Wikipedia (see http://en.wikipedia.org/wiki/ Memento_pattern). Although many design-pattern proponents are annoying, understanding and implementing design patterns can provide a lot of benefits, particularly some of the design patterns I present here. You can think of these as base patterns. A design pattern has absolutely nothing to do with software. It is an architectural process first brought into form by architect Christopher Alexander. It states that patterns of design are inherent in many different instances. In other words, project A and project B, though completely disparate in every way, can still have similarities in design because of similar problems that need to be solved. Advanced Guide to PHP on IBM i In Alexander’s book A Pattern Language (Oxford University Press, 1977), he describes how people should be able to build their own homes and communities through a series of patterns. These patterns are made available via the implementation of doors, walls, windows, colors, and such to make a community in the likeness of the desires of the people who are living there. Although I have not read the book, it has a number of interesting observations that seem worth considering.
    [Show full text]
  • Patterns of Parallel Programming
    PATTERNS OF PARALLEL PROGRAMMING UNDERSTANDING AND APPLYING PARALLEL PATTERNS WITH THE .NET FRAMEWORK 4 AND VISUAL C# Stephen Toub Parallel Computing Platform Microsoft Corporation Abstract This document provides an in-depth tour of support in the Microsoft® .NET Framework 4 for parallel programming. This includes an examination of common parallel patterns and how they’re implemented without and with this new support, as well as best practices for developing parallel components utilizing parallel patterns. Last Updated: July 1, 2010 This material is provided for informational purposes only. Microsoft makes no warranties, express or implied. ©2010 Microsoft Corporation. TABLE OF CONTENTS Introduction ................................................................................................................................................................... 3 Delightfully Parallel Loops ............................................................................................................................................. 4 Fork/Join ...................................................................................................................................................................... 36 Passing Data ................................................................................................................................................................. 49 Producer/Consumer ...................................................................................................................................................
    [Show full text]