scispace - formally typeset
Search or ask a question
Book

Design Patterns: Elements of Reusable Object-Oriented Software

TL;DR: The book is an introduction to the idea of design patterns in software engineering, and a catalog of twenty-three common patterns, which most experienced OOP designers will find out they've known about patterns all along.
Abstract: The book is an introduction to the idea of design patterns in software engineering, and a catalog of twenty-three common patterns. The nice thing is, most experienced OOP designers will find out they've known about patterns all along. It's just that they've never considered them as such, or tried to centralize the idea behind a given pattern so that it will be easily reusable.
Citations
More filters
Journal ArticleDOI
TL;DR: M mothur is used as a case study to trim, screen, and align sequences; calculate distances; assign sequences to operational taxonomic units; and describe the α and β diversity of eight marine samples previously characterized by pyrosequencing of 16S rRNA gene fragments.
Abstract: mothur aims to be a comprehensive software package that allows users to use a single piece of software to analyze community sequence data. It builds upon previous tools to provide a flexible and powerful software package for analyzing sequencing data. As a case study, we used mothur to trim, screen, and align sequences; calculate distances; assign sequences to operational taxonomic units; and describe the alpha and beta diversity of eight marine samples previously characterized by pyrosequencing of 16S rRNA gene fragments. This analysis of more than 222,000 sequences was completed in less than 2 h with a laptop computer.

17,350 citations

Book
Martin Fowler1
01 Jan 1999
TL;DR: Almost every expert in Object-Oriented Development stresses the importance of iterative development, but how do you add function to the existing code base while still preserving its design integrity?
Abstract: Almost every expert in Object-Oriented Development stresses the importance of iterative development. As you proceed with the iterative development, you need to add function to the existing code base. If you are really lucky that code base is structured just right to support the new function while still preserving its design integrity. Of course most of the time we are not lucky, the code does not quite fit what we want to do. You could just add the function on top of the code base. But soon this leads to applying patch upon patch making your system more complex than it needs to be. This complexity leads to bugs, and cripples your productivity.

5,174 citations


Additional excerpts

  • ...[4], [5], [6] Object-oriented design techniques such as CRC[7] focus on defining classes and their protocols....

    [...]

Journal ArticleDOI
Gregor Kiczales1
TL;DR: This work proposes to use aspect-orientation to automate the calculation of statistics for database optimization and shows how nicely the update functionality can be modularized in an aspect and how easy it is to specify the exact places and the time when statistics updates should be performed to speed up complex queries.
Abstract: The performance of relational database applications often suffers. The reason is that query optimizers require accurate statistics about data in the database in order to provide optimal query execution plans. Unfortunately, the computation of these statistics must be initiated explicitly (e.g., within application code), and computing statistics takes some time. Moreover, it is not easy to decide when to update statistics of what tables in an application. A well-engineered solution requires adding source code usually in many places of an application. The issue of updating the statistics for database optimization is a crosscutting concern. Thus we propose to use aspect-orientation to automate the calculation. We show how nicely the update functionality can be modularized in an aspect and how easy it is to specify the exact places and the time when statistics updates should be performed to speed up complex queries. Due to the automatic nature, computation takes place on time for complex queries, only when necessary, and only for stale tables. The implementation language for the automated aspect-oriented statistics update concern is AspectJ, a well known and mature aspect-oriented programming language. The approach can however be implemented in any other aspect-oriented language. Unlike in traditional object-oriented pattern solutions, e.g. using the interceptor pattern, we do not have to modify existing code.

5,161 citations


Cites background from "Design Patterns: Elements of Reusab..."

  • ...The agent exposes a façade [23] to which the application needs to make calls at significant points in its execution....

    [...]

  • ...Lohmann, Gal, and Spinczyk [23] demonstrate that these mechanisms can be used to develop code with an aspect-oriented style, but without the obliviousness of aspects: everything must be explicitly instantiated through templates, which have to have the extension points designed in....

    [...]

  • ...P6Spy [28] is a popular library the uses the decorator pattern [23] to collect information about JDBC usage....

    [...]

  • ...The main limitation of implementing aspects as templates and of policy classes is that the extension points of an aspect or the actual policy location of a policy class must be designed into the template [23]....

    [...]

  • ...Springer Berlin Heidelberg 2004 [23] Seshadri, P....

    [...]

