DOCSLIB.ORG

Revisiting the Visitor: the ``Just Do It'' Pattern

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Revisiting the Visitor: the ``Just Do It'' Pattern Visitor: Just Do It Didier Verna Introduction C++ Revisiting the Visitor: the “Just Do It” Pattern LISP Step 1: plain LISP Step 2: brute force Step 3: first class Step 4: mapping Didier Verna Step 5: generic map State Step 6: objects [email protected] Step 7: closures http://www.lrde.epita.fr/˜didier step 8: visit schemes Conclusion ACCU 2009 – Friday, April 24th 1/25 Introduction Visitor: Just Do It Necessary literature Didier Verna The GOF Book: Design Patterns, Elements of Introduction Reusable Object-Oriented Software. Gamma, Helm, C++ LISP Johnson, Vlissides. Step 1: plain LISP Step 2: brute force The POSA Book: Pattern-Oriented Software Step 3: first class Step 4: mapping Architecture. Buschmann, Meunier, Rohnert, Step 5: generic map Sommerlad, Stal. State Step 6: objects Step 7: closures step 8: visit schemes What is a software design pattern ? Conclusion I Context (POSA) I Problem I Solution I Consequences (GOF) 2/25 A constatation Visitor: Just Do It Peter Norvig (Object World, 1996) Didier Verna About the GOF book: Introduction C++ 16 of 23 patterns are either invisible or simpler LISP [...] in Dylan or Lisp Step 1: plain LISP Step 2: brute force Step 3: first class Step 4: mapping Step 5: generic map Peter Norvig is right, so State I is the GOF book (70%) wrong ? Step 6: objects Step 7: closures I are patterns (70%) useless ? step 8: visit schemes Conclusion 3/25 Some clues from the GOF book itself Visitor: Just Do It Didier Verna Although design patterns describe object-oriented designs, they are based on Introduction practical solutions that have been implemented in C++ mainstream object-oriented programming LISP Step 1: plain LISP languages [. ] Step 2: brute force Step 3: first class Step 4: mapping Step 5: generic map State Similarly, some of our patterns are supported Step 6: objects Step 7: closures directly by the less common object-oriented step 8: visit schemes languages. Conclusion I That’s what people usually miss 4/25 Patterns descriptions / organizations Visitor: Just Do It GOF: Creational, Structural, Behavioral Didier Verna I usage-oriented Introduction POSA: Architectural, Design, Idioms C++ I abstraction-oriented LISP Step 1: plain LISP Step 2: brute force Idioms according to POSA Step 3: first class Step 4: mapping An idiom is a low-level pattern specific to a Step 5: generic map State programming language. An idiom describes how to Step 6: objects Step 7: closures implement particular aspects of components or the step 8: visit schemes relationships between them using the features of Conclusion the given language. [. ] They address aspects of both design and implementation. I GOF’s design patterns are closer to POSA’s idioms 5/25 The risk: blind pattern application Visitor: Just Do It POSA’s advice: Didier Verna [. ] sometimes, an idiom that is useful for one Introduction programming language does not make sense into C++ another. LISP Step 1: plain LISP Step 2: brute force Step 3: first class Step 4: mapping GOF’s Visitor example: Step 5: generic map State Use the Visitor pattern when [. ] many distinct Step 6: objects Step 7: closures and unrelated operations need to be performed on step 8: visit schemes objects in an object structure, and you want to Conclusion avoid “polluting” their classes with these operations. I But who said operations belong to classes ? 6/25 Table of contents Visitor: Just Do It Didier Verna 1 Visiting in C++ Introduction 2 Visiting in LISP C++ ISP LISP Step 1: plain L Step 1: plain LISP Step 2: brute force visiting Step 2: brute force Step 3: first class Step 3: first class generic functions Step 4: mapping Step 5: generic map Step 4: mapping State Step 6: objects Step 5: generic mapping Step 7: closures step 8: visit schemes Conclusion 3 Visiting with state Step 6: objects Step 7: lexical closures Step 8: dynamic visitation schemes 7/25 Visiting in C++ Visitor: Just Do It Problems: Didier Verna Original hierarchy R/O Introduction C++ Abstract the visiting process away LISP Step 1: plain LISP Step 2: brute force Solution: Step 3: first class Step 4: mapping 1 Equip original hierarchy for visits Step 5: generic map State I A Visitable abstract class Step 6: objects I An accept method in each visitable component Step 7: closures step 8: visit schemes 2 Write independent visitors Conclusion I A Visitor abstract class I A visit method for each visitable component 9/25 Step 1: plain LISP Visitor: Just Do It Classes Didier Verna ( defclass class (superclass1 superclass2 ...) Introduction ((slot :initform <form> :initarg :slot :accessor slot) ...) C++ options ...) LISP ( make−instance ’class :slot <value> ...) Step 1: plain LISP Step 2: brute force Step 3: first class Step 4: mapping Step 5: generic map Generic functions, methods State ( defgeneric func (arg1 arg2 ...) Step 6: objects (:method ((arg1 class1) arg2 ...) Step 7: closures step 8: visit schemes body ) options ...) Conclusion ( defmethod func ((arg1 class1) arg2 ...) body ) I Methods are outside the classes (ordinary function calls) I Multiple dispatch (multi-methods) 11/25 Summary of step 1 Visitor: Just Do It 1 Original hierarchy untouched Didier Verna I Generic function model (outside the classes) Introduction 2 Abstract the visiting process away C++ I Still needs to be done LISP Step 1: plain LISP Step 2: brute force Step 3: first class Step 4: mapping Step 5: generic map State Step 6: objects Step 7: closures step 8: visit schemes Conclusion 12/25 Step 2: brute force visiting Visitor: Just Do It Abstract the visiting process away Didier Verna I OK: the accept generic function Introduction C++ But what’s wrong with this picture ? LISP Step 1: plain LISP obj visitor Step 2: brute force Step 3: first class Step 4: mapping Step 5: generic map State Step 6: objects accept visit Step 7: closures step 8: visit schemes obj visitor Conclusion obj visitor obj visitor ... ... I One indirection too many 13/25 Step 3: first class (generic) functions Visitor: Just Do It Notion of first class / order Didier Verna (Christopher Strachey, 1916–1975) Introduction storage (in variables) C++ aggregation (in structures) LISP Step 1: plain LISP Step 2: brute force argument (to functions) Step 3: first class Step 4: mapping return value (from functions) Step 5: generic map State anonymous manipulation Step 6: objects Step 7: closures dynamic creation step 8: visit schemes Conclusion ... I Generic functions are first class objects in LISP 14/25 The better picture Visitor: Just Do It Didier Verna obj Introduction C++ LISP Step 1: plain LISP accept visitor Step 2: brute force Step 3: first class obj Step 4: mapping obj Step 5: generic map obj State ... Step 6: objects Step 7: closures step 8: visit schemes Conclusion Retrieving function objects in LISP (function func) ;; => #<FUNCTION FUNC> # ’ func ;; => #<FUNCTION FUNC> 15/25 Step 4: mapping Visitor: Just Do It Prominent concept in functional programming Didier Verna I Along with folding (reduction), filtering etc. Introduction Thanks to first class functions C++ I Argument passing LISP Step 1: plain LISP Step 2: brute force Typical mapping example Step 3: first class Step 4: mapping "foo" "bar" "baz" Step 5: generic map ( mapcar # ’ string−upcase ’ ( )) ;; =>("FOO""BAR""BAZ") State Step 6: objects Step 7: closures step 8: visit schemes I “visiting” is a form of structural mapping Conclusion 16/25 Step 5: generic mapping Visitor: Just Do It Having to specialize mapobject is boring Didier Verna I Mapping over lists, vectors, arrays, even class slots Introduction should be written only once C++ LISP The CLOS Meta-Object Protocol (MOP) Step 1: plain LISP Step 2: brute force CLOS itself is object-oriented Step 3: first class Step 4: mapping I The CLOS MOP: a de facto implementation standard Step 5: generic map I The CLOS components (classes etc.) are State Step 6: objects (meta-)objects of some (meta-)classes Step 7: closures step 8: visit schemes We have reflexive (introspective) access to class slots Conclusion I 17/25 Step 6: objects Visitor: Just Do It How about a component counter visitor ? Didier Verna C++: left as an exercise. Introduction C++ LISP: how does that fit with first class functions ? LISP I Global state (yuck !) Step 1: plain LISP I Behavior + state = objects ! Step 2: brute force Step 3: first class Step 4: mapping So we’re back to visitor objects ? Step 5: generic map State There has got to be a better way. Step 6: objects I Step 7: closures step 8: visit schemes Conclusion 19/25 Step 7: lexical closures Visitor: Just Do It Behavior + State without the OO machinery Didier Verna Introduction Typical functional example (with anonymous function) C++ ( defun make−adder ( n ) LISP (lambda (x) (+ n x))) Step 1: plain LISP Step 2: brute force ( funcall ( make−adder 3) 5) ;; =>8 Step 3: first class Step 4: mapping Step 5: generic map State Closures with mutation (impure functional programming) Step 6: objects Step 7: closures ( l e t (( count 0 ) ) step 8: visit schemes ( defun increment () ( incf count ))) Conclusion (increment) ;; =>1 (increment) ;; =>2 ;;... 20/25 Step 8: dynamic visitation schemes Visitor: Just Do It How about a component nesting counter visitor ? Didier Verna C++: left as an exercise. Introduction C++ LISP: modification of the visit process required LISP 1 increment nesting level before visiting an object Step 1: plain LISP 2 actual visit Step 2: brute force Step 3: first class 3 decrement nesting level afterwards Step 4: mapping Step 5: generic map Do we need a dedicated mapobject for that ? State Step 6: objects Step 7: closures No ! We have the MOP’s generic function protocol
Load more

