DOCSLIB.ORG

Python 3 Patterns, Recipes and Idioms Release 1.0

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Python 3 Patterns, Recipes and Idioms Release 1.0 , Python 3 Patterns, Recipes and Idioms Release 1.0 Bruce Eckel September 27, 2017 Contents 1 Contributors 1 1.1 Thanks To................................................1 2 ToDo List 3 3 The remainder are from context, from the book.5 4 A Note To Readers 7 5 Introduction 9 5.1 A Team Effort..............................................9 5.2 Not an Introductory Book.......................................9 5.3 The License............................................... 10 5.4 The Printed Book............................................ 10 5.5 Translations............................................... 10 5.6 My Motives............................................... 11 6 Teaching Support 13 7 Book Development Rules 15 7.1 Contribute What You Can....................................... 15 7.2 Don’t Get Attached........................................... 15 7.3 Credit.................................................. 16 7.4 Mechanics................................................ 16 7.5 Diagrams................................................ 17 8 Developer Guide 19 8.1 Getting Started: The Easiest Approach............................... 19 8.2 For Windows Users.......................................... 19 8.3 Installing Sphinx............................................ 20 8.4 Getting the Development Branch of the Book............................ 20 8.5 Building the Book........................................... 21 8.6 Building the PDF............................................ 21 8.7 Setting up Mercurial.......................................... 21 8.8 Working with BitBucket and Mercurial............................... 22 8.9 A Simple Overview Of Editing and Merging............................ 23 8.10 Emacs for Editing Restructured Text................................. 23 i 9 Part I: Foundations 25 10 Python for Programmers 27 10.1 Scripting vs. Programming...................................... 27 10.2 Built-In Containers........................................... 28 10.3 Functions................................................ 29 10.4 Strings.................................................. 29 10.5 Classes.................................................. 30 10.6 Useful Techniques........................................... 33 10.7 Further Reading............................................ 33 11 Initialization and Cleanup 35 11.1 Initialization.............................................. 35 11.2 Cleanup................................................. 36 11.3 Further Reading............................................ 37 12 Unit Testing & Test-Driven Development 39 12.1 Write Tests First............................................. 40 12.2 Simple Python Testing......................................... 40 12.3 A Very Simple Framework...................................... 41 12.4 Writing Tests.............................................. 42 12.5 White-Box & Black-Box Tests..................................... 44 12.6 Running tests.............................................. 45 12.7 Automatically Executing Tests.................................... 47 12.8 Exercises................................................. 47 13 Python 3 Language Changes 49 14 Decorators 51 14.1 Decorators vs. the Decorator Pattern................................. 51 14.2 History of Macros........................................... 51 14.3 The Goal of Macros........................................... 52 14.4 What Can You Do With Decorators?................................. 52 14.5 Function Decorators.......................................... 52 14.6 Slightly More Useful.......................................... 54 14.7 Using Functions as Decorators.................................... 54 14.8 Review: Decorators without Arguments.............................. 55 14.9 Decorators with Arguments...................................... 56 14.10 Decorator Functions with Decorator Arguments.......................... 58 14.11 Further Reading............................................ 59 15 Metaprogramming 61 15.1 Basic Metaprogramming....................................... 62 15.2 The Metaclass Hook.......................................... 64 15.3 Example: Self-Registration of Subclasses.............................. 66 15.4 Example: Making a Class “Final”.................................. 67 15.5 Using __init__ vs. __new__ in Metaclasses........................... 68 15.6 Class Methods and Metamethods.................................. 70 15.7 The __prepare__() Metamethod................................. 72 15.8 Module-level __metaclass__ Assignment............................ 73 15.9 Metaclass Conflicts........................................... 73 15.10 Further Reading............................................ 73 16 Generators, Iterators, and Itertools 75 ii 17 Comprehensions 77 17.1 List Comprehensions......................................... 77 17.2 Nested Comprehensions....................................... 78 17.3 Techniques............................................... 79 17.4 A More Complex Example...................................... 80 17.5 Set Comprehensions.......................................... 83 17.6 Dictionary Comprehensions..................................... 83 18 Coroutines, Concurrency & Distributed Systems 85 18.1 The GIL................................................. 85 18.2 Multiprocessing............................................ 86 18.3 Further Reading............................................ 87 19 Jython 89 19.1 Installation............................................... 90 19.2 Scripting................................................. 91 19.3 Interpreter Motivation......................................... 92 19.4 Using Java libraries........................................... 94 19.5 Controlling Java from Jython..................................... 96 19.6 Controlling the Interpreter...................................... 99 19.7 Creating Java classes with Jython.................................. 106 19.8 Summary................................................ 110 19.9 Exercises................................................. 110 20 Part II: Idioms 111 21 Discovering the Details About Your Platform 113 22 A Canonical Form for Command-Line Programs 115 23 Messenger/Data Transfer Object 117 24 Part III: Patterns 119 25 The Pattern Concept 121 25.1 What is a Pattern?........................................... 121 25.2 Classifying Patterns.......................................... 122 25.3 Pattern Taxonomy........................................... 123 25.4 Design Structures............................................ 123 25.5 Design Principles............................................ 124 25.6 Further Reading............................................ 125 26 The Singleton 127 26.1 Exercises................................................. 131 27 Building Application Frameworks 133 27.1 Template Method............................................ 133 27.2 Exercises................................................. 134 28 Fronting for an Implementation 135 28.1 Proxy................................................... 136 28.2 State................................................... 137 29 StateMachine 139 29.1 Table-Driven State Machine...................................... 144 29.2 Tools................................................... 151 iii 29.3 Exercises................................................. 151 30 Decorator: Dynamic Type Selection 153 30.1 Basic Decorator Structure....................................... 154 30.2 A Coffee Example........................................... 154 30.3 Class for Each Combination...................................... 154 30.4 The Decorator Approach....................................... 156 30.5 Compromise.............................................. 158 30.6 Other Considerations......................................... 160 30.7 Further Reading............................................ 161 30.8 Exercises................................................. 161 31 Iterators: Decoupling Algorithms from Containers 163 31.1 Type-Safe Iterators........................................... 163 32 Factory: Encapsulating Object Creation 165 32.1 Simple Factory Method........................................ 165 32.2 Polymorphic Factories......................................... 167 32.3 Abstract Factories........................................... 169 32.4 Exercises................................................. 171 33 Function Objects 173 33.1 Command: Choosing the Operation at Runtime.......................... 173 33.2 Strategy: Choosing the Algorithm at Runtime........................... 174 33.3 Chain of Responsibility........................................ 175 33.4 Exercises................................................. 178 34 Changing the Interface 179 34.1 Adapter................................................. 179 34.2 Façade.................................................. 180 34.3 Exercises................................................. 181 35 Table-Driven Code: Configuration Flexibility 183 35.1 Table-Driven Code Using Anonymous Inner Classes....................... 183 36 Observer 185 36.1 Observing Flowers........................................... 186 37 Multiple Dispatching 197 38 Visitor 201 38.1 Exercises................................................. 202 39 Pattern Refactoring 205 39.1 Simulating the Trash Recycler.................................... 205 39.2 Improving the Design......................................... 208 39.3 A Pattern for Prototyping
Load more

