Design Pattern Creazionali

Total Page:16

File Type:pdf, Size:1020Kb

Design Pattern Creazionali DESIGN PATTERN CREAZIONALI DESIGN PATTERN CREAZIONALI INGEGNERIA DEL SOFTWARE Università degli Studi di Padova Dipartimento di Matematica Corso di Laurea in Informatica, A.A. 2017 – 2018 Architetturali [email protected] Model view controller Ingegneria del software Riccardo Cardin 2 INTRODUZIONE SINGLETON Scopo dei design pattern creazionali Scopo Assicurare l’esistenza di un’unica istanza di una classe Rendere un sistema indipendente … ed avere un punto di accesso globale a questa dall’implementazione concreta delle sue componenti Si nascondono i tipi concreti delle classi realmente utilizzate Motivazione Si nascondono i dettagli sulla composizione e creazione Alcune entità NON DEVONO avere più di un’istanza Riduzione accoppiamento e flessibilità Non è possibile utilizzare una variabile globale (C++) La classe deve tenere traccia della sua unica istanza Ampio uso dell’astrazione / interfacce Ingegneria del software Riccardo Cardin 3 Ingegneria del software Riccardo Cardin 4 SINGLETON SINGLETON Applicabilità Struttura /* * Implementazione Java Definisce getInstance che permette * "naive" */ l’accesso all’unica istanza. È Deve esistere una e una sola istanza di una classe in public class Singleton { responsabile della creazione dell’unica private static tutta l’applicazione istanza Singleton instance; L’istanza deve essere accessibile dai client in modo noto private Singleton() { /* Corpo vuoto */ } L’istanza deve essere estendibile con ereditarietà public static Singleton getInstance() { I client non devono modificare il proprio codice if (instance == nul) { instance = new Singleton(); } return instance; } } Ingegneria del software Riccardo Cardin 5 Ingegneria del software Riccardo Cardin 6 SINGLETON SINGLETON Conseguenze Esempio Esempio Controllo completo di come e quando i client Un applicativo deve istanziare un oggetto che gestisce una accedono all’interfaccia stampante (printer spooler). Questo oggetto deve essere unico perché Evita il proliferare di variabili globali (C++) si dispone di una sola risorsa di stampa. Permette la ridefinizione delle operazioni definite nel Singleton Può permettere un numero massimo e preciso di istanze attive Più flessibile delle operazioni di classe Utilizzo del polimorfismo Ingegneria del software Riccardo Cardin 7 Ingegneria del software Riccardo Cardin 8 SINGLETON SINGLETON Esempio Implementazione Printer Spooler Assicurare un’unica istanza attiva (lazy initialization) Si rende il/i costruttore/i privato/i (non accessibili) Si rende disponibile un’operazione di classe di “recupero” Non è possibile utilizzare variabili globali (C++) Non garantisce l’unicità dell’istanza L’istanza è generata durante l’inizializzazione “statica” L’appoccio non è thread safe in Tutti i singleton sarebbero costruiti sempre, anche se mai Java: nessuna sincronizzazione utilizzati sulla creazione di instance Ingegneria del software Riccardo Cardin 9 Ingegneria del software Riccardo Cardin 10 SINGLETON SINGLETON Soffrono di attacco per Reflection sul costruttore Implementazione Implementazione Ereditare da una classe Singleton Java Costruttore privato (omesso per spazio) public class PrinterSpooler { È difficile installare l’unica istanza nel membro instance private static final PrinterSpooler INSTANCE = new PrinterSpooler(); public static PrinterSpooler getInstance() { La soluzione migliore è utilizzare un registro di singleton return INSTANCE; public class Singleton { } private static Singleton instance; } private static Map<String, Singleton> registry; public class MySingleton no lazy, thread safe, no subclassing, no serializable extends Singleton { private Singleton() { /* Corpo vuoto */ } public class PrinterSpooler { static { public static register(String name, Singleton) private static volatile PrinterSpooler INSTANCE; { /* ... */} Singleton.register(“MySingleton”, public static PrinterSpooler getInstance() { new MySingleton()) if (INSTANCE == null) { protected static Singleton lookup(String name) } synchronize (PrinterSpooler.class) { { /* ... */} /* ... */ if (INSTANCE == null { INSTANCE = new PrinterSpooler(); } public static Singleton } } getInstance(String singletonName) { } return INSTANCE; /* Utilizza lookup per recuperare l’istanza */ } } } } lazy, thread safe, subclassing possibile, no serializable Ingegneria del software Riccardo Cardin 11 Ingegneria del software Riccardo Cardin 12 SINGLETON SINGLETON Cons: meno Implementazione Implementazione controllo sull’inizializzazione Java Scala object PrinterSpooler extends ... { Versione accettata da JDK ≥ 1.5 def print(file: String) { public enum PrinterSpooler { // do something INSTANCE; } } public void print(String file) { /* ... */ } } In Java il pattern Sigleton è uno dei più utilizzati no lazy, thread safe, no subclassing, serializable Mancanza a livello di linguaggio Item 3 di Effective Java di Joshua Bloch Error prone Usa costrutti nativi del linguaggio Scala risolve introducendo il tipo object Non soffre di alcun attacco Implementazione del pattern Singleton nel linguaggio Conciso, leggibile e manutenibile Thread‐safe Gli Object sono inizializzati su richiesta (laziness) Ingegneria del software Riccardo Cardin 13 Ingegneria del software Riccardo Cardin 14 SINGLETON BUILDER Implementazione Scopo Javascript: si utilizza il module pattern Private Separa la costruzione di un oggetto complesso dalla namespace var mySingleton = (function () { var instance; sua rappresentazione function init() { // Private methods and variables function privateMethod() { console.log( "I am private" ); }; Motivazione var privateRandomNumber = Math.random(); Necessità di riutilizzare un medesimo algoritmo di return { // Public methods and variables costruzione per più oggetti di tipo differente publicMethod: function () { console.log( "The public can see me!" ); Processo di costruzione step‐by‐step }, getRandomNumber: function() { return privateRandomNumber; } }; Il cassiere deve: }; return { 1. Inserire il panino getInstance: function () { Public 2. Inserire le patate if ( !instance ) { instance = init(); } return instance; functions/variables 3. Inserire la frutta } 4. ... }; })(); Ingegneria del software Riccardo Cardin 15 Ingegneria del software Riccardo Cardin 16 BUILDER BUILDER Esempio Applicabilità La procedura di creazione di un oggetto complesso deve essere indipendente dalle parti che compongono l’oggetto Il processo di costruzione deve permettere diverse rappresentazioni per l’oggetto da costruire Ingegneria del software Riccardo Cardin 17 Ingegneria del software Riccardo Cardin 18 BUILDER BUILDER Struttura Struttura Costruisce un oggetto Specifica l’interfaccia da utilizzando il builder utilizzare per assemblare Il client conosce il tipo (procedura) il prodotto builder concreto Il director notifica il builder delle parti che devono essere costruite Il prodotto complesso da costruire Costruisce e assembla le parti del Il client recupera dal prodotto. Tiene traccia dell’istanza builder concreto il costruita. Fornisce un’interfaccia per prodotto finito recuperare il prodotto finale Ingegneria del software Riccardo Cardin 19 Ingegneria del software Riccardo Cardin 20 BUILDER BUILDER Conseguenze Esempio Facilita le modifiche alla rappresentazione interna di Si vuole ordinare un bicchiere di scotch. È necessario fornire al un prodotto barman alcune informazioni: la marca del whiskey, come deve essere È sufficiente costruire un nuovo builder: NO telescoping! preparato (liscio, on the rocks, allungato) e se lo si desidera doppio. È inoltre possibile scegliere il tipo di bicchiere (piccolo, lungo, a Isola il codice dedicato alla costruzione di un prodotto tulipano). dalla sua rappresentazione Il client non conosce le componenti interne di un prodotto [se fossimo veramente intenditori, anche la marca e la temperatura Encapsulation dell’acqua sarebbero fondamentali...] L’orchestrazione dei processi di costruzione è unica Consente un controllo migliore del processo di costruzione Costruzione step‐by‐step Accentramento logica di validazione Ingegneria del software Riccardo Cardin 21 Ingegneria del software Riccardo Cardin 22 BUILDER BUILDER Implementazione Il builder defisce un’interfaccia per ogni parte che il director può richiedere di costruire Abbastanza generale per la costruizione di prodotti differenti Appending process Nessuna classe astratta comune per i prodotti Differiscono notevolmente fra loro Se simili, valutare l’utilizzo di un Abstract Factory Pattern Fornire metodi vuoti come default I builder concreti ridefiniscono solo i metodi necessari Ingegneria del software mod. A Riccardo Cardin 23 Ingegneria del software Riccardo Cardin 24 BUILDER BUILDER Implementazione Implementazione Java: il builder diventa classe interna del prodotto Java public class OrderOfScotch { // CONTINUA... private String brand; public OrderOfScotch build() { return new OrderOfScotch(this); } private Praparation preparation; // Si puo’ dichiarare enum interna } // public static class Builder // ... private OrderOfScotch() { } // Costruttore privato per il prodotto public static void main(String[] args) { private OrderOfScotch(Builder builder) { // Il client non conosce il processo di costruzione e le classi this.brand = builder._brand; // prodotto e builder sono correttamente accoppiate tra loro. // ... // Non e’ possibile costruire un prodotto se non con il builder. } OrderOfScotch oos = new OrderOfScotch.Builder() public static class Builder { .setBrand(“Brand 1“) private String
Recommended publications
  • Learning Javascript Design Patterns
    Learning JavaScript Design Patterns Addy Osmani Beijing • Cambridge • Farnham • Köln • Sebastopol • Tokyo Learning JavaScript Design Patterns by Addy Osmani Copyright © 2012 Addy Osmani. All rights reserved. Revision History for the : 2012-05-01 Early release revision 1 See http://oreilly.com/catalog/errata.csp?isbn=9781449331818 for release details. ISBN: 978-1-449-33181-8 1335906805 Table of Contents Preface ..................................................................... ix 1. Introduction ........................................................... 1 2. What is a Pattern? ...................................................... 3 We already use patterns everyday 4 3. 'Pattern'-ity Testing, Proto-Patterns & The Rule Of Three ...................... 7 4. The Structure Of A Design Pattern ......................................... 9 5. Writing Design Patterns ................................................. 11 6. Anti-Patterns ......................................................... 13 7. Categories Of Design Pattern ............................................ 15 Creational Design Patterns 15 Structural Design Patterns 16 Behavioral Design Patterns 16 8. Design Pattern Categorization ........................................... 17 A brief note on classes 17 9. JavaScript Design Patterns .............................................. 21 The Creational Pattern 22 The Constructor Pattern 23 Basic Constructors 23 Constructors With Prototypes 24 The Singleton Pattern 24 The Module Pattern 27 iii Modules 27 Object Literals 27 The Module Pattern
    [Show full text]
  • Course Title
    "Charting the Course ... ... to Your Success!" JavaScript Advanced Course Summary Description This course will review the basics of JavaScript and provide instruction on advanced topics such as advanced features of JavaScript functions, Object-Oriented programming in JavaScript (Inheritance, encapsulation) with prototypes, using closures, understanding JavaScript promises and advanced best practices. Objectives At the end of this course, students will be able to: Review Learn function expressions/function declarations/immediately executable functions Use JavaScript objects to implement Inheritance and encapsulation Understand JavaScript closures Learn JavaScript promises Discuss how to best use the advanced topics in this course in your JavaScript projects. Topics Basics Review Object-Oriented Programming Function Expressions Error Handling And Debugging Advanced Techniques Audience This course is intended for JavaScript programmers Prerequisites JavaScript introduction Duration Two days Due to the nature of this material, this document refers to numerous hardware and software products by their trade names. References to other companies and their products are for informational purposes only, and all trademarks are the properties of their respective companies. It is not the intent of ProTech Professional Technical Services, Inc. to use any of these names generically "Charting the Course ... ... to Your Success!" JavaScript Advanced Course Outline I. Basics Review IV. Error Handling And Debugging A. Browser Error Reporting II. Object-Oriented Programming B. Internet Explorer A. Understanding Objects C. Firefox B. Types of Properties D. Chrome C. Defining Multiple Properties E. Error Handling D. Reading Property Attributes F. The try-catch Statement E. Object Creation G. Throwing Errors F. The Factory Pattern H. The error Event G. The Constructor Pattern I.
    [Show full text]
  • Business Object Life Cycle Pattern
    PATTERNS FOR ENTERPRISE APPLICATION DESIGN AND DEVELOPMENT by Ruslan Rubis A Dissertation Submitted to the Faculty of The College of Engineering and Computer Science In Partial Fulfillment of the Requirements for the Degree of Doctor of Philosophy Florida Atlantic University Boca Raton, FL December 2017 Copyright by Ruslan Rubis 2017 ii ACKNOWLEDGEMENTS I would like to thank from the bottom of my heart my advisor, Dr. Ionut Cardei, for his persistent guidance, patience and countless advice. Without his continuous support and encouragement this project would not have been possible. I would also like to express my deepest gratitude to my committee members, Dr. Mihaela Cardei, Dr. Eduardo B. Fernandez, and Dr. Daniel Raviv. Your continuous feedback, knowledge sharing, and advice has been invaluable and immensely appreciated. iv ABSTRACT Author: Ruslan Rubis Title: Patterns for Enterprise Application Design and Development Institution: Florida Atlantic University Dissertation Advisor: Ionut Cardei, Ph.D. Degree: Doctor of Philosophy Year: 2017 Designing and developing enterprise applications is a complex and resource intensive process, as it often must address thousands of requirements. At the same time, the software architecture of most enterprise applications at their core have many features and structures in common. Designers from different teams do not normally share design elements because of the competitive and proprietary nature of development, and enterprise applications design and development teams end up re-inventing the wheel when tackling a new product. My objective is to formulate new design patterns for enterprise application architectures that assist software architects with reusable solutions to improve design quality and productivity. I achieve this by presenting seven patterns, each providing a solution to a specific challenge or a problem that is common to many enterprise applications.
    [Show full text]
  • Rationales and Approaches for Automated Testing of Javascript and Standard ML
    UPTEC IT 14 002 Examensarbete 30 hp Februari 2014 Rationales and Approaches for Automated Testing of JavaScript and Standard ML Emil Wall Abstract Rationales and Approaches for Automated Testing of JavaScript and Standard ML Emil Wall Teknisk- naturvetenskaplig fakultet UTH-enheten The ever increasing complexity of web applications has brought new demands on automated testing of JavaScript, requiring test-driven development to achieve Besöksadress: maintainable code. A contrasting area is testing of Standard ML, another functional Ångströmlaboratoriet Lägerhyddsvägen 1 language but with important differences. Hus 4, Plan 0 The aim of this thesis is to highlight the main problems with testing behaviour of Postadress: applications written in these two programming languages, and how these problems Box 536 751 21 Uppsala relate to development tools and practises. This has been investigated based on the following research questions: What are the testability issues of client-side JavaScript Telefon: and Standard ML? Which considerations need to be made in order to write stable and 018 – 471 30 03 maintainable tests? How does testing culture affect productivity and quality of Telefax: software? 018 – 471 30 00 Through quantitative interviews, implementation of the DescribeSML testing Hemsida: framework and development with tests in different scenarios, answers to these http://www.teknat.uu.se/student questions have been sought. The dynamic nature of JavaScript makes it more important to test whereas there are limitations on how Standard ML can be tested imposed by its static type system and immutability. The conclusion was drawn that the main issues for testability are dependency management, how to test graphical interfaces, and maintaining separation of concerns.
    [Show full text]
  • Javascript for PHP Developers
    www.it-ebooks.info www.it-ebooks.info JavaScript for PHP Developers Stoyan Stefanov www.it-ebooks.info JavaScript for PHP Developers by Stoyan Stefanov Copyright © 2013 Stoyan Stefanov. All rights reserved. Printed in the United States of America. Published by O’Reilly Media, Inc., 1005 Gravenstein Highway North, Sebastopol, CA 95472. O’Reilly books may be purchased for educational, business, or sales promotional use. Online editions are also available for most titles (http://my.safaribooksonline.com). For more information, contact our corporate/ institutional sales department: 800-998-9938 or [email protected]. Editor: Mary Treseler Indexer: Meghan Jones, WordCo Indexing Production Editor: Kara Ebrahim Cover Designer: Randy Comer Copyeditor: Amanda Kersey Interior Designer: David Futato Proofreader: Jasmine Kwityn Illustrator: Rebecca Demarest April 2013: First Edition Revision History for the First Edition: 2013-04-24: First release See http://oreilly.com/catalog/errata.csp?isbn=9781449320195 for release details. Nutshell Handbook, the Nutshell Handbook logo, and the O’Reilly logo are registered trademarks of O’Reilly Media, Inc. JavaScript for PHP Developers, the image of an eastern gray squirrel, and related trade dress are trademarks of O’Reilly Media, Inc. Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in this book, and O’Reilly Media, Inc., was aware of a trade‐ mark claim, the designations have been printed in caps or initial caps. While every precaution has been taken in the preparation of this book, the publisher and author assume no responsibility for errors or omissions, or for damages resulting from the use of the information contained herein.
    [Show full text]
  • Computer Science and Engineering National Institute of Technology
    Course Curriculum for B. Tech. in Computer Science and Engineering (For students admitted in 2019-20 onwards) National Institute of Technology Arunachal Pradesh P.O. -Yupia, Dist.–Papumpare, Arunachal Pradesh, Pin–791112 Phone No: 0360-2284801/2001582 Fax No: 0360-2284972 www.nitap.ac.in 1.0 Semester wise Credit point distribution Credit Point Sl. No. Year ODD EVEN 1 First 18.5 20.5 2 Second 23 19 3 Third 21 21 4 Fourth 19 18 77.5 82.5 Total Credit Point 160 1.1 Subject Category wise Credit point Distribution Sem- Sem- Sem- Sem- Sem- Sem- Sem- Sem- Total Course Category I II III IV V VI VII VIII Credit Point Core (Basic Science) 10 7 8 -- 4 -- -- -- 24 Core (Engineering Science) 3 3 -- -- -- -- -- -- 9 Core (Professional) -- 2 9 13 13 16 9 -- 65 Core (Humanities) 3 3 3 3 -- -- -- -- 12 Elective (Professional) -- -- -- -- -- -- 3 -- 3 Open Elective -- -- -- -- -- -- 3 -- 3 Elective (online course) -- -- -- -- -- -- -- 6 6 Lab (Basic Science) 1 1 -- -- -- -- -- -- 0 Lab (Engineering Science) 1.5 2.5 -- -- -- -- -- -- 5 Lab (Humanities) -- -- -- -- -- -- -- -- -- Lab (Professional) -- 2 3 3 3 4 3 -- 18 Internship -- -- -- -- 1 1 1 -- 3 Academic Project -- -- -- -- -- -- -- 10 10 Audit (NSS/NCC) 0 0 -- -- -- -- -- -- 0 Grand Viva -- -- -- -- -- -- -- 2 2 Total Credit Point 18.5 20.5 23 19 21 21 19 18 160 COURSE STRUCTURE 1stSemester Sl. Course Code Course Title L T P C No. 1. CY-101 Engineering Chemistry 3 0 0 3 2. CY-102 Engineering Chemistry lab 0 0 2 1 3. MA-101 Engineering Mathematics I 3 1 0 4 4. ME-101 Engineering Mechanics 3 0 0 3 5.
    [Show full text]
  • Design Patterns for Scalable Javascript Application
    Design Patterns for Scalable JavaScript Application Starting from the Scalable Javascript Application Architecture by Nicholas Zakas [1], this document gets one level deeper, describing the design patterns useful to implement it. The document is intended for a technical audience. Executive Summary The design patterns proposed to implement the Scalable JavaScript Application Architecture fall into two different categories: general Design Patterns from the Gang of Four [2] and other sources, and Design Patterns specific to JavaScript. General Design Patterns • Proxy [3] to impose strict rules on modules ; the sandbox objects act as proxies between user interface modules and the application core Facade • Builder [19] to assemble the Sandbox API from separate parts, each defined by a separate Plug-in [20]. • Facade [4] to provide a single entry point to the methods part of the application core programming interface • Mediator [5] to ensure loose coupling, all communication between user interface modules is channeled through the application core Facade. Through this link, modules send messages to the application core Facade, never to each other. • Observer [6] mechanism provided by the application core Facade lets modules subscribe to events to get notified when these events occur. Each user interface module is an Observer of events broadcast by the application core Facade. • Adapter [7] to translate messages from the objects used in the JavaScript application to the format used for communication with the server, and vice versa Design Patterns
    [Show full text]
  • Institutionen För Datavetenskap Department of Computer and Information Science
    Institutionen för datavetenskap Department of Computer and Information Science Final thesis Designing and implementing an architecture for single-page applications in Javascript and HTML5 by Jesper Petersson LIU-IDA/LITH-EX-A--12/063--SE 2012-11-21 Linköpings universitet Linköpings universitet SE-581 83 Linköping, Sweden 581 83 Linköping Final thesis Designing and implementing an architecture for single-page applications in Javascript and HTML5 by Jesper Petersson LIU-IDA/LITH-EX-A--12/063--SE November 21, 2012 Supervisors: Johannes Edelstam (Valtech), Massimiliano Raciti (LiU) Examiner: Prof. Simin Nadjm-Tehrani Abstract A single-page application is a website that retrieves all needed components in one single page load. The intention is to get a user experience that reminds more of a native appli- cation rather than a website. Single-page applications written in Javascript are becoming more and more popular, but when the size of the applications grows the complexity is also increased. A good architecture or a suitable framework is therefore needed. The thesis begins by analyzing a number of design patterns suitable for applications containing a graphical user interface. Based on a composition of these design patterns, an architecture that targets single-page applications was designed. The architecture was designed to make applications easy to develop, test and maintain. Initial loading time, data synchronization and search engine optimizations were also important aspects that were considered. A framework based on the architecture was implemented, tested and compared against other frameworks available on the market. The framework that was implemented was designed to be modular, supports routing and templates as well as a number of different drivers for communicating with a server-side database.
    [Show full text]
  • Javascript Patterns
    JavaScript Patterns JavaScript Patterns Stoyan Stefanov Beijing • Cambridge • Farnham • Köln • Sebastopol • Tokyo JavaScript Patterns by Stoyan Stefanov Copyright © 2010 Yahoo!, Inc.. All rights reserved. Printed in the United States of America. Published by O’Reilly Media, Inc., 1005 Gravenstein Highway North, Sebastopol, CA 95472. O’Reilly books may be purchased for educational, business, or sales promotional use. Online editions are also available for most titles (http://my.safaribooksonline.com). For more information, contact our corporate/institutional sales department: (800) 998-9938 or [email protected]. Editor: Mary Treseler Indexer: Potomac Indexing, LLC Production Editor: Teresa Elsey Cover Designer: Karen Montgomery Copyeditor: ContentWorks, Inc. Interior Designer: David Futato Proofreader: Teresa Elsey Illustrator: Robert Romano Printing History: September 2010: First Edition. Nutshell Handbook, the Nutshell Handbook logo, and the O’Reilly logo are registered trademarks of O’Reilly Media, Inc. JavaScript Patterns, the image of a European partridge, and related trade dress are trademarks of O’Reilly Media, Inc. Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in this book, and O’Reilly Media, Inc., was aware of a trademark claim, the designations have been printed in caps or initial caps. While every precaution has been taken in the preparation of this book, the publisher and author assume no responsibility for errors or omissions, or for damages resulting from the use of the information con- tained herein. ISBN: 978-0-596-80675-0 [SB] 1284038177 To my girls: Eva, Zlatina, and Nathalie Table of Contents Preface . ................................................................... xiii 1. Introduction .
    [Show full text]
  • Rewriting Javascript Module System
    Rewriting JavaScript Module System [Extended Abstract] Junhee Cho KAIST [email protected] ABSTRACT overrides the other for the symbol $. In substitution for Although JavaScript is one of the major languages used module system, module pattern is recommended. However, for web and other general applications, it does not have since it is not a system on language level, it is hard to guar- a language-level module system. Lack of module system antee properties on module system. causes name conflicts when programmer uses libraries. We Because of the needs for language-level module system, introduce a JavaScript module system with formal seman- ECMAScript Harmony [8], a proposal for the next genera- tics. As an implementation, we also introduce a source- tion of JavaScript, introduces a language-level module sys- to-source transformation from JavaScript with module to tem. Since ECMAScript Harmony is still a work in progress, JavaScript itself for current JavaScript engines to use them. it does not provide complete module semantics, but part of module semantics in high-level description in prose. Kang et al. [9] introduced the formal specification and the imple- Categories and Subject Descriptors mentation of a module system based on the module system D.3.3 [Programming Languages]: Language Constructs in ECMAScript Harmony by the means of desugaring rule and Features from JavaScript with module to λJS [10], a core-calculus of JavaScript. Unfortunately, due to the innate limitations of Keywords λJS , the module system introduced is impractical. First of all, desugared λJS program is very large, and interpretation JavaScript, module system, source-to-source transformation of program involves a large amount of memory usage.
    [Show full text]
  • Modular Javascript JC Franco Blake Stearman Console.Log("Hello World");
    Modular JavaScript JC Franco Blake Stearman console.log("hello world"); JC Franco Blake Stearman @arfncode @cthru jcfranco BlakeStearman The Story of an App We’ve all been here. • Start small <!DOCTYPE html> • Add features <html> • Grow complexity • Add developers <head lang="en"> • Trouble <meta charset="UTF-8"> </head> <body> </body> </html> The Story of an App We’ve all been here. • Start small <!DOCTYPE html> • Add features <html> • Grow complexity <head lang="en"> • Add developers <meta charset="UTF-8"> <title>Stopwatch</title> • Trouble </head> <body> <div> <div id="timer">00:00:00:000</div> </div> </body> </html> The Story of an App We’ve all been here. • Start small <!DOCTYPE html> <html> • Add features <head lang="en"> • Grow complexity <meta charset="UTF-8"> • Add developers <title>Stopwatch</title> • Trouble </head> <body> <div> <div id="timer">00:00:00:000</div> <button type="button" id="start-button">Start</button> <button type="button" id="stop-button">Stop</button> </div> </body> </html> The Story of an App We’ve all been here. <!DOCTYPE html> • Start small <html> • Add features <head lang="en"> <meta charset="UTF-8"> • Grow complexity <title>Stopwatch</title> • Add developers <link rel="stylesheet" href="./css/app.css"> </head> • Trouble <body> <div class="nav"> <a class="hoverHighlight" href="./index.html">&lt; Back</a> | Stopwatch script </div> <div class="display"> <div id="timer">00:00:00:000</div> <button type="button" id="start-button">Start</button> <button type="button" id="stop-button">Stop</button> </div> </body>
    [Show full text]
  • Software Design Patterns for the Web CPEN400A – Building Modern Web Applications (Fall-2019)
    Design Patterns Web Design Patterns Software Design Patterns for the Web CPEN400A – Building Modern Web Applications (Fall-2019) Julien Gascon-Samson, Assistant Professor ÉTS Montréal / University of Quebec Department of Software and IT Engineering Montréal, Canada The design patterns mentioned in this lecture and the code samples are taken or adapted from the book Learning JavaScript Design Patterns,byAddyOsmani Thursday, November 21, 2019 Last compilation: November 21, 2019 Design Patterns Web Design Patterns Design Patterns 2 1 Design Patterns 2 Web Design Patterns Module Revealing Module Singleton Pattern Observer Pattern Publish/Subscribe Pattern Constructor Pattern Prototype Pattern Facade Pattern Mixin Pattern Design Patterns Web Design Patterns Design Patterns: Definition 3 In software engineering, a software design pattern is a gen- eral, reusable solution to a commonly occurring problem within a given context in software design. It is not a finished design that can be transformed directly into source or machine code. It is a description or template for how to solve a problem that can be used in many different situations. Design patterns are formalized best practices that the programmer can use to solve common problems when designing an application or system. Source: https: // fr. wikipedia. org/ wiki/ Patron_ de_ conception 1995: a key book in Software Engineering was published Design Patterns: Elements of Reusable Oriented-Object Software,bythe “Gang of Four” (GoF) (Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides) Proposed
    [Show full text]