DOCSLIB.ORG

Design Patterns

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text

Load more

DESIGN PATTERNS Subject Code: A70530 Regulations: R15 – JNTUH Class: IV Year B.Tech CSE I Semester Department of Computer Science and Engineering BHARAT INSTITUTE OF ENGINEERING AND TECHNOLOGY Ibrahimpatnam - 501 510, Hyderabad DESIGN PATTERNS (A70530) COURSE PLANNER I.COURSE OVERVIEW: The course covers a wide range of software development concepts, abilities, and skills, from analyzing a problem to implementing a solution, also discuss the design patterns in Smalltalk MVC architecture, Express representation invariants, understand their impact on efficiency an66 d ease of implementation, and implement them as runtime assertions. Outlines the differences between structural patterns and behavioral patterns of a model. The course explains about common design vocabulary. This course helps to determine how to be recognizing a design and they can reduce the amount of refactoring, helps to use primitive techniques such as objects, inheritance, and polymorphism. Describes problems that occur in a design how to resolve them and how to evaluate them. II.PRE-REQUISITES: Object Oriented Analysis and Design. Data structures and algorithms. Programming Language (C++ or Java) III.COURSE OBJECTIVE: 1 Demonstration of patterns related to object oriented design. 2 Describe the design patterns that are common in software applications. 3 Analyze a software development problem and express it. 4 Design a module structure to solve a problem, and evaluate alternatives. 5 Implement a module so that it executes efficiently and correctly. IV.COURSE OUTCOMES: S.NO Description Bloom’s Taxonomy Level 1 Construct a design consisting of a collection of modules. Create 2 Exploit well-known design patterns (such as Iterator, Observer, Analyze Factory and Visitor). 3 Distinguish between different categories of design patterns. Analyze 4 Ability to understand and apply common design patterns to Understand incremental/iterative development. 5 Ability to identify appropriate patterns for design of given Remember problem. 6 Design the software using Pattern Oriented Architectures. Create V.HOW PROGRAM OUTCOMES ARE ASSESSED: Program Outcomes Level Proficiency assessed by PO1: Engineering knowledge: Apply the knowledge of 3 Assignment, Exercises mathematics, science, engineering fundamentals, and an engineering specialization to the solution of complex engineering problems. PO2: Problem analysis: Identify, formulate, review research 2 Exercises literature, and analyze complex engineering problems reaching substantiated conclusions using first principles of mathematics, natural sciences, and engineering sciences. PO3: Design/development of solutions: Design solutions for 2 Exercises complex engineering problems and design system components or processes that meet the specified needs with appropriate consideration for the public health and safety, and the cultural, societal, and environmental considerations. PO4: Conduct investigations of complex problems: Use research- -- ………….. based knowledge and research methods including design of experiments, analysis and interpretation of data, and synthesis of the information to provide valid conclusions. PO5: Modern tool usage: Create, select, and apply appropriate 2 Design, Exercises techniques, resources, and modern engineering and IT tools including prediction and modeling to complex engineering activities with an understanding of the limitations. PO6: The engineer and society: Apply reasoning informed by the -- ………….. contextual knowledge to assess societal, health, safety, legal and cultural issues and the consequent responsibilities relevant to the professional engineering practice. PO7: Environment and sustainability: Understand the impact of 1 Assignment, Exercises the professional engineering solutions in societal and environmental contexts, and demonstrate the knowledge of, and need for sustainable development. PO8: Ethics: Apply ethical principles and commit to professional 1 Seminars, Discussions ethics and responsibilities and norms of the engineering practice. PO9: Individual and team work: Function effectively as an 1 Workshop individual, and as a member or leader in diverse teams, and in multidisciplinary teams. PO10: Communication: Communicate effectively on complex 1 Seminars, Paper engineering activities with the engineering community and presentations with society at large, such as, being able to comprehend and write effective reports and design documentation, make effective presentations, and give and receive clear instructions. PO11: Project management and finance: Demonstrate knowledge 1 Design Exercises, and understanding of the engineering and management Discussions principles and apply these to one’s own work, as a member and leader in a team, to manage projects and in multidisciplinary environments. PO12: Life-long learning: Recognize the need for, and have the 1 Exams, Discussions preparation and ability to engage in independent and life-long learning in the broadest context of technological change. VI.HOW PROGRAM SPECIFIC OUTCOMES ARE ASSESSED: PROGRAM SPECIFIC OUTCOMES Level Proficiency assessed by PSO1: To use mathematical methodologies to crack problem using 2 Lectures, suitable mathematical analysis, data structure and suitable Assignments algorithm. PSO2: The ability to interpret the fundamental concepts and methodology 3 Projects of computer systems. Students can understand the functionality of hardware and software aspects of computer systems. PSO3: The ability to grasp the software development lifecycle and 2 Guest Lectures methodologies of software systems. Possess competent skills and knowledge of software design process. Familiarity and practical proficiency with a broad area of programming concepts and provide new ideas and innovations towards research VII.COURSE CONTENTS – AS PER JNTUH SYLLABUS: UNIT – I: What is a Design Pattern?, Design Patterns in Smalltalk MVC, Describing Design Patterns, The Catalogue of Design Patterns, Organizing The Cato log, How Design Patterns solve Design Problems, How to Select a Design pattern, How to Use a Design Pattern. .UNIT – II A Case Study: Designing a Document Editor, Design Problems , Document Structure, Formatting , Embellishing the User Interface, Supporting Multiple Look-and-Feel Standards, Supporting Multiple Window Systems, User Operations Spelling Checking and Hyphenation, Summary, Creational Patterns, Abstract Factory, Builder , Factory Method, Prototype, Singleton, Discussion of Creational Patterns. UNIT – III: Structural Pattern Part-I, Adapter, Bridge, Composite. Structural Pattern Part-II, Decorator, Facade, Flyweight, Proxy. UNIT--IV: Behavioral Patterns Part: I, Chain of Responsibility, Command, Interpreter, Iterator. Behavioral Patterns Part: II, Mediator, Memento, Observer, Discussion of Behavioral Patterns. UNIT V: Behavioral Patterns Part: III, State, Strategy, Template Method, Visitor, Discussion of Behavioral Patterns. What to Expect from Design Patterns, A Brief History, The Pattern Community, An Invitation, A Parting Thought. RELEVANT SYLLABUS FOR GATE: NA RELEVANT SYLLABUS FOR IES: NA LESSON PLAN: s o d e o e n o c t r n e n e c r e k i v s r u e o p g t e e e c o f c n v i i e e T e t W n c b L R r e a j e Unit I b L 1 What is a Design Pattern? RecognizeO the 1. importance of design Design 2 1 Design Patterns in Smalltalk MVC and design patterns. Pattern 3 Describing Design Patterns s By 4 The Catalog of Design Patterns Erich 5 The Catalog of Design Patterns Listing contents of Gamma catalog of design 6 Organizing The Catalog patterns. , Pearson 2 How Design Patterns solve Design, 7 Problems Determine object Educati on. 8 How to Select a Design pattern granularity and 2. How to Use a Design Pattern Specify object interfaces. Pattern 9 s in 10 Revision of Unit-1 / Tutorial Class JAVA Unit II Volume 3 A Case Study: Designing a Document -I By 11 Editor Mark 12 Design Problems Grand, Outlines the problems of 13 4 Document Structure Wiley Lexi’s design. 14 Formatting Dream Embellishing the User 15 Interface. Tech. Supporting Multiple Look-and-Feel 16 Standards 1. Summarize command Supporting Multiple Window Systems Design 14 class and subclasses. Pattern User Operations Spelling Checking s By 5 and Hyphenation. Describe interact or 15 class and subclasses. Erich Gamma 16 Summary , 17 Creational Patterns Pearson 19 Factory Method Educati 20 Abstract Factory Lists out the importance 6 of creational patterns. on. 21 Builder 2. 22 Prototype Pattern Reviews the importance 23 Singleton s in 24 Discussion of Creational Patterns of prototype and singleton pattern. JAVA 25 Revision of Unit-2 / Tutorial Class Volume 26 -I By Mark 7 Identify the importance Grand, Unit III of structural patterns. Structural Pattern Part-I Wiley Dream Tech. 27 Adapter 1. 28 Bridge Design 8 29 composite Pattern 30 Mock Test -1 s By 31 Bridge Class Erich 32 9 Structural Pattern Part-II Summarizes the Gamma 33 Decorator implementation issues , 34 Façade when applying the Pearson 35 Flyweight,proxy bridge pattern. Educati 36 Mid1 on. 10 UNIT-IV 2. Patterns 37 Behavioural Patterns Part: I in JAVA 38 Chain of Responsibility Volume -I 39 Command Outlines the importance By Mark of behavioral patterns. Grand, 40 Interpreter Wiley Dream 41 11 Iterator Tech 42 Behavioral Patterns Part: II 43 Mediator 44 12 Memento 45 Observer Use of observer, 46 Discussion of Behavioral Patterns Mediator, Memento in 47 Discussion of Behavioral Patterns behavioral patterns. 48 UNIT V 49 Behavioral Patterns Part: III 1. Design 13 50 State Use of state, strategy in Patterns 51
Recommended publications
  • Ece351 Lab Manual

    Ece351 Lab Manual

    DEREK RAYSIDE & ECE351 STAFF ECE351 LAB MANUAL UNIVERSITYOFWATERLOO 2 derek rayside & ece351 staff Copyright © 2014 Derek Rayside & ECE351 Staff Compiled March 6, 2014 acknowledgements: • Prof Paul Ward suggested that we look into something with vhdl to have synergy with ece327. • Prof Mark Aagaard, as the ece327 instructor, consulted throughout the development of this material. • Prof Patrick Lam generously shared his material from the last offering of ece251. • Zhengfang (Alex) Duanmu & Lingyun (Luke) Li [1b Elec] wrote solutions to most labs in txl. • Jiantong (David) Gao & Rui (Ray) Kong [3b Comp] wrote solutions to the vhdl labs in antlr. • Aman Muthrej and Atulan Zaman [3a Comp] wrote solutions to the vhdl labs in Parboiled. • TA’s Jon Eyolfson, Vajih Montaghami, Alireza Mortezaei, Wenzhu Man, and Mohammed Hassan. • TA Wallace Wu developed the vhdl labs. • High school students Brian Engio and Tianyu Guo drew a number of diagrams for this manual, wrote Javadoc comments for the code, and provided helpful comments on the manual. Licensed under Creative Commons Attribution-ShareAlike (CC BY-SA) version 2.5 or greater. http://creativecommons.org/licenses/by-sa/2.5/ca/ http://creativecommons.org/licenses/by-sa/3.0/ Contents 0 Overview 9 Compiler Concepts: call stack, heap 0.1 How the Labs Fit Together . 9 Programming Concepts: version control, push, pull, merge, SSH keys, IDE, 0.2 Learning Progressions . 11 debugger, objects, pointers 0.3 How this project compares to CS241, the text book, etc. 13 0.4 Student work load . 14 0.5 How this course compares to MIT 6.035 .......... 15 0.6 Where do I learn more? .
  • Design Pattern Interview Questions

    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.
  • University of Vaasa

    University of Vaasa

    UNIVERSITY OF VAASA FACULTY OF TECHNOLOGY DEPARTMENT OF COMPUTER SCIENCE Arvi Lehesvuo A SOFTWARE FRAMEWORK FOR STORING USER WORKSPACES OF DESKTOP APPLICATIONS Master’s thesis in Technology for the degree of Master of Science in Technology submitted for inspection, Vaasa, June 30, 2012. Supervisor Prof. Jouni Lampinen Instructor M.Sc. Pasi Pelkkikangas 1 TABLE OF CONTENTS page ABBREVIATIONS 3 LIST OF FIGURES 4 TIIVISTELMÄ 5 ABSTRACT 6 1. INTRODUCTION 7 1.1. Company Introduction: Wapice Ltd 8 1.2. Professional Background Statement 9 1.3. The Scope of the Research 9 1.4. Research Questions 10 2. RESEARCH METHODOLOGY 12 2.1. Constructive Research Approach 12 2.2. Research Process as Applied in This Research 13 3. THEORY AND BACKGROUND OF THE STUDY 17 3.1. Introduction to the Subject 17 3.2. History of Object Oriented Programming 17 3.3. Most Central Elements in Object Oriented Programming 19 3.4. More Advanced Features of Object Oriented Programming 25 3.5. Software Design Patterns 27 3.6. Graphical User Interface Programming 34 4. DEVELOPING THE SOLUTION 39 4.1. Identifying the Solution Requirements 39 4.2. Designing Basic Structure for the Solution 43 4.3. Building the Solution as an External Software Component 47 4.4. Storing the User Data 48 4.5. Optimizing Construction for C# 51 2 5. EVALUATING PRACTICAL RELEVANCE OF THE DESIGN 54 5.1. Testing Design by applying it to Different GUI Design Models 54 5.2. Analyzing Results of the User Questionnaire 57 6. CONCLUSIONS AND FUTURE 61 6.1. Practical Contribution 62 6.2.
  • A Framework to Support Behavioral Design Pattern Detection from Software Execution Data

    A Framework to Support Behavioral Design Pattern Detection from Software Execution Data

    A Framework to Support Behavioral Design Pattern Detection from Software Execution Data Cong Liu1, Boudewijn van Dongen1, Nour Assy1 and Wil M. P. van der Aalst2;1 1Department of Mathematics and Computer Science, Eindhoven University of Technology, 5600MB Eindhoven, The Netherlands 2Department of Computer Science, RWTH Aachen University, 52056 Aachen, Germany Keywords: Pattern Instance Detection, Behavioral Design Pattern, Software Execution Data, General Framework. Abstract: The detection of design patterns provides useful insights to help understanding not only the code but also the design and architecture of the underlying software system. Most existing design pattern detection approaches and tools rely on source code as input. However, if the source code is not available (e.g., in case of legacy software systems) these approaches are not applicable anymore. During the execution of software, tremendous amounts of data can be recorded. This provides rich information on the runtime behavior analysis of software. This paper presents a general framework to detect behavioral design patterns by analyzing sequences of the method calls and interactions of the objects that are collected in software execution data. To demonstrate the applicability, the framework is instantiated for three well-known behavioral design patterns, i.e., observer, state and strategy patterns. Using the open-source process mining toolkit ProM, we have developed a tool that supports the whole detection process. We applied and validated the framework using software execution data containing around 1000.000 method calls generated from both synthetic and open-source software systems. 1 INTRODUCTION latter specifies how classes and objects interact. Many techniques have been proposed to detect design pat- As a common design practice, design patterns have tern instances.
  • Behavioral Patterns

    Behavioral Patterns

    Behavioral Patterns 101 What are Behavioral Patterns ! " Describe algorithms, assignment of responsibility, and interactions between objects (behavioral relationships) ! " Behavioral class patterns use inheritence to distribute behavior ! " Behavioral object patterns use composition ! " General example: ! " Model-view-controller in UI application ! " Iterating over a collection of objects ! " Comparable interface in Java !" 2003 - 2007 DevelopIntelligence List of Structural Patterns ! " Class scope pattern: ! " Interpreter ! " Template Method ! " Object scope patterns: ! " Chain of Responsibility ! " Command ! " Iterator ! " Mediator ! " Memento ! " Observer ! " State ! " Strategy ! " Visitor !" 2003 - 2007 DevelopIntelligence CoR Pattern Description ! " Intent: Avoid coupling the sender of a request to its receiver by giving more than one object a chance to handle the request. Chain the receiving objects and pass the request along the chain until an object handles it. ! " AKA: Handle/Body ! " Motivation: User Interfaces function as a result of user interactions, known as events. Events can be handled by a component, a container, or the operating system. In the end, the event handling should be decoupled from the component. ! " Applicability: ! " more than one object may handle a request, and the handler isn't known a priori. ! " Want to issue a request to one of several objects without specifying the receiver !" 2003 - 2007 DevelopIntelligence CoR Real World Example ! " The Chain of Responsibility pattern avoids coupling the sender of a request to the receiver, by giving more than one object a chance to handle the request. ! " Mechanical coin sorting banks use the Chain of Responsibility. Rather than having a separate slot for each coin denomination coupled with receptacle for the denomination, a single slot is used. When the coin is dropped, the coin is routed to the appropriate receptacle by the mechanical mechanisms within the bank.
  • Design Patterns (Part 3)

    Design Patterns (Part 3)

    Design patterns (part 3) CSE 331 University of Washington Michael Ernst Outline Introduction to design patterns Creational patterns (constructing objects) Structural patterns (controlling heap layout) ⇒Behavioral patterns (affecting object semantics) Composite pattern Composite permits a client to manipulate either an atomic unit or a collection of units in the same way Good for dealing with part-whole relationships Composite example: Bicycle • Bicycle – Wheel • Skewer • Hub • Spokes • Nipples • Rim • Tape • Tube • Tire – Frame – Drivetrain – ... Methods on components class BicycleComponent { int weight (); float cost (); } class Skewer extends BicycleComponent { float price ; float cost () { return price; } } class Wheel extends BicycleComponent { float assemblyCost ; Skewer skewer ; Hub hub ; ... float cost () { return assemblyCost + skewer.cost() + hub.cost() + ...; } } Composite example: Libraries Library Section (for a given genre) Shelf Volume Page Column Word Letter interface Text { String getText (); } class Page implements Text { String getText () { ... return the concatenation of the column texts ... } } Traversing composites Goal: perform operations on all parts of a composite Representing Java code x = foo * b + c / d; = x + * / foo b c d Abstract syntax tree (AST) for Java code class PlusOp extends Expression { // + operation Expression leftExp ; Expression rightExp ; } class VarRef extends Expression { // variable reference String varname ; } class EqualOp extends Expression { // equality test a==b; Expression lvalue ; //
  • Automatic Generation of Truffle-Based Interpreters for Domain

    Automatic Generation of Truffle-Based Interpreters for Domain

    Automatic generation of Truffle-based interpreters for Domain-Specific Languages Manuel Leduc, Gwendal Jouneaux, Thomas Degueule, Gurvan Le Guernic, Olivier Barais, Benoit Combemale To cite this version: Manuel Leduc, Gwendal Jouneaux, Thomas Degueule, Gurvan Le Guernic, Olivier Barais, et al.. Automatic generation of Truffle-based interpreters for Domain-Specific Languages. The Journal of Object Technology, Chair of Software Engineering, 2020, 19 (2), pp.1-21. 10.5381/jot.2020.19.2.a1. hal-02395867v2 HAL Id: hal-02395867 https://hal.inria.fr/hal-02395867v2 Submitted on 21 Feb 2021 HAL is a multi-disciplinary open access L’archive ouverte pluridisciplinaire HAL, est archive for the deposit and dissemination of sci- destinée au dépôt et à la diffusion de documents entific research documents, whether they are pub- scientifiques de niveau recherche, publiés ou non, lished or not. The documents may come from émanant des établissements d’enseignement et de teaching and research institutions in France or recherche français ou étrangers, des laboratoires abroad, or from public or private research centers. publics ou privés. Journal of Object Technology Published by AITO — Association Internationale pour les Technologies Objets http://www.jot.fm/ Automatic generation of Truffle-based interpreters for Domain-Specific Languages Manuel Leduca Gwendal Jouneauxa Thomas Degueuleb Gurvan Le Guernicc Olivier Baraisa Benoit Combemalead a. Univ. Rennes, Inria, CNRS, IRISA, France b. Univ. Bordeaux, Bordeaux INP, CNRS, LaBRI, UMR5800, F-33400 Talence, France c. DGA MI, Bruz, France d. Univ. Toulouse, IRIT, France Abstract Numerous language workbenches have been proposed over the past decade to ease the definition of Domain-Specific Languages (DSLs).
  • Active Object

    Active Object

    Active Object an Object Behavioral Pattern for Concurrent Programming R. Greg Lavender Douglas C. Schmidt [email protected] [email protected] ISODE Consortium Inc. Department of Computer Science Austin, TX Washington University, St. Louis An earlier version of this paper appeared in a chapter in the book ªPattern Languages of Program Design 2º ISBN 0-201-89527-7, edited by John Vlissides, Jim Coplien, and Norm Kerth published by Addison-Wesley, 1996. : Output : Input Handler Handler : Routing Table : Message Abstract Queue This paper describes the Active Object pattern, which decou- 3: enqueue(msg) ples method execution from method invocation in order to : Output 2: find_route(msg) simplify synchronized access to a shared resource by meth- Handler ods invoked in different threads of control. The Active Object : Message : Input pattern allows one or more independent threads of execution Queue Handler 1: recv(msg) to interleave their access to data modeled as a single ob- ject. A broad class of producer/consumer and reader/writer OUTGOING OUTGOING MESSAGES GATEWAY problems are well-suited to this model of concurrency. This MESSAGES pattern is commonly used in distributed systems requiring INCOMING INCOMING multi-threaded servers. In addition,client applications (such MESSAGES MESSAGES as windowing systems and network browsers), are increas- DST DST ingly employing active objects to simplify concurrent, asyn- SRC SRC chronous network operations. 1 Intent Figure 1: Connection-Oriented Gateway The Active Object pattern decouples method execution from method invocation in order to simplify synchronized access to a shared resource by methods invoked in different threads [2]. Sources and destinationscommunicate with the Gateway of control.
  • Sample Chapter

    Sample Chapter

    SAMPLE CHAPTER C# in Depth by Jon Skeet Chapter 6 Copyright 2008 Manning Publications brief contents PART 1PREPARING FOR THE JOURNEY ......................................1 1 ■ The changing face of C# development 3 2 ■ Core foundations: building on C# 1 32 PART 2C#2: SOLVING THE ISSUES OF C# 1........................... 61 3 ■ Parameterized typing with generics 63 4 ■ Saying nothing with nullable types 112 5 ■ Fast-tracked delegates 137 6 ■ Implementing iterators the easy way 161 7 ■ Concluding C# 2: the final features 183 PART 3C# 3—REVOLUTIONIZING HOW WE CODE ..................205 8 ■ Cutting fluff with a smart compiler 207 9 ■ Lambda expressions and expression trees 230 10 ■ Extension methods 255 11 ■ Query expressions and LINQ to Objects 275 12 ■ LINQ beyond collections 314 13 ■ Elegant code in the new era 352 vii Implementing iterators the easy way This chapter covers ■ Implementing iterators in C# 1 ■ Iterator blocks in C# 2 ■ A simple Range type ■ Iterators as coroutines The iterator pattern is an example of a behavioral pattern—a design pattern that simplifies communication between objects. It’s one of the simplest patterns to understand, and incredibly easy to use. In essence, it allows you to access all the elements in a sequence of items without caring about what kind of sequence it is— an array, a list, a linked list, or none of the above. This can be very effective for building a data pipeline, where an item of data enters the pipeline and goes through a number of different transformations or filters before coming out at the other end. Indeed, this is one of the core patterns of LINQ, as we’ll see in part 3.
  • Java Design Patterns I

    Java Design Patterns I

    Java Design Patterns i Java Design Patterns Java Design Patterns ii Contents 1 Introduction to Design Patterns 1 1.1 Introduction......................................................1 1.2 What are Design Patterns...............................................1 1.3 Why use them.....................................................2 1.4 How to select and use one...............................................2 1.5 Categorization of patterns...............................................3 1.5.1 Creational patterns..............................................3 1.5.2 Structural patterns..............................................3 1.5.3 Behavior patterns...............................................3 2 Adapter Design Pattern 5 2.1 Adapter Pattern....................................................5 2.2 An Adapter to rescue.................................................6 2.3 Solution to the problem................................................7 2.4 Class Adapter..................................................... 11 2.5 When to use Adapter Pattern............................................. 12 2.6 Download the Source Code.............................................. 12 3 Facade Design Pattern 13 3.1 Introduction...................................................... 13 3.2 What is the Facade Pattern.............................................. 13 3.3 Solution to the problem................................................ 14 3.4 Use of the Facade Pattern............................................... 16 3.5 Download the Source Code.............................................
  • Skin Vs. Guts: Introducing Design Patterns in the MIS Curriculum Elizabeth Towell and John Towell Carroll College, Waukesha, WI, USA

    Skin Vs. Guts: Introducing Design Patterns in the MIS Curriculum Elizabeth Towell and John Towell Carroll College, Waukesha, WI, USA

    Journal of Information Technology Education Volume 1 No. 4, 2002 Skin vs. Guts: Introducing Design Patterns in the MIS Curriculum Elizabeth Towell and John Towell Carroll College, Waukesha, WI, USA [email protected] [email protected] Executive Summary Significant evidence suggests that there is increasing demand for information technology oriented stu- dents who have exposure to Object-Oriented (OO) methodologies and who have knowledge of the Uni- fied Modeling Language (UML). Object-oriented development has moved into the mainstream as the value of reusable program modules is becoming more evident. Building blocks such as software com- ponents and application frameworks allow organizations to bring products to market faster and to adapt to changes more quickly. When only one analysis and design course is required, the study of object-oriented analysis and design is often minimal or left out of the Management Information Systems curriculum. This paper argues for an increased emphasis on object-oriented techniques in the introductory Systems Analysis and Design course. Specifically, it provides guidance for faculty who are considering adding object-orientation to a systems analysis and design course where existing content leaves little time for new topics. In particular, the authors recommend the introduction of two successful, generalized design patterns in the context of adaptation of a software development framework. Where time is limited, coverage of such recurring software problems cannot be comprehensive so it is proposed that students explore two design patterns in depth as opposed to a cursory review of more patterns. Students must first learn or review the OO vocabulary including terms such as classes, inheritance, and aggregation so that the ap- propriate term can be used to discuss the UML relationships among the object model components.
  • Table of Contents

    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