Recommended publications
  • ISO/IEC JTC 1/SC 22/WG4 N 0163 Information Technology
    ISO/IEC JTC 1/SC 22/WG4 N 0163 Date: 2002-05-21 Reference number of document: WDTR 19755 Version 1.1 Committee identification: ISO/IEC JTC 1/SC 22 /WG 4 Secretariat: ANSI Information Technology — Programming languages, their environments and system software interfaces — Object finalization for programming language COBOL Warning This document is an ISO/IEC proposed draft Technical Report. It is not an ISO/IEC International Technical Report. It is distributed for review and comment. It is subject to change without notice and shall not be referred to as an International Technical Report or International Standard. Recipients of this document are invited to submit, with their comments, notification of any relevant patent rights of which they are aware and to provide supporting documentation. Document type: Technical report Document subtype: n/a Document stage: (20) Preparation Document language: E ISO/WDTR 19755 Copyright notice This ISO/IEC document is a working draft and is copyright-protected by ISO/IEC. Requests for permission to reproduce this document for the purpose of selling it should be addressed as shown below or to ISO’s member body in the country of the requester: Copyright manager ISO Central Secretariat 1 rue de Varembé 1211 Geneva 20 Switzerland tel: +41 22 749 0111 fax: +41 22 734 0179 email: [email protected] Reproduction for sales purposes may be subject to royalty payments or a licensing agreement. Violators may be prosecuted. ii © ISO/IEC 2002 – All rights reserved ISO/IEC WDTR 19755 Acknowledgement notice COBOL originated in 1959 as a common business oriented language developed by the Conference on Data Systems Languages (CODASYL).
    [Show full text]
  • Comprehending Adts*
    Comprehending ADTs* Martin Erwig School of EECS Oregon State University [email protected] Abstract We show how to generalize list comprehensions to work on abstract data types. First, we make comprehension notation automatically available for any data type that is specified as a constructor/destructor-pair (bialgebra). Second, we extend comprehensions to enable the use of dif- ferent types in one comprehension and to allow to map between different types. Third, we refine the translation of comprehensions to give a reasonable behavior even for types that do not obey the monad laws, which significantly extends the scope of comprehensions. Keywords: Functional Programming, Comprehension Syntax, Abstract Data Type, Generalized Fold, Monad 1 Introduction Set comprehensions are a well-known and appreciated notation from mathematics: an expression such as fE(x) j x 2 S; P(x)g denotes the set of values given by repeatedly evaluating the expression E for all x taken from the set S for which P(x) yields true. This notation has found its way into functional languages as list comprehensions [3, 17, 18]. Assuming that s denotes a list of numbers, the following Haskell expression computes squares of the odd numbers in s. [ x ∗ x j x s; odd x ] The main difference to the mathematical set comprehensions is the use of lists in the generator and as a result. In general, a comprehension consists of an expression defining the result values and of a list of qualifiers, which are either generators for supplying variable bindings or filters restricting these. Phil Wadler has shown that the comprehension syntax can be used not only for lists and sets, but more generally for arbitrary monads [19].
    [Show full text]
  • Download the Paper (PDF)
    WWW.VIRUSBULLETIN.COM/CONFERENCE 2019 LONDON 2 – 4 October 2019 EXPLORING EMOTET, AN ELABORATE EVERYDAY ENIGMA Luca Nagy Sophos, Hungary [email protected] ABSTRACT Based on Sophos detection numbers, the Emotet trojan is the most widespread malware family in the wild. Since its appearance more than fi ve years ago, it has been – and remains – the most notorious and costly active malware. Emotet owes its reputation to its constant state of evolution and change. The malware’s rapid advancement helps support its highly sophisticated operation. This paper will discuss the reverse engineering of its components, as well as the capabilities and features of Emotet: a detailed overview of its multi-layered operation, starting with the spam lure, the malicious attachments (and their evolution), and the malware executable itself, from its highly sophisticated packer to its C2 server communications. Emotet is well known for its modular architecture, its worm-like propagation, and its highly skilled persistence techniques. The recent versions spread rapidly using multiple methods. Besides its ability to spread by brute forcing using its own password lists, it can also harvest email addresses and email content from victims, then spread through spam. Its diverse module list hides different malicious intentions, such as information stealing, including credentials from web browsers or email clients; spreading capabilities; and delivering other malware including ransomware and other banking trojans. We will dissect the background operations of the payload modules. We will also present statistics from Sophos about Emotet’s global reach. A BRIEF HISTORY OF EMOTET The fi rst Emotet sample we detected popped up on 26 May 2014.
    [Show full text]
  • Stable/Build) • --Port PORT - Set the PORT Number (Default: 8000)
    Pyodide Release 0.18.1 unknown Sep 16, 2021 CONTENTS 1 Using Pyodide 3 1.1 Getting started..............................................3 1.2 Downloading and deploying Pyodide..................................6 1.3 Using Pyodide..............................................7 1.4 Loading packages............................................ 12 1.5 Type translations............................................. 14 1.6 Pyodide Python compatibility...................................... 25 1.7 API Reference.............................................. 26 1.8 Frequently Asked Questions....................................... 50 2 Development 55 2.1 Building from sources.......................................... 55 2.2 Creating a Pyodide package....................................... 57 2.3 How to Contribute............................................ 64 2.4 Testing and benchmarking........................................ 74 2.5 Interactive Debugging.......................................... 76 3 Project 79 3.1 About Pyodide.............................................. 79 3.2 Roadmap................................................. 80 3.3 Code of Conduct............................................. 82 3.4 Governance and Decision-making.................................... 83 3.5 Change Log............................................... 85 3.6 Related Projects............................................. 95 4 Indices and tables 97 Python Module Index 99 Index 101 i ii Pyodide, Release 0.18.1 Python with the scientific stack, compiled to WebAssembly.
    [Show full text]
  • Common Tools for Team Collaboration Problem: Working with a Team (Especially Remotely) Can Be Difficult
    Common Tools for Team Collaboration Problem: Working with a team (especially remotely) can be difficult. ▹ Team members might have a different idea for the project ▹ Two or more team members could end up doing the same work ▹ Or a few team members have nothing to do Solutions: A combination of few tools. ▹ Communication channels ▹ Wikis ▹ Task manager ▹ Version Control ￭ We’ll be going in depth with this one! Important! The tools are only as good as your team uses them. Make sure all of your team members agree on what tools to use, and train them thoroughly! Communication Channels Purpose: Communication channels provide a way to have team members remotely communicate with one another. Ideally, the channel will attempt to emulate, as closely as possible, what communication would be like if all of your team members were in the same office. Wait, why not email? ▹ No voice support ￭ Text alone is not a sufficient form of communication ▹ Too slow, no obvious support for notifications ▹ Lack of flexibility in grouping people Tools: ▹ Discord ￭ discordapp.com ▹ Slack ￭ slack.com ▹ Riot.im ￭ about.riot.im Discord: Originally used for voice-chat for gaming, Discord provides: ▹ Voice & video conferencing ▹ Text communication, separated by channels ▹ File-sharing ▹ Private communications ▹ A mobile, web, and desktop app Slack: A business-oriented text communication that also supports: ▹ Everything Discord does, plus... ▹ Threaded conversations Riot.im: A self-hosted, open-source alternative to Slack Wikis Purpose: Professionally used as a collaborative game design document, a wiki is a synchronized documentation tool that retains a thorough history of changes that occured on each page.
    [Show full text]
  • Why Untyped Nonground Metaprogramming Is Not (Much Of) a Problem
    NORTH- HOLLAND WHY UNTYPED NONGROUND METAPROGRAMMING IS NOT (MUCH OF) A PROBLEM BERN MARTENS* and DANNY DE SCHREYE+ D We study a semantics for untyped, vanilla metaprograms, using the non- ground representation for object level variables. We introduce the notion of language independence, which generalizes range restriction. We show that the vanilla metaprogram associated with a stratified normal oljjctct program is weakly stratified. For language independent, stratified normal object programs, we prove that there is a natural one-to-one correspon- dence between atoms p(tl, . , tr) in the perfect Herbrand model of t,he object program and solve(p(tl, , tT)) atoms in the weakly perfect Her\) and model of the associated vanilla metaprogram. Thus, for this class of programs, the weakly perfect, Herbrand model provides a sensible SC mantics for the metaprogram. We show that this result generalizes to nonlanguage independent programs in the context of an extended Hcr- brand semantics, designed to closely mirror the operational behavior of logic programs. Moreover, we also consider a number of interesting exterl- sions and/or variants of the basic vanilla metainterpreter. For instance. WC demonstrate how our approach provides a sensible semantics for a limit4 form of amalgamation. a “Partly supported by the Belgian National Fund for Scientific Research, partly by ESPRlT BRA COMPULOG II, Contract 6810, and partly by GOA “Non-Standard Applications of Ab- stract Interpretation,” Belgium. TResearch Associate of the Belgian National Fund for Scientific Research Address correspondence to Bern Martens and Danny De Schreye, Department of Computer Science, Katholieke Universiteit Leuven, Celestijnenlaan 200A. B-3001 Hevrrlee Belgium E-mail- {bern, dannyd}@cs.kuleuven.ac.be.
    [Show full text]
  • Visual Smalltalk Enterprise ™ ™
    Visual Smalltalk Enterprise ™ ™ Language Reference P46-0201-00 Copyright © 1999–2000 Cincom Systems, Inc. All rights reserved. Copyright © 1999–2000 Seagull Systems, Inc. All rights reserved. This product contains copyrighted third-party software. Part Number: P46-0201-00 Software Release 3.2 This document is subject to change without notice. RESTRICTED RIGHTS LEGEND: Use, duplication, or disclosure by the Government is subject to restrictions as set forth in subparagraph (c)(1)(ii) of the Rights in Technical Data and Computer Software clause at DFARS 252.227-7013. Trademark acknowledgments: CINCOM, CINCOM SYSTEMS, and the Cincom logo are registered trademarks of Cincom Systems, Inc. Visual Smalltalk is a trademark of Cincom Systems, Inc., its subsidiaries, or successors and are registered in the United States and other countries. Microsoft Windows is a registered trademark of Microsoft, Inc. Win32 is a trademark of Microsoft, Inc. OS/2 is a registered trademark of IBM Corporation. Other product names mentioned herein are used for identification purposes only, and may be trademarks of their respective companies. The following copyright notices apply to software that accompanies this documentation: Visual Smalltalk is furnished under a license and may not be used, copied, disclosed, and/or distributed except in accordance with the terms of said license. No class names, hierarchies, or protocols may be copied for implementation in other systems. This manual set and online system documentation copyright © 1999–2000 by Cincom Systems, Inc. All rights reserved. No part of it may be copied, photocopied, reproduced, translated, or reduced to any electronic medium or machine-readable form without prior written consent from Cincom.
    [Show full text]
  • GNU Grep: Print Lines That Match Patterns Version 3.7, 8 August 2021
    GNU Grep: Print lines that match patterns version 3.7, 8 August 2021 Alain Magloire et al. This manual is for grep, a pattern matching engine. Copyright c 1999{2002, 2005, 2008{2021 Free Software Foundation, Inc. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.3 or any later version published by the Free Software Foundation; with no Invariant Sections, with no Front-Cover Texts, and with no Back-Cover Texts. A copy of the license is included in the section entitled \GNU Free Documentation License". i Table of Contents 1 Introduction ::::::::::::::::::::::::::::::::::::: 1 2 Invoking grep :::::::::::::::::::::::::::::::::::: 2 2.1 Command-line Options ::::::::::::::::::::::::::::::::::::::::: 2 2.1.1 Generic Program Information :::::::::::::::::::::::::::::: 2 2.1.2 Matching Control :::::::::::::::::::::::::::::::::::::::::: 2 2.1.3 General Output Control ::::::::::::::::::::::::::::::::::: 3 2.1.4 Output Line Prefix Control :::::::::::::::::::::::::::::::: 5 2.1.5 Context Line Control :::::::::::::::::::::::::::::::::::::: 6 2.1.6 File and Directory Selection:::::::::::::::::::::::::::::::: 7 2.1.7 Other Options ::::::::::::::::::::::::::::::::::::::::::::: 9 2.2 Environment Variables:::::::::::::::::::::::::::::::::::::::::: 9 2.3 Exit Status :::::::::::::::::::::::::::::::::::::::::::::::::::: 12 2.4 grep Programs :::::::::::::::::::::::::::::::::::::::::::::::: 13 3 Regular Expressions ::::::::::::::::::::::::::: 14 3.1 Fundamental Structure ::::::::::::::::::::::::::::::::::::::::
    [Show full text]
  • Practical Reflection and Metaprogramming for Dependent
    Practical Reflection and Metaprogramming for Dependent Types David Raymond Christiansen Advisor: Peter Sestoft Submitted: November 2, 2015 i Abstract Embedded domain-specific languages are special-purpose pro- gramming languages that are implemented within existing general- purpose programming languages. Dependent type systems allow strong invariants to be encoded in representations of domain-specific languages, but it can also make it difficult to program in these em- bedded languages. Interpreters and compilers must always take these invariants into account at each stage, and authors of embedded languages must work hard to relieve users of the burden of proving these properties. Idris is a dependently typed functional programming language whose semantics are given by elaboration to a core dependent type theory through a tactic language. This dissertation introduces elabo- rator reflection, in which the core operators of the elaborator are real- ized as a type of computations that are executed during the elab- oration process of Idris itself, along with a rich API for reflection. Elaborator reflection allows domain-specific languages to be imple- mented using the same elaboration technology as Idris itself, and it gives them additional means of interacting with native Idris code. It also allows Idris to be used as its own metalanguage, making it into a programmable programming language and allowing code re-use across all three stages: elaboration, type checking, and execution. Beyond elaborator reflection, other forms of compile-time reflec- tion have proven useful for embedded languages. This dissertation also describes error reflection, in which Idris code can rewrite DSL er- ror messages before presenting domain-specific messages to users, as well as a means for integrating quasiquotation into a tactic-based elaborator so that high-level syntax can be used for low-level reflected terms.
    [Show full text]
  • Cygwin User's Guide
    Cygwin User’s Guide Cygwin User’s Guide ii Copyright © Cygwin authors Permission is granted to make and distribute verbatim copies of this documentation provided the copyright notice and this per- mission notice are preserved on all copies. Permission is granted to copy and distribute modified versions of this documentation under the conditions for verbatim copying, provided that the entire resulting derived work is distributed under the terms of a permission notice identical to this one. Permission is granted to copy and distribute translations of this documentation into another language, under the above conditions for modified versions, except that this permission notice may be stated in a translation approved by the Free Software Foundation. Cygwin User’s Guide iii Contents 1 Cygwin Overview 1 1.1 What is it? . .1 1.2 Quick Start Guide for those more experienced with Windows . .1 1.3 Quick Start Guide for those more experienced with UNIX . .1 1.4 Are the Cygwin tools free software? . .2 1.5 A brief history of the Cygwin project . .2 1.6 Highlights of Cygwin Functionality . .3 1.6.1 Introduction . .3 1.6.2 Permissions and Security . .3 1.6.3 File Access . .3 1.6.4 Text Mode vs. Binary Mode . .4 1.6.5 ANSI C Library . .4 1.6.6 Process Creation . .5 1.6.6.1 Problems with process creation . .5 1.6.7 Signals . .6 1.6.8 Sockets . .6 1.6.9 Select . .7 1.7 What’s new and what changed in Cygwin . .7 1.7.1 What’s new and what changed in 3.2 .
    [Show full text]
  • Sistemas De Control De Versiones De Última Generación (DCA)
    Tema 10 - Sistemas de Control de Versiones de última generación (DCA) Antonio-M. Corbí Bellot Tema 10 - Sistemas de Control de Versiones de última generación (DCA) II HISTORIAL DE REVISIONES NÚMERO FECHA MODIFICACIONES NOMBRE Tema 10 - Sistemas de Control de Versiones de última generación (DCA) III Índice 1. ¿Qué es un Sistema de Control de Versiones (SCV)?1 2. ¿En qué consiste el control de versiones?1 3. Conceptos generales de los SCV (I) 1 4. Conceptos generales de los SCV (II) 2 5. Tipos de SCV. 2 6. Centralizados vs. Distribuidos en 90sg 2 7. ¿Qué opciones tenemos disponibles? 2 8. ¿Qué podemos hacer con un SCV? 3 9. Tipos de ramas 3 10. Formas de integrar una rama en otra (I)3 11. Formas de integrar una rama en otra (II)4 12. SCV’s con los que trabajaremos 4 13. Git (I) 5 14. Git (II) 5 15. Git (III) 5 16. Git (IV) 6 17. Git (V) 6 18. Git (VI) 7 19. Git (VII) 7 20. Git (VIII) 7 21. Git (IX) 8 22. Git (X) 8 23. Git (XI) 9 Tema 10 - Sistemas de Control de Versiones de última generación (DCA) IV 24. Git (XII) 9 25. Git (XIII) 9 26. Git (XIV) 10 27. Git (XV) 10 28. Git (XVI) 11 29. Git (XVII) 11 30. Git (XVIII) 12 31. Git (XIX) 12 32. Git. Vídeos relacionados 12 33. Mercurial (I) 12 34. Mercurial (II) 12 35. Mercurial (III) 13 36. Mercurial (IV) 13 37. Mercurial (V) 13 38. Mercurial (VI) 14 39.
    [Show full text]
  • Design Pattern
    Sitesbay.com A Perfect Place for All Tutorials Resources Java Projects | C | C++ | DS | Interview Questions | JavaScript Core Java | Servlet | JSP | JDBC | Struts | Hibernate | Spring | Java Projects | C | C++ | DS | Interview Questions | Html | CSS | Html5 | JavaScript | Ajax | Angularjs | Basic Programs | C Project | Java Project | Interview Tips | Forums | Java Discussions www.sitesbay.com DESIGN PATTERN By SEKHAR SIR [Thursday, May 29, 2014] Recursive Problem:- If some problem occurs again and again in a particular context then we call it as a Recursive Problem. For example, if an audio player having support with MP2 files gets problem for MP3 files and having support for MP3 gets problem MP4. So it is a recursive problem. In a software application, for example a recursive problem will be transferring the data across layers. Q. Why Design Patterns? Ans:- Design patterns are used for solving recursive problems in a software application design. A design pattern is a description for how to solve a recursive problem. Design patterns are not a technology or a tool or a language or a platform or a framework. Design patterns are effective proven solutions for recursive problems. Q. How many Design Patterns? Ans:- Actually, there is no fixed count of no of design patterns because design patterns is not a package and not in the form of classes. SUN Microsystems constituted a group with four professional with the name of Gang of Four (GOF) to find effective solutions for the recursive problems. According to GOF, they found 23 design patterns as effective solutions for re-occurring problems. GOF divided java design patterns into 4 categories (a) Creational Design Patterns:- (1) Singleton Pattern.
    [Show full text]