01 Jan 1999
TL;DR: The Unified Modeling Language Reference Manual as discussed by the authors provides an excellent real-world guide to working with UML, from structured design methods of the '60s and '70s to the competing object-oriented design standards that were unified to create UML.
Abstract: Written by the three pioneers behind the Unified Modeling Language (UML) standard, The Unified Modeling Language Reference Manual provides an excellent real-world guide to working with UML. This title provides expert knowledge on all facets of today's UML standard, helping developers who are encountering UML on the job for the first time to be more productive. The book begins with a history of UML, from structured design methods of the '60s and '70s to the competing object-oriented design standards that were unified in 1997 to create UML. For the novice, the authors illustrate key diagram types such as class, use case, state machine, activity, and implementation. (Of course, learning these basic diagram types is what UML is all about. The authors use an easy-to-understand ticket-booking system for many of their examples.) After a tour of basic document types, The Unified Modeling Language Reference Manual provides an alphabetical listing of more than 350 UML terms. Entries range from a sentence or two to several pages in length. (Class, operation, and use case are just a few of the important terms that are covered.) Though you will certainly need to be acquainted with software engineering principles, this reference will serve the working software developer well. As the authors note, this isn't UML for Dummies, but neither is it an arcane academic treatise. The authors succeed in delivering a readable reference that will answer any UML question, no matter how common or obscure. --Richard Dragan

4,531 citations

Journal ArticleDOI
TL;DR: Galaxy Pages are interactive, web-based documents that provide users with a medium to communicate a complete computational analysis and provide support for capturing the context and intent of computational methods.
Abstract: Increased reliance on computational approaches in the life sciences has revealed grave concerns about how accessible and reproducible computation-reliant results truly are. Galaxy http://usegalaxy.org, an open web-based platform for genomic research, addresses these problems. Galaxy automatically tracks and manages data provenance and provides support for capturing the context and intent of computational methods. Galaxy Pages are interactive, web-based documents that provide users with a medium to communicate a complete computational analysis.

3,576 citations

References
More filters
Journal ArticleDOI
01 Jun 1986
TL;DR: Because any object can be used as a prototype, and any messages can be forwarded at any time, delegation is the more flexible and general of the two techniques.
Abstract: A traditional philosophical controversy between representing general concepts as abstract sets or classes and representing concepts as concrete prototypes is reflected in a controversy between two mechanisms for sharing behavior between objects in object oriented programming languages. Inheritance splits the object world into classes, which encode behavior shared among a group of instances, which represent individual members of these sets. The class/instance distinction is not needed if the alternative of using prototypes is adopted. A prototype represents the default behavior for a concept, and new objects can re-use part of the knowledge stored in the prototype by saying how the new object differs from the prototype. The prototype approach seems to hold some advantages for representing default knowledge, and incrementally and dynamically modifying concepts. Delegation is the mechanism for implementing this in object oriented languages. After checking its idiosyncratic behavior, an object can forward a message to prototypes to invoke more general knowledge. Because class objects must be created before their instances can be used, and behavior can only be associated with classes, inheritance fixes the communication patterns between objects at instance creation time. Because any object can be used as a prototype, and any messages can be forwarded at any time, delegation is the more flexible and general of the two techniques.

564 citations

Book
Bjarne Stroustrup1
01 Jan 1994
TL;DR: The Prehistory of C++ and the C++ Language Design Rules, 1985-1993, and Looking Ahead, which describes the future of the language and its structure, are published.
Abstract: PART I. 1. The Prehistory of C++ . 2. C with Classes. 3. The Birth of C++. 4. C++ Language Design Rules. 5. Chronology 1985-1993. 6. Standardization. 7. Interest and Use. 8. Libraries. 9. Looking Ahead. PART II. 1. Memory Management. 2. Overloading. 3. Multiple Inheritance. 4. Class Concept Refinements. 5. Casting. 6. Templates. 7. Exception Handling. 8. Namespaces. 9. The C Preprocessor. Index. 0201543303T04062001

544 citations

Journal ArticleDOI
TL;DR: A user interface toolkit that offers a rich set of composition mechanisms and a variety of predefined objects, allowing easy implementation of complex user interfaces, and support for end-user customization as well as the status of the current implementation is described.
Abstract: The authors describe a user interface toolkit, InterViews, that offers a rich set of composition mechanisms and a variety of predefined objects, allowing easy implementation of complex user interfaces. InterViews supports composition of three object categories, each implemented as a hierarchy of object classes derived from a common base class. The categories are interactive objects, structured graphics objects, and structured text objects. The authors present several simple applications and show how InterViews objects can implement their interfaces. They illustrate the benefits of separating interactive behavior and abstract data in several different contexts. They discuss InterViews support for end-user customization as well as the status of the current implementation. >

502 citations

