Docsity
Docsity

Prepare for your exams
Prepare for your exams

Study with the several resources on Docsity


Earn points to download
Earn points to download

Earn points by helping other students or get them with a premium plan


Guidelines and tips
Guidelines and tips

Design Patterns - Principles of Software Development - Lecture Notes, Study notes of Software Engineering

Main points of this lecture are: Design Patterns, Naive Concept of Pattern, Three-Part Rule, Design Pattern Intentions, Economy of Scale, Beware Jabberwock, Pattern Essentials, Exploit Economy of Scale, Object-Relational Modeling

Typology: Study notes

2012/2013

Uploaded on 04/23/2013

ashakiran
ashakiran 🇮🇳

4.5

(27)

251 documents

1 / 26

Related documents


Partial preview of the text

Download Design Patterns - Principles of Software Development - Lecture Notes and more Study notes Software Engineering in PDF only on Docsity! So far, we have concentrated on reusable software. ○ A design pattern is a reusable practice for designing software. ○ Simply stated, a pattern is a proven way of solving some problem. ○ So far, we've concentrated on principles that guide practice. ○ A design pattern is a practice based upon principles. ○ Design patterns Design Patterns Monday, November 09, 2009 10:29 AM Patterns Page 1 Docsity.com Description with blanks in it. You "fill in the blanks" to get software. What kinds of things fit in the blanks. (preconditions) What you can expect if you put them there. (postconditions) There is documentation on Naïve concept of a pattern Naïve concept of a pattern Wednesday, September 26, 2012 4:38 PM Patterns Page 2 Docsity.com If lots of people have successfully used an approach, then it is most likely a good approach. ○ If a few people have successfully used it, it is less attractive and less proven. ○ The basic motivation for patterns is economy of scale. the way they use it is likely to be free of bugs, and  that particular way is unlikely to become deprecated.  If 1/2 of the known internet developers use a specific library or toolkit, then ○ More specifically, Pattern implementations gain validity by adoption. This is a "500-lb gorilla" approach to choosing technological solutions. Economy of scale Monday, November 09, 2009 12:01 PM Patterns Page 5 Docsity.com You are doing something quite different than the other people. ○ You are using a library in an unusual way. ○ The above logic does not apply if: You're the only tester! ○ Your use of the library can be deprecated! ○ You don't want to be the only developer using a library in a given way! Then: Beware the jabberwock Monday, November 09, 2009 2:13 PM Patterns Page 6 Docsity.com A clear mission or purpose ("value proposition") A clear method to be applied. Proof of successful application. Pattern essentials Pattern essentials Monday, November 09, 2009 2:14 PM Patterns Page 7 Docsity.com The context: web applications○ The problem: database interaction with web pages. ○ Define primitive operations on a database as functions.  Functions are methods of a "database object" that makes the appropriate changes to the database.  Create□ Read□ Update □ Delete□ Enabling libraries instantiate common operations:  This is the so-called "CRUD model" of database interaction.  The solution: object-relational modeling (ORM) ○ Attributes of the solution: encapsulates database operations, increases inherent portability (and ease of porting) of solution. ○ Example: encapsulation as a pattern Example 1: encapsulation as a pattern Monday, November 09, 2009 10:37 AM Patterns Page 10 Docsity.com The context: web applications The problem: communication between local JavaScript and remote server (Web 2.0). Code information as JavaScript structures. Web client uses client library to encode structures as text data. Text data is sent to server. Server uses server library to decode data, and encode answer. Client receives response from server in kind. The solution: JavaScript Object Notation (JSON). Attributes of the solution: leverages existing debugged libraries for server-client interaction, including tested and reliable encoding and decoding. One doesn't have to write encoding and decoding "again". Example: algorithm as a pattern Example 2: algorithm as a pattern Monday, November 09, 2009 10:43 AM Patterns Page 11 Docsity.com The context: writing a web application The problem: use an architecture that streamlines development The model: database interactions (an ORM). The view: how that appears to the user. The controller: manages changes of state in response to user input (uses the model). The solution: Model-View-Controller (MVC) architecture Attributes of the solution: separates a web application into three parts that are usually orthogonal, eases parallel development and maintenance of M, V, and C. Example: architecture as a pattern Example 3: architecture as a pattern Monday, November 09, 2009 10:50 AM Patterns Page 12 Docsity.com Factories: customize an object for a specific purpose.  Builder: separate object construction from use to allow different constructions as necessary.  Prototype: pre-instantiate parts of an object to reduce factory cost.  Creational○ Adapter pattern: create "middleware" that adapts an existing object for use by a new kind of client.  Bridge pattern: decouple an abstraction from its implementation.  Container pattern: hold a set of objects to manipulate it.  Proxy pattern: a class that functions as an interface to something that might not be an object.  Pipes and filters: constructing a dataflow process from primitive dataflow components.  Structural○ Command: encapsulate a command and its parameters.  Event listener: objects "listen" for events and only respond to those that they recognize.  Interpreter: use a specialized computer language to solve a set of problems.  Iterator: iterate over a container of objects without reference to how the container is designed.  Mediator: provide a unified interface to a set of interfaces within a subsystem.  Visitor: separate an algorithm from an object by defining what is done when one "visits" a node.  Behavioral○ A short list of available patterns A short list of available patterns Monday, November 09, 2009 11:02 AM Patterns Page 15 Docsity.com defining what is done when one "visits" a node. Patterns Page 16 Docsity.com Known limits: patterns have limitations. Square peg; round hole: patterns can't be applied to just any problem without thinking about it. Not a pattern: a pattern isn't a pattern until it's proven by practice. A "personal pattern" is an oxymoron. Pattern limits Pattern limits Monday, November 09, 2009 11:17 AM Patterns Page 17 Docsity.com Pattern: MVC Problem: new kind of database interaction, e.g., Amazon S3 (scalable storage service). Difficulty: MVC tied to existing ORM software. "Square peg in round hole" ignore MVC and proceed with classical web development craft a new ORM to plug into existing MVC. Two approaches: Agile solution: both. Example of pattern inapplicability Example of inapplicability Monday, November 09, 2009 3:31 PM Patterns Page 20 Docsity.com Problem: the problem it solves. Motivation: what you expect adopters to gain. Context: describes the application context to which the pattern applies. Forces: limitations and constraints that should be considered in adopting. Solution: a detailed description of what adopters should do. Collaborations: how other patterns contribute to the solution. Consequences: tradeoffs that must be made when considering adoption. Implementation: special issues that must be considered when implementing the pattern. Known uses: examples of successful adoption. Related patterns: cross-reference to patterns with similar goals. How to specify a pattern: How to specify a pattern Monday, November 09, 2009 11:24 AM Patterns Page 21 Docsity.com Problem: modification of specific data elements often requires modification of related elements, e.g., a display or sum or other function of the elements. Motivation: can forget about side-effects and program changes in data elements without considering them. Context: serial programming in typical high-level languages: C++, C#, Java, J#. Forces: only really effective in decoupling parameter changes from side-effects if the language supports it transparently (C#/J#). Solution: program side-effects of setting a parameter via get and set methods that are transparently used whenever anyone sets or accesses the parameter. Collaborations: none. Consequences: any time one changes a get or set method, one must potentially retest every component that uses it. Implementation: only truly effective when language supports it. Known uses: displaying the value of a changing parameter as a side-effect of changing it. Keeping running sums and statistics of several parameters transparently. Thousands of C# and J# apps. Related patterns: none. Aspect-oriented programming Example: aspect-oriented programming Monday, November 09, 2009 11:24 AM Patterns Page 22 Docsity.com A rigorous depiction of what is really "common sense". Not really any different from the way we approach any coding problem. The basic principle: if it worked for others, it'll work for you, unless something about your problem is really different! What are patterns, really? What are patterns, really? Monday, November 09, 2009 3:15 PM Patterns Page 25 Docsity.com My answer: No! It is engineering. Engineering is about using the lessons from the past to engineer reliable solutions for the future. "Sometimes the last thing you need is a new idea." Is software engineering creative? Reliable, quickly implementable, risk-free solutions are always preferable to creative, risky ones with unknown risk factors. Leave the risky approaches to research! In other words, Creativity Monday, November 09, 2009 3:18 PM Patterns Page 26 Docsity.com
Docsity logo



Copyright © 2024 Ladybird Srl - Via Leonardo da Vinci 16, 10126, Torino, Italy - VAT 10816460017 - All rights reserved