DOCSLIB.ORG

A Refactoring Architecture for Measuring and Identifying Spots of Design Patterns Insertion in Source Code

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
A Refactoring Architecture for Measuring and Identifying Spots of Design Patterns Insertion in Source Code A Refactoring Architecture for Measuring and Identifying Spots of Design Patterns Insertion in Source Code Luan Bukowitz Beluzzo, Simone Nasser Matos and Thyago Henrique Pacher UTFPR, Ponta Grossa, Parana, Brazil Keywords: Software Architecture, Refactoring, Design Patterns. Abstract: This work presents an architecture for detecting insertion spots of design patterns in an object-oriented source code. The proposed architecture contains a Service that implements Detection Methods (DMS) present in the literature such as identification of precursors, prolog rules and facts, among others. The DMS notifies the Metrics Service (MS) which patterns can be used. The evaluation of the application of the patterns undertaken by the MS is performed by means of quality metrics such as maintainability, flexibility, and so forth. The MS notifies the Client App (CA) of the advantages and disadvantages of using the eligible patterns. The CA interacts with the user to retrieve decisions about which changes to perform in source code according to the design pattern real benefit and notifies the Applier Service (AS), that applies the patterns in the source code. The difference between the proposed architecture and the literature is that it allows a thorough interaction with the user and it creates an extendable environment to cover several pattern detection/insertion methods. The architecture allows automated support to users engaged in the refactoring process based on design patterns. 1 INTRODUCTION This work proposes an architecture aimed to pro- vide a structure that covers methods in the literature Refactoring processes correct bad smells or code that that identify spots to insert design patterns in source is poorly written. These processes are aimed to pro- code, also, some other methods that apply these pat- vide a good internal structure for a software project, terns in a given project. Besides detecting and inser- to remove duplicated code, find meaningful names for ting patterns in source code, this architecture will also methods and classes, restructure class hierarchies and be responsible for the evaluations of the possible re- others (Fowler and Beck, 1999). Some quality requi- factorings and to promote interactions with the user, rements such as performance, maintainability, loose providing feedbacks and relying on his/her decisions coupling, high cohesion and reusability can be impro- to actually execute the proposed procedures. ved in a software project through refactoring (Fowler and Beck, 1999; Mens and Tourwe,´ 2004). Design patterns may be attached to refactoring 2 BACKGROUND WORKS processes improving code flexibility, these patterns are highly recommended during software natural evo- In order to extend the reader’s perception concerning lution (Cinneide, 2000). The benefits of applying methods that to introduce design patterns in source these patterns are widely known, being present in code, the following descriptions present a deeper un- works that detect them, like the ones of Chatzigeor- derstanding of some methods of the literature. giou et. al (Chatzigeorgiou et al., 2006) and Li et. Some works were analyzed during the develop- al (Li et al., 2007), as well as in works that used them ment of the architecture, these were gathered consi- within refactoring processes such as Christopoulou et. dering the past twenty years. Cinneide´ and Nixon al (Christopoulou et al., 2012), Zafeiris et. al (Zafeiris (Cinneide´ and Nixon, 1999) for example, created a et al., 2017) and Zanoni et. al (Zanoni et al., 2015). method to insert a given design pattern based on mi- It has been a more common approach to deal nipatterns and minitransformations. with refactorings to patterns in an automated man- Jeon, Lee and Bae (Jeon et al., 2002) only pro- ner (Christopoulou et al., 2012; Fontana and Zanoni, pose a method to identify spots to insert design pat- 2011; Zafeiris et al., 2017). terns in code through prolog rules and facts; Gaitani 632 Beluzzo, L., Matos, S. and Pacher, T. A Refactoring Architecture for Measuring and Identifying Spots of Design Patterns Insertion in Source Code. DOI: 10.5220/0006868006320639 In Proceedings of the 13th International Conference on Software Technologies (ICSOFT 2018), pages 632-639 ISBN: 978-989-758-320-9 Copyright © 2018 by SCITEPRESS – Science and Technology Publications, Lda. All rights reserved A Refactoring Architecture for Measuring and Identifying Spots of Design Patterns Insertion in Source Code et al. (Gaitani et al., 2015) propose refatorings to- IS in order to request operations from the core. wards a NULL Object design pattern; Christopoulou It is quite noticeable that Figure 1 displays a dupli- et al. (Christopoulou et al., 2012) identify the spots to cated structure in the architecture, the only difference insert a Strategy design pattern, these are spots con- being the identifier of the so called Regions (A and B). taining conditional statements with two or more bran- These regions were built considering the possibility to ches. have absent modules in each region, it also provides Analyzing the works Cinneide´ and Nixon means to distribute the requests from the CAs to the (Cinneide´ and Nixon, 1999), Jeon, Lee and Bae alive members in the core. (Jeon et al., 2002), Gaitani et al. (Gaitani et al., The main idea is that each member of the Region 2015) and Christopoulou et al. (Christopoulou et al., must send messages directly to the IS, this confirms its 2012), it is noticed that features could be added to alive state within the architecture. After that, once the their process, for example, measuring whether the IS receives a request from a given CA, it can redirect insertion brings actual benefits to the project and the call to a specific member for processing. improving interactions with the user. Once the overview of the architecture is well sta- Considering the above mentioned and the other blished, the following sections are in charge of having works of the literature that were studied, this ar- a detailed description of the basic requirements of the chitecture focuses on having more interactions with architecture and afterwards, the internal procedures of the user. It also evaluates the refactoring possibility each module. through software metrics. As last, it provides an en- vironment that covers several refactoring methods of 3.1 Architecture Inputs the literature, which enables the user to use an unique process (having no need to search for other refacto- The input corresponds to a project with a set of ring tools). subsystems, at the lowest level of each subsystem is a set of source files. Within the project, a Project Description file is 3 PROPOSED ARCHITECTURE provided so that the project may be registered. The Project Description has the project id (empty at first The proposed architecture (Figure 1), called Ar- and filled by a procedure of the architecture), pro- chProMe, is composed of tree core modules: Applier ject name (significant name given by the project ow- Service (AS), Metrics Service (MS) and Detection ner) and a source code folder path (src). Methods Service (DMS); an intermediary one called A .prop extension is placed with the project file Intermediary Service (IS) and a Client App (CA). name as a markup extension to be read by the CA, The modules that present this name Service are the which identifies the text file as a Project Description. ones that contain the pattern Service Layer, this pat- The first requirement of the ArchProMe is to know tern presents some functionalities that are made avai- in depth the methods of the literature focused on lable to external users, like a boundary that encapsu- the insertion and detection of patterns insertion spots lates business rules and control the responses to be (Section 2). In case of the creation of a new method, given in each functionality (Fowler, 2002). the architecture must be prepared to be extended. The second requirement for the ArchProMe are a set of metrics, which are used to evaluate the qua- lity of the source code. These metrics provide means to precisely measure a source code through quantita- tive values. They also contribute to measure quality requirements such as: reliability, maintainability and others. After having the base for the refactoring (require- ments) and receiving the input value (project), the ar- chitecture is ready to detect what design patterns can be inserted within the source code. Figure 1: Architecture Overview. 3.2 Client App The CA in turn, promotes the interaction between the users of the architecture (probably software deve- This module presents two main responsibilities: to in- lopers) and is responsible for communicating with the teract with the user and to communicate with the IS. 633 ICSOFT 2018 - 13th International Conference on Software Technologies Among the interactions with the user, it is expected to ceived and to distinguish what architecture member extract data inputs from the user and present some in- should be executed, the IS searches in its queues by formation from the architecture core (patterns eligible type, the Service to be called. for insertion and metrics analysis result). For every kind of request received by the IS, the There are two main interactions available for the due Service is retrieved from its own queue and called user: start process and apply patterns: through an HTTP request for processing.The functio- Start Process: This interaction is triggered by the nalities of this module, as well as the Services called user and it causes the CA to request two operations in the requests are presented as follows: provided by the IS. First the CA is responsible for col- Register Project Request: It inserts the source code lecting project data from the Project Description, after (along with the other data provided) in the database. that, the CA requests the IS to register the project at The project will have its unique id once it is inserted, hand. The source code is compressed and sent with after that, the id is sent as a response.
Load more