Proceedings ArticleDOI
31 Oct 1992
TL;DR: This paper shows one way to document frameworks with patterns, and includes a set of patterns for HotDraw as an example to see how well patterns work to describe a framework.
Abstract: The documentation for a framework must meet several requirements. These requirements can all be met by structuring the documentation as a set of patterns, sometimes called a “pattern language”. Patterns can describe the purpose of a framework, can let application programmers use a framework without having to understand in detail how it works, and can teach many of the design details embodied in the framework. This paper shows how to use patterns to document a framework, and includes a set of patterns for HotDraw as an example. Christopher Alexander, an architect, developed the idea of a “pattern language” to enable people to design their own homes and communities [Alexander et. al.]. A pattern language is a set of patterns, each of which describes how to solve a particular kind of problem. His pattern language starts at a very large scale, explaining how the world should be broken into nations and nations into smaller regions, and goes on to explain how to arrange roads, parking, shopping, places to work, homes, and places of worship. The patterns focus on finer and finer levels of detail, passing though a discussion of how to arrange rooms in a house, and finally describing the type of material to use for walls, how to decorate rooms, and how to provide lighting. Alexander's pattern language is supposed to be a document that non-architects can use to design their own communities and homes. No specialized training is needed to use it. It focuses on common design problems that non-architects will encounter, like how to build bedrooms and row houses, rather than uncommon ones, like how to build concert halls and cathedrals. To be presented at OOPSLA’92. Although Alexander uses the term “pattern language” to describe his document, it is not a formal language like a context-free language, for example. A pattern language is a structured essay, not a mathematical object. Therefore, we will replace that term with the term “patterns”. A framework is a reusable design of a program or a part of a program expressed as a set of classes [Deutsch][Johnson and Foote]. Like all software, it is a mixture of the concrete and the abstract. Since frameworks are reusable designs, not just code, they are more abstract than most software, which makes documenting them difficult. Frameworks are designed by experts in a particular domain and then used by non-experts. The principal audience of framework documentation is someone who wants to use the framework to solve typical problems, not someone building a software cathedral. Patterns seem to be well suited for this audience. This paper shows one way to document frameworks with patterns. It is essentially an experiment to see how well patterns work to describe a framework. The result is a set of patterns that are included in the appendix. The main purpose of a set of patterns is to show how to use a framework, not to show how it works, but patterns can also describe a great deal of the theory of its design. 1. A Format for Patterns One of the important features of Alexander’s pattern language is its structure; each pattern is written in a particular format and patterns are arranged so that each pattern leads into the next. The format that Alexander uses is unlikely to be suitable for software. For example, since he is building physical objects, he requires pictures both for stating the problem that a pattern solves and for stating the solution. Thus, the patterns in this paper have a different format that the one he used. Each pattern describes a problem that occurs over and over again in the problem domain of the framework, and then describes how to solve that problem. Each pattern has the same format. The format used in this paper is to first give a description of the problem in italics. This is followed by a detailed discussion of the different ways to solve the problem, with examples and pointers to other parts of the framework. The pattern ends with a summary of the solution, again in italics, followed by pointers to other patterns that are needed to fill it out and embellish it. The appendix to this paper describes a set of ten patterns for HotDraw, a drawing framework. For example, pattern 4 is Pattern 4: Complex Figures Some figures have a visual presentation with internal structure. For example, they may have attributes that are displayed by other figures. It should be possible to compose them from simpler figures. Complicated figures like PERTEvent can be thought of as being composed of simpler figures. For example, a PERTEvent has a RectangleFigure and several TextFigures for the title, the duration, and the ending date. Complex figures like PERTEvent are subclasses of CompositeFigure. A CompositeFigure is a figure with other figures as components, and it displays itself by displaying its components. It has a bounding box that is independent of the bounding box of its components, and it will display its components only if they are inside of its bounding box. The selection tool and text tool will operation on its components when the left shift key is pressed. Custom tools can operate directly on the components, if you want.

453 citations

Book
Andrew S. Glassner1
01 Nov 1990
TL;DR: The Graphics GEMS series as discussed by the authors provides tips, techniques, and algorithms for graphics programmers with a common desire to share interesting ideas and tools with their colleagues, and each volume provides a new set of innovative solutions to a variety of programming problems.
Abstract: From the Publisher: "The GRAPHICS GEMS Series" was started in 1990 by Andrew Glassner. The vision and purpose of the Series was - and still is - to provide tips, techniques, and algorithms for graphics programmers. All of the gems are written by programmers who work in the field and are motivated by a common desire to share interesting ideas and tools with their colleagues. Each volume provides a new set of innovative solutions to a variety of programming problems

410 citations