Recommended publications
  • APPLYING MODEL-VIEW-CONTROLLER (MVC) in DESIGN and DEVELOPMENT of INFORMATION SYSTEMS an Example of Smart Assistive Script Breakdown in an E-Business Application
    APPLYING MODEL-VIEW-CONTROLLER (MVC) IN DESIGN AND DEVELOPMENT OF INFORMATION SYSTEMS An Example of Smart Assistive Script Breakdown in an e-Business Application Andreas Holzinger, Karl Heinz Struggl Institute of Information Systems and Computer Media (IICM), TU Graz, Graz, Austria Matjaž Debevc Faculty of Electrical Engineering and Computer Science, University of Maribor, Maribor, Slovenia Keywords: Information Systems, Software Design Patterns, Model-view-controller (MVC), Script Breakdown, Film Production. Abstract: Information systems are supporting professionals in all areas of e-Business. In this paper we concentrate on our experiences in the design and development of information systems for the use in film production processes. Professionals working in this area are neither computer experts, nor interested in spending much time for information systems. Consequently, to provide a useful, useable and enjoyable application the system must be extremely suited to the requirements and demands of those professionals. One of the most important tasks at the beginning of a film production is to break down the movie script into its elements and aspects, and create a solid estimate of production costs based on the resulting breakdown data. Several film production software applications provide interfaces to support this task. However, most attempts suffer from numerous usability deficiencies. As a result, many film producers still use script printouts and textmarkers to highlight script elements, and transfer the data manually into their film management software. This paper presents a novel approach for unobtrusive and efficient script breakdown using a new way of breaking down text into its relevant elements. We demonstrate how the implementation of this interface benefits from employing the Model-View-Controller (MVC) as underlying software design paradigm in terms of both software development confidence and user satisfaction.
    [Show full text]
  • The Role of Model-View Controller in Object Oriented Software Development
    Nepal Journal of Multidisciplinary Research (NJMR) ISSN: 2645-8470 Vol 2, No. 2 June 2019 The Role of Model-View Controller in Object Oriented Software Development Ram Naresh Thakur1 and U S Pandey2 1PhD Scholar, Mewar University, Chittorgarh, Rajasthan, India 2Professor, University of Delhi, India. Corresponding Author Ram Naresh Thakur Email: [email protected] Abstract Object Oriented Software Development (OOSD) is a design technique that is used before the development and design of a software. This design method makes the system appears as a collection of objects to communicate with other objects by passing messages. The Model-View- Controller (MVC) has been inherited from Object-Oriented Programming (OOP) with the integration of Graphical User Interface (GUI) and interactive program execution. The MVC is very useful for developing Interactive and Dynamic Web Applications and iOS. With MVC, developers can trust on design patterns that are widely accepted as solutions for recurring problems. MVC can be used to develop flexible, reusable and modular Software. Applying the MVC design pattern in object-oriented Software development a flexible, reliable, modular and scalable website can be built. So, it’s necessary for every developer to have the knowledge of software development using MVC design pattern. Keywords: OOSD, MVC, OOP, GUI, Dynamic, Web Application, iOS, Design Pattern. 1 Introduction In today’s era, it is very essential to develop and design a working software in an effective and efficient manner. As we know that Object Oriented software development is a designing technique that is used before the development and design of a software. Through this method the system appears as a collection of objects which communicate with other objects by passing messages.
    [Show full text]
  • The Scalable Adapter Design Pattern: Enabling Interoperability Between Educational Software Tools
    The Scalable Adapter Design Pattern: Enabling Interoperability Between Educational Software Tools Andreas Harrer, Catholic University Eichstatt-Ingolstadt,¨ Germany, Niels Pinkwart, Clausthal University of Technology, Germany, Bruce M. McLaren, Carnegie Mellon University, Pittsburgh PA, U.S.A., and DFKI, Saarbrucken,¨ Germany, and Oliver Scheuer, DFKI, Saarbrucken,¨ Germany Abstract For many practical learning scenarios, the integrated use of more than one learning tool is educationally beneficial. In these cases, interoperability between learning tools - getting the pieces to talk to one another in a coherent, well-founded manner - is a crucial requirement that is often hard to achieve. This paper describes a re-usable software design that aims at the integration of independent learning tools into one collaborative learning scenario. We motivate the usefulness and expressiveness of combining several learning tools into one integrated learning experience. Based on this we sketch software design principles that integrate several existing components into a joint technical framework. The feasibility of the approach, which we name the “Scalable Adapter” design pattern, is shown with several implementation examples from different educational technology domains, including Intelligent Tutoring Systems and collaborative learning environments. IEEE keywords: J.m Computer applications, H.5.3 Group and Organization interfaces, K.3.m Computers in Education A short version of this paper appeared in the Proceedings of the Conference on Intelligent Tutoring Systems 2008 1 The Scalable Adapter Design Pattern: Enabling Interoperability Between Educational Software Tools1 I. INTRODUCTION hypothesis and plans. In order to help the student or student In the field of educational technology, there have been groups during the different steps of this inquiry procedure, it numerous attempts in recent years to connect differently makes sense to enable them to have hypotheses, experimenta- targeted learning environments to one another.
    [Show full text]
  • A Study Focused on Web Application Development Using MVC Design Pattern
    International Research Journal of Engineering and Technology (IRJET) e-ISSN: 2395-0056 Volume: 06 Issue: 08 | Aug 2019 www.irjet.net p-ISSN: 2395-0072 A Study Focused on Web Application Development using MVC Design Pattern Ram Naresh Thakur1, Dr. U.S. Pandey2 1Research Scholar, Mewar University, Rajasthan, India 2Professor, University of Delhi ---------------------------------------------------------------------***---------------------------------------------------------------------- Abstract - The Model-View-Controller (MVC) is very useful for developing Interactive and Dynamic Web Applications. It has become the most powerful and dominant Programming Paradigm for developing large scale and Dynamic Web Applications. With MVC, developers can trust on design patterns that are widely accepted as solutions for recurring problems and used to develop flexible, reusable and modular Software. Applying the MVC design pattern to Web Applications is therefore complicated by the fact that current technologies encourage developers to partition the application as early as in the design phase. In this work we have developed a web-based application using MVC framework using Java Web Architecture. Key Words: MVC, Dynamic, Web Application, Programming Paradigm, Developers, Design Phase, Java Web Architecture. 1. INTRODUCTION 1.1 Web Application A Web Application is a distributed application that runs on more than one Computer and communicates through a Network or a Server. Specifically, a Web Application is accessed with a Web Browser as a client and provides the facility to update and manage a program without deploying and installing Application on client Computers. Web Applications are used for Email, Online Retail Purchase/Sales, Online Banking, among others. The advantage of Web Application is that can be access and used by millions of people at the same time [1].
    [Show full text]
  • From Sequential to Parallel Programming with Patterns
    From sequential to parallel programming with patterns Inverted CERN School of Computing 2018 Plácido Fernández [email protected] 07 Mar 2018 Table of Contents Introduction Sequential vs Parallel patterns Patterns Data parallel vs streaming patterns Control patterns (sequential and parallel Streaming parallel patterns Composing parallel patterns Using the patterns Real world use case GrPPI with NUMA Conclusions Acknowledgements and references 07 Mar 2018 3 Table of Contents Introduction Sequential vs Parallel patterns Patterns Data parallel vs streaming patterns Control patterns (sequential and parallel Streaming parallel patterns Composing parallel patterns Using the patterns Real world use case GrPPI with NUMA Conclusions Acknowledgements and references 07 Mar 2018 4 Source: Herb Sutter in Dr. Dobb’s Journal Parallel hardware history I Before ~2005, processor manufacturers increased clock speed. I Then we hit the power and memory wall, which limits the frequency at which processors can run (without melting). I Manufacturers response was to continue improving their chips performance by adding more parallelism. To fully exploit modern processors capabilities, programmers need to put effort into the source code. 07 Mar 2018 6 Parallel Hardware Processors are naturally parallel: Programmers have plenty of options: I Caches I Multi-threading I Different processing units (floating I SIMD / Vectorization (Single point, arithmetic logic...) Instruction Multiple Data) I Integrated GPU I Heterogeneous hardware 07 Mar 2018 7 Source: top500.org Source: Intel Source: CERN Parallel hardware Xeon Xeon 5100 Xeon 5500 Sandy Bridge Haswell Broadwell Skylake Year 2005 2006 2009 2012 2015 2016 2017 Cores 1 2 4 8 18 24 28 Threads 2 2 8 16 36 48 56 SIMD Width 128 128 128 256 256 256 512 Figure: Intel Xeon processors evolution 0Source: ark.intel.com 07 Mar 2018 11 Parallel considerations When designing parallel algorithms where are interested in speedup.
    [Show full text]
  • A Pattern Language for Designing Application-Level Communication Protocols and the Improvement of Computer Science Education Through Cloud Computing
    Utah State University DigitalCommons@USU All Graduate Theses and Dissertations Graduate Studies 5-2017 A Pattern Language for Designing Application-Level Communication Protocols and the Improvement of Computer Science Education through Cloud Computing Jorge Edison Lascano Utah State University Follow this and additional works at: https://digitalcommons.usu.edu/etd Part of the Computer Sciences Commons Recommended Citation Lascano, Jorge Edison, "A Pattern Language for Designing Application-Level Communication Protocols and the Improvement of Computer Science Education through Cloud Computing" (2017). All Graduate Theses and Dissertations. 6547. https://digitalcommons.usu.edu/etd/6547 This Dissertation is brought to you for free and open access by the Graduate Studies at DigitalCommons@USU. It has been accepted for inclusion in All Graduate Theses and Dissertations by an authorized administrator of DigitalCommons@USU. For more information, please contact [email protected]. A PATTERN LANGUAGE FOR DESIGNING APPLICATION-LEVEL COMMUNICATION PROTOCOLS AND THE IMPROVEMENT OF COMPUTER SCIENCE EDUCATION THROUGH CLOUD COMPUTING by Jorge Edison Lascano A dissertation submitted in partial fulfillment of the requirements for the degree of DOCTOR OF PHILOSOPHY in Computer Science Approved: ______________________ ____________________ Stephen W. Clyde, Ph.D. Curtis Dyreson, Ph.D. Major Professor Committee Member ______________________ ____________________ Haitao Wang, Ph.D. Young-Woo Kwon, Ph.D. Committee Member Committee Member ______________________ ____________________ Luis Gordillo, Ph.D. Mark R. McLellan, Ph.D. Committee Member Vice President for Research and Dean of the School of Graduate Studies UTAH STATE UNIVERSITY Logan, Utah 2017 ii Copyright © Jorge Edison Lascano 2017 All Rights Reserved iii ABSTRACT A Pattern Language for Designing Application-Level Communication Protocols and the Improvement of Computer Science Education through Cloud Computing by Jorge Edison Lascano, Doctor of Philosophy Utah State University, 2017 Major Professor: Stephen W.
    [Show full text]
  • Application Design Patterns Catalogue
    Design Patterns Catalogue AUTOSAR Release 4.2.2 Document Title Design Patterns Catalogue Document Owner AUTOSAR Document Responsibility AUTOSAR Document Identification No 672 Document Classification Auxiliary Document Status Final Part of AUTOSAR Release 4.2.2 Document Change History Release Changed by Description • reconsideration of signal definitions and tailored AUTOSAR pattern for smart actuators and actuators with no 4.2.2 Release feedback loop Management • specification items added • minor changes • First Release of document. Patterns covered: AUTOSAR – Sensor and Actuator Pattern 4.2.1 Release – Arbitration of Several Set-point Requester Management Pattern • Previously published as part of EXP_AIPowertrain 1 of 46 Document ID 672: AUTOSAR_TR_AIDesignPatternsCatalogue — AUTOSAR CONFIDENTIAL — Design Patterns Catalogue AUTOSAR Release 4.2.2 Disclaimer This specification and the material contained in it, as released by AUTOSAR, is for the purpose of information only. AUTOSAR and the companies that have contributed to it shall not be liable for any use of the specification. The material contained in this specification is protected by copyright and other types of Intellectual Property Rights. The commercial exploitation of the material contained in this specification requires a license to such Intellectual Property Rights. This specification may be utilized or reproduced without any modification, in any form or by any means, for informational purposes only. For any other purpose, no part of the specification may be utilized or reproduced, in any form or by any means, without permission in writing from the publisher. The AUTOSAR specifications have been developed for automotive applications only. They have neither been developed, nor tested for non-automotive applications.
    [Show full text]
  • Design Patterns Past and Future
    Proceedings of Informing Science & IT Education Conference (InSITE) 2011 Design Patterns Past and Future Aleksandar Bulajic Metropolitan University, Belgrade, Serbia [email protected]; [email protected] Abstract A very important part of the software development process is service or component internal de- sign and implementation. Design Patterns (Gamma et al., 1995) provide list of the common pat- terns used in the object-oriented software design process. The primary goal of the Design Patterns is to reuse good practice in the design of new developed components or applications. Another important reason of using Design Patterns is improving common application design understand- ing and reducing communication overhead by reusing the same generic names for implemented solution. Patterns are designed to capture best practice in a specific domain. A pattern is supposed to present a problem and a solution that is supported by an example. It is always worth to listen to an expert advice, but keep in mind that common sense should decide about particular implemen- tation, even in case when are used already proven Design Patterns. Critical view and frequent and well designed testing would give an answer about design validity and a quality. Design Patterns are templates and cannot be blindly copied. Each design pattern records design idea and shall be adapted to particular implementation. Using time to research and analyze existing solutions is recommendation supported by large number of experts and authorities and fits very well in the pattern basic philosophy; reuse solution that you know has been successfully implemented in the past. Sections 2 and 3 are dedicated to the Design Patterns history and theory as well as literature sur- vey.
    [Show full text]
  • Elephants, Patterns, and Heuristics
    Elephants, Patterns, and Heuristics REBECCA WIRFS-BROCK, Wirfs-Brock Associates CHRISTIAN KOHLS, TH Köln Capturing the wholeness of design solutions in order to effectively communicate them to others can be challenging. We posit that patterns are observable phenomena of design solutions. To represent these phenomena, a pattern author needs to generalize and omit information. Experienced designers are able to unfold the essence of the pattern and generate design solutions based on the information that they do find in a pattern description. Not surprisingly, their personal design heuristics play a central role in this. As they create a design solution, they also liberally apply their pre-existing design know-how and heuristics. But novice designers may have more difficulty. As this folding and unfolding of information and knowledge seems to be quite an abstract concept, we have chosen to make our point by discussing elephants. Like patterns, elephants are an observable phenomenon, a pattern in nature. Many different descriptions, representations, and accounts of elephants exist. Many people claim to know what elephants are. Yet they actually have little or limited knowledge of them. This analogy helps to understand how at the same time we both know and do not know what a thing is. Categories and Subject Descriptors: • Software and its engineering~Software design engineering • Software and its engineering~Software design tradeoffs • Software and its engineering~Design patterns ACM Reference Format: Wirfs-Brock, R. and Kohls, C. Elephants, Patterns, and Heuristics 26th Conference on Pattern Languages of Programming (PLoP), PLoP 2019, Oct 7-10 2019, 15 pages. 1. INTRODUCTION Patterns are recurrent phenomena that can be found in all design domains.
    [Show full text]
  • Object Oriented Paradigm/Programming
    an object is an instantiation from a class, e.g., you have a pet cat, who's Object Oriented Paradigm name is Garfield, then Garfield is a object (of the class cat) to invoke an method, simply do obj.method( ) or obj->method( ), the Ming- Hwa Wang, Ph.D. former is object reference syntax, and the latter is pointer syntax Department of Computer Engineering Santa Clara University Relationships a-kind-of relationship: a subclass inherits and adds more attributes Object Oriented Paradigm/Programming (OOP) and/or methods from its super class to become somewhat "specialized" similar to Lego, which kids build new toys from assembling the existing is-a relationship: an object of a subclass is an object of its super class construction blocks of different shapes part-of relationship: OOP - doing programs by reusing (composing/inheriting) objects has-a relationship: (instantiated from classes) as much as possible, and only writing code when no exiting objects can be applied Reusability inheritance Two Fundamental Principles for OOP a sub/child/derived/extended class can inherit all properties from its generalization or reusability: the classes designed should target to super/parent/base/original class, with or without reusability, i.e., it should very generic and can be applied to lots of modification/override or addition situations/applications without much efforts; reusability comes from single inheritance and multiple inheritance (watch out naming inheritance and/or composition conflicts) encapsulation or information hiding: we can hide detailed or composition implementation specific information away from the users/programmers, so changing implementation using the same interfaces will not need Abstract or Virtual Classes modifying the application code only used as a super class for other classes, only specified but not fully defined, and can't be instantiated OOP Language vs.
    [Show full text]
  • Software Design Pattern Using : Algorithmic Skeleton Approach S
    International Journal of Computer Network and Security (IJCNS) Vol. 3 No. 1 ISSN : 0975-8283 Software Design Pattern Using : Algorithmic Skeleton Approach S. Sarika Lecturer,Department of Computer Sciene and Engineering Sathyabama University, Chennai-119. [email protected] Abstract - In software engineering, a design pattern is a general reusable solution to a commonly occurring problem in software design. A design pattern is not a finished design that can be transformed directly into code. It is a description or template for how to solve a problem that can be used in many different situations. Object-oriented design patterns typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved. Many patterns imply object-orientation or more generally mutable state, and so may not be as applicable in functional programming languages, in which data is immutable Fig 1. Primary design pattern or treated as such..Not all software patterns are design patterns. For instance, algorithms solve 1.1Attributes related to design : computational problems rather than software design Expandability : The degree to which the design of a problems.In this paper we try to focous the system can be extended. algorithimic pattern for good software design. Simplicity : The degree to which the design of a Key words - Software Design, Design Patterns, system can be understood easily. Software esuability,Alogrithmic pattern. Reusability : The degree to which a piece of design can be reused in another design. 1. INTRODUCTION Many studies in the literature (including some by 1.2 Attributes related to implementation: these authors) have for premise that design patterns Learn ability : The degree to which the code source of improve the quality of object-oriented software systems, a system is easy to learn.
    [Show full text]
  • DAO Dispatcher Pattern: a Robust Design of the Data Access Layer
    PATTERNS 2013 : The FIfth International Conferences on Pervasive Patterns and Applications DAO Dispatcher Pattern: A Robust Design of the Data Access Layer Pavel Micka Zdenek Kouba Faculty of Electrical Engineering Faculty of Electrical Engineering Czech Technical University in Prague Czech Technical University in Prague Technicka 2, Prague, Czech Republic Technicka 2, Prague, Czech Republic [email protected] [email protected] Abstract—Designing modern software has to respect the nec- Such frameworks help to separate the principal concern of essary requirement of easy maintainability of the software in business objects behavior (business logic) from the infrastruc- the future. The structure of the developed software must be tural concern of how business object’s data is retrieved/stored logical and easy to comprehend. This is why software designers from/to the database and make business objects free from this tend to reusing well-established software design patterns. This infrastructural aspect by delegating it to specialized data access paper deals with a novel design pattern aimed at accessing data objects (DAO). Thus, DAOs intermediate information ex- typically stored in a database. Data access is a cornerstone of all modern enterprise computer systems. Hence, it is crucial to change between business objects and the database. To facilitate design it with many aspects in mind – testability, reusability, the replacement of the particular mapping technology and to replaceability and many others. Not respecting these principles encapsulate database queries, data access objects layer pattern may cause defective architecture of the upper layer of the product, was devised. There are many possible implementations that or even make it impossible to deliver the product in time and/or differ mainly in their reusability, testability, architecture/design in required quality.
    [Show full text]