Recommended publications
  • Learning Functional Programming in Scala Alvin Alexander
    Learning Functional Programming in Scala Alvin Alexander A logical, step by step approach to learning functional programming Copyright Learning Functional Programming in Scala Copyright 2017 Alvin J. Alexander All rights reserved. No part of this book may be reproduced without prior written permission from the author. Disclaimer: This book is presented solely for educational purposes, and it’s also a work in progress. While best efforts have been used in prepar- ing this book, the author makes no representations or warranties of any kind and assume no liabilities of any kind with respect to the accuracy or completeness of the contents, and specifically disclaim any implied war- ranties of merchantability or fitness of use for a particular purpose. The author shall not be held liable or responsible to any person or entity with respect to any loss or incidental or consequential damages caused, or al- leged to have been caused, directly or indirectly, by the information or programs contained herein. Any use of this information is at your own risk. The advice and strategies contained herein may not be suitable for your situation. Version 0.1.1, published May 15, 2017 (The cover photo was taken on the Dalton Highway in Alaska, some- where between Fairbanks and Prudhoe Bay.) Contents 1 Changelog 1 2 Preface 3 3 Introduction (or, Why I Wrote This Book) 5 4 WhoThisBookisFor 11 5 Goals 15 6 Question Everything 23 7 Rules for Programming in this Book 33 8 One Rule for Reading this Book 39 9 What is “Functional Programming”? 41 10 What is This Lambda
    [Show full text]
  • Design Pattern Interview Questions
    DDEESSIIGGNN PPAATTTTEERRNN -- IINNTTEERRVVIIEEWW QQUUEESSTTIIOONNSS http://www.tutorialspoint.com/design_pattern/design_pattern_interview_questions.htm Copyright © tutorialspoint.com Dear readers, these Design Pattern Interview Questions have been designed specially to get you acquainted with the nature of questions you may encounter during your interview for the subject of Design Pattern. As per my experience good interviewers hardly plan to ask any particular question during your interview, normally questions start with some basic concept of the subject and later they continue based on further discussion and what you answer: What are Design Patterns? Design patterns represent the best practices used by experienced object-oriented software developers. Design patterns are solutions to general problems that software developers faced during software development. These solutions were obtained by trial and error by numerous software developers over quite a substantial period of time. What is Gang of Four GOF? In 1994, four authors Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides published a book titled Design Patterns - Elements of Reusable Object-Oriented Software which initiated the concept of Design Pattern in Software development. These authors are collectively known as Gang of Four GOF. Name types of Design Patterns? Design patterns can be classified in three categories: Creational, Structural and Behavioral patterns. Creational Patterns - These design patterns provide a way to create objects while hiding the creation logic, rather than instantiating objects directly using new opreator. This gives program more flexibility in deciding which objects need to be created for a given use case. Structural Patterns - These design patterns concern class and object composition. Concept of inheritance is used to compose interfaces and define ways to compose objects to obtain new functionalities.
    [Show full text]
  • Five Considerations for Software Developers
    FiveFive ConsiderationsConsiderations forfor SoftwareSoftware DevelopersDevelopers Kevlin Henney [email protected] Presented at Jfokus, Stockholm, 30th January 2008. Kevlin Henney [email protected] [email protected] Curbralan Ltd http://www.curbralan.com Voice: +44 117 942 2990 Fax: +44 870 052 2289 Agenda • Introduction • Consideration 1: Economy • Consideration 2: Visibility • Consideration 3: Spacing • Consideration 4: Symmetry • Consideration 5: Emergence • Outroduction 2 What general qualities in a software architecture help to promote its success? We can of course focus on fitness for purpose, cost of change, organisational acceptance, and so on, but are there broad considerations that can be kept in mind when looking at the structural and developmental side of an architecture? Those involved in software have a lot to keep in mind as they negotiate the worlds inside and outside of their code and the relationship between them. For those interested in improving the state of their art there are many (many) sources of specific recommendations they can use to sharpen their practice. This talk takes a step back from the busy, overpopulated and often overwhelming world of such recommendations to focus on five general considerations that can inform more detailed recommendations and specific decisions. Introduction StructuralSoftwareStructural engineering engineering engineering is is theis the the science science science an and dand art art art of of designingof designing designing and and and making, making, making, with with with economyeconomy and and elegance, elegance, buildings,applications, buildings, bridges, bridges, bridges, frameworks, frameworks, frameworks, and and and other other other similar similar similar structuresstructures so so that that they they can can safely safely resist resist the the forces forces to to which which they they may may be be subjected.
    [Show full text]
  • Declare Property Class Accept Null C
    Declare Property Class Accept Null C Woesome and nontechnical Joshuah planned inveterately and pull-outs his frontiers sourly and daftly. Unquiet Bernard fly-by very instructively while Rick remains ectotrophic and chastened. Sometimes stereoscopic Addie unnaturalizes her acorns proportionally, but unlidded Cat invert heinously or orientalizes rancorously. Even experts are accepted types and positional parameters and references, and assigns to. Use HasValue property to check has value is assigned to nullable type sometimes not Static Nullable class is a. Thank you declare more freely, declare property class accept null c is useful to provide only one dispiriting aspect of. Here we're defining a suggest that extracts all non-nullable property keys from plant type. By disabling cookies to accept all? The car variable inside counter Person class shouldn't be declared type grass and. Use JSDoc type. Any class property name, null safe code token stream of properties and corresponds to accept a class! Why death concept of properties came into C The decline because not two reasons If the members of a class are private then select another class in C. JavaScript Properties of variables with null or undefined. Type cup type as should pickle the null value variable the pastry of the variable to which null. CS31 Intro to C Structs and Pointers. Using the New Null Conditional Operator in C 6 InformIT. Your extra bet is to get themselves the good group of initializing all variables when you disabled them. This class that null values can declare variables declared inside an exception handling is nullable context switches a varargs in.
    [Show full text]
  • Design Patterns
    CSE 403: Software Engineering, Winter 2016 courses.cs.washington.edu/courses/cse403/16wi/ Design Patterns Emina Torlak [email protected] Outline • Overview of design patterns • Creational patterns • Structural patterns • Behavioral patterns 2 introoverview of design patterns What is a design pattern? 4 What is a design pattern? • A standard solution to a common programming problem • a design or implementation structure that achieves a particular purpose • a high-level programming idiom 4 What is a design pattern? • A standard solution to a common programming problem • a design or implementation structure that achieves a particular purpose • a high-level programming idiom • A technique for making code more flexible or efficient • reduce coupling among program components • reduce memory overhead 4 What is a design pattern? • A standard solution to a common programming problem • a design or implementation structure that achieves a particular purpose • a high-level programming idiom • A technique for making code more flexible or efficient • reduce coupling among program components • reduce memory overhead • Shorthand for describing program design • a description of connections among program components • the shape of a heap snapshot or object model 4 Why should you care? • You could come up with these solutions on your own … • But you shouldn't have to! • A design pattern is a known solution to a known problem. 5 Types of design patterns • Creational patterns • how objects are instantiated • Structural patterns • how objects / classes can
    [Show full text]
  • Table of Contents
    Table of Contents ± -—T^jTp^om Object-Oriented to Functional Programming 5 Chajava- an introduction 5 java programming paradigms 6 CO imperative programming CD Real-life imperative example Object-oriented paradigm 7 Objects and classes 7 Encapsulation 7 Abstraction 8 Inheritance 8 Polymorphism 9 Declarative programming 10 Functional programming 11 Working with collections versus working with streams 11 An introduction to Unified Modeling Language 12 Class relations 14 Generalization 15 Realization 15 Dependency 16 Association 16 Aggregation 16 Composition 17 Design patterns and principles 17 Single responsibility principle 18 Open/closed principle 20 Liskov Substitution Principle 20 Interface Segregation Principle 22 Dependency inversion principle 23 Summary 24 Chapter 2: Creational Patterns 27 Singleton pattern 27 Synchronized singletons 29 Synchronized singleton with double-checked locking mechanism 30 Lock-free thread-safe singleton 30 tu * y and lazy loacling 31 i he factory pattern 31 Simple factory pattern 32 Table of Contents Static factory 33 Simple factory with class registration using reflection 34 Simple factory with class registration using Product.newlnstance 35 Factory method pattern 36 Anonymous concrete factory 38 Abstract factory 38 Simple factory versus factory method versus abstract factory 40 Builder pattern 40 Car builder example 41 Simplified builder pattern 43 Anonymous builders with method chaining 44 Prototype pattern 45 Shallow clone versus deep clone Object pool pattern Summary аэоэсБ Chapter 3: Behavioral Patterns
    [Show full text]
  • Pharo by Example
    Portland State University PDXScholar Computer Science Faculty Publications and Computer Science Presentations 2009 Pharo by Example Andrew P. Black Portland State University, [email protected] Stéphane Ducasse Oscar Nierstrasz University of Berne Damien Pollet University of Lille Damien Cassou See next page for additional authors Let us know how access to this document benefits ouy . Follow this and additional works at: http://pdxscholar.library.pdx.edu/compsci_fac Citation Details Black, Andrew, et al. Pharo by example. 2009. This Book is brought to you for free and open access. It has been accepted for inclusion in Computer Science Faculty Publications and Presentations by an authorized administrator of PDXScholar. For more information, please contact [email protected]. Authors Andrew P. Black, Stéphane Ducasse, Oscar Nierstrasz, Damien Pollet, Damien Cassou, and Marcus Denker This book is available at PDXScholar: http://pdxscholar.library.pdx.edu/compsci_fac/108 Pharo by Example Andrew P. Black Stéphane Ducasse Oscar Nierstrasz Damien Pollet with Damien Cassou and Marcus Denker Version of 2009-10-28 ii This book is available as a free download from http://PharoByExample.org. Copyright © 2007, 2008, 2009 by Andrew P. Black, Stéphane Ducasse, Oscar Nierstrasz and Damien Pollet. The contents of this book are protected under Creative Commons Attribution-ShareAlike 3.0 Unported license. You are free: to Share — to copy, distribute and transmit the work to Remix — to adapt the work Under the following conditions: Attribution. You must attribute the work in the manner specified by the author or licensor (but not in any way that suggests that they endorse you or your use of the work).
    [Show full text]
  • Functional Programming Patterns in Scala and Clojure Write Lean Programs for the JVM
    Early Praise for Functional Programming Patterns This book is an absolute gem and should be required reading for anybody looking to transition from OO to FP. It is an extremely well-built safety rope for those crossing the bridge between two very different worlds. Consider this mandatory reading. ➤ Colin Yates, technical team leader at QFI Consulting, LLP This book sticks to the meat and potatoes of what functional programming can do for the object-oriented JVM programmer. The functional patterns are sectioned in the back of the book separate from the functional replacements of the object-oriented patterns, making the book handy reference material. As a Scala programmer, I even picked up some new tricks along the read. ➤ Justin James, developer with Full Stack Apps This book is good for those who have dabbled a bit in Clojure or Scala but are not really comfortable with it; the ideal audience is seasoned OO programmers looking to adopt a functional style, as it gives those programmers a guide for transitioning away from the patterns they are comfortable with. ➤ Rod Hilton, Java developer and PhD candidate at the University of Colorado Functional Programming Patterns in Scala and Clojure Write Lean Programs for the JVM Michael Bevilacqua-Linn The Pragmatic Bookshelf Dallas, Texas • Raleigh, North Carolina 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 The Pragmatic Programmers, LLC was aware of a trademark claim, the designations have been printed in initial capital letters or in all capitals.
    [Show full text]
  • 2010 Midterm Exam Answer All 10 Questions. Answer Essay Questions
    2010 Midterm Exam Answer all 10 questions. Answer essay questions as briefly as possible. The following might be names of patterns: Abstract Class, Abstract Factory, Adapter, Application Controller, Bridge, Builder, Chain of Responsibility, Collaborator, Command, Composite, Decorator, Façade, Factory Method, Flyweight, Interpreter, Iterator, Master- Slave, Mediator, Memento, Null Object, Observer, Prototype, Proxy, Singleton, Specification, State, Strategy, Template Method, Visitor. 1. The purpose of many of the design patterns is to make it easy to change some property of the system. What design pattern would you use to make it easy to change: A. The algorithm that an object uses. B. The class of the object that a method returns. C. The kind and number of objects that react to changes in the object you are designing. D. Adding operations to classes without changing the class. E. How methods in a class behave. 2. What is a code smell? List two code smells. 3. Explain shallow copy and deep copy. 4. Explain control coupling. Give an example. 5. Explain Coupling and Cohesion. 6. According to the Big Ball of Mud paper why should we use piecemeal growth? 7. Explain the command processor pattern. 8. What is the difference between the Proxy and Decorator pattern? 9. Explain how the State pattern works. 10.What are some of the problems cause by using the singleton pattern? 2010 Final Exam Answer all 10 questions. Answer essay questions as briefly as possible. The following might be names of patterns: Abstract Class, Abstract Factory, Active Object Model, Adapter, Application Controller, Bridge, Builder, Chain of Responsibility, Collaborator, Command, Composite, Decorator, Dependency Injection, Dynamic Factory, Façade, Factory Method, Flyweight, Interpreter, Iterator, Master-Slave, Mediator, Memento, Null Object, Observer, Property, Prototype, Proxy, Singleton, Schema, Smart Variables, Specification, State, Strategy, Template Method, Type Object, Visitor.
    [Show full text]
  • Design Patterns
    Design Patterns Design Patterns • A design pattern is a template solution that developers have refined over time to solve a range of recurring problems • Generally object-oriented focus – Name that uniquely identifies the pattern – Problem description that describes situations it can be used – Solution stated as a set of classes and interfaces – Consequences that describes tradeoffs and alternatives 1 Model-View-Controller (MVC) • Archetypical example of a design pattern • Three components – Model : Encapsulates system data and operations on the data – View : Displays data obtained from the model to the user – Controller : Handles events that affect the model or view • Separating user interface from computational elements considered a good design practice Exercise • Consider a program that displays an analog clock; what could correspond to the model, view, and controller? 2 Singleton • Sometimes it is important to have only one instance of a class, e.g., a window manager or ID generation system • The singleton class ensures that only one instance of a class is created Singleton - instance: Singleton - Singleton() - + getInstance() Singleton class Singleton { private static Singleton instance; private Singleton() { ... } public static synchronized Singleton getInstance() { if (instance == null) instance = new Singleton(); return instance; } ... public void doSomething() { ... } } Usage: Singleton.getInstance().doSomething() 3 Adapter Pattern • “Convert the interface of a class into another interface clients expect.” • The adapter pattern lets classes work together that couldn’t otherwise because of incompatible interfaces • Used to provide a new interface to existing legacy components (Interface engineering, reengineering). • Also known as a wrapper • Two adapter patterns: – Class adapter: • Uses multiple inheritance to adapt one interface to another – Object adapter: • Uses single inheritance and delegation • Object adapters are much more frequent.
    [Show full text]
  • Introducing Patterns and Principles
    PART I Introducing Patterns and Principles ⊲⊲ CHApTER 1: The Pattern for Successful Applications ⊲⊲ CHApTER 2: Dissecting the Pattern’s Pattern COPYRIGHTED MATERIAL 292785c01.indd 1 8/23/10 12:00:48 PM 292785c01.indd 2 8/23/10 12:00:48 PM 1 The Pattern for Successful Applications WHAT’S IN THiS CHApTER? ➤➤ An introduction to the Gang of Four Design Patterns ➤➤ An overview of some common design principles and the SOLID design principles ➤➤ A description of Fowlers Enterprise Patterns John Lennon once wrote, “There are no problems, only solutions.” Now, Mr. Lennon never, to my mind, did much in the way of ASP.NET programming; however, what he said is extremely relevant in the realm of software development and probably humanity, but that’s a whole other book. Our job as software developers involves solving problems — ​problems that other devel- opers have had to solve countless times before albeit in various guises. Throughout the lifetime of object-oriented programming, a number of patterns, principles, and best practices have been discovered, named, and catalogued. With knowledge of these patterns and a common solu- tion vocabulary, we can begin to break down complex problems, encapsulate what varies, and develop applications in a uniformed way with tried and trusted solutions. This book is all about introducing you to design patterns, principles, and best practices that you can apply to your ASP.NET applications. By their very nature, patterns and principles are language agnostic, so the knowledge gained in this book can be applied to win forms, WPF and Silverlight applications, as well as other first-class object-oriented languages.
    [Show full text]
  • A Hands-On Guide with Real-World Examples — Vaskaran Sarcar Foreword by Priya Shimanthoor
    Design Patterns in C# A Hands-on Guide with Real-World Examples — Vaskaran Sarcar Foreword by Priya Shimanthoor www.EBooksWorld.ir Design Patterns in C# A Hands-on Guide with Real-World Examples Vaskaran Sarcar Foreword by Priya Shimanthoor www.EBooksWorld.ir Design Patterns in C# Vaskaran Sarcar Whitefield, Bangalore, Karnataka, India ISBN-13 (pbk): 978-1-4842-3639-0 ISBN-13 (electronic): 978-1-4842-3640-6 https://doi.org/10.1007/978-1-4842-3640-6 Library of Congress Control Number: 2018946636 Copyright © 2018 by Vaskaran Sarcar This work is subject to copyright. All rights are reserved by the Publisher, whether the whole or part of the material is concerned, specifically the rights of translation, reprinting, reuse of illustrations, recitation, broadcasting, reproduction on microfilms or in any other physical way, and transmission or information storage and retrieval, electronic adaptation, computer software, or by similar or dissimilar methodology now known or hereafter developed. Trademarked names, logos, and images may appear in this book. Rather than use a trademark symbol with every occurrence of a trademarked name, logo, or image we use the names, logos, and images only in an editorial fashion and to the benefit of the trademark owner, with no intention of infringement of the trademark. The use in this publication of trade names, trademarks, service marks, and similar terms, even if they are not identified as such, is not to be taken as an expression of opinion as to whether or not they are subject to proprietary rights. While the advice and information in this book are believed to be true and accurate at the date of publication, neither the author nor the editors nor the publisher can accept any legal responsibility for any errors or omissions that may be made.
    [Show full text]