Design Patterns as Higher-Order Datatype-Generic Programs
Design patterns are reusable abstractions in object-oriented software. However, using current mainstream programming languages, these elements can only be expressed extra-linguistically: as prose, pictures, and prototypes. We believe that this is not inherent in the patterns themselves, but evidence of a lack of expressivity in the languages of today. We expect that, in the languages of the future, the code parts of design patterns will be expressible as reusable library components. Indeed, we claim that the languages of tomorrow will suffice; the future is not far away. All that is needed, in addition to commonly-available features, are higherorder and datatype-generic constructs; these features are already or nearly available now. We argue the case by presenting higherorder datatype-generic programs capturing ORIGAMI, a small suite of patterns for recursive data structures.
Read more
Facade Design Pattern
definition
Provide a unified interface to a set of interfaces in a subsystem. Façade defines a higher-level interface that makes the subsystem easier to use.
Read more
Structural Design Patterns and .NET Framework 2.0
There are many uncertainties in identifying and applying suitable design patterns while designing applications. Our goal is to investigate applications of design patterns in .NET Framework. Among the seven structural patterns described by Gang of Four (GOF), we have discussed five patterns from .NET perspective. As there is no official documentation available on the patterns used in the latest version of .NET Framework (version 2.0) currently, this study would be beneficial for .NET designers in understanding patterns behind the framework, which in turn would help them in applying relevant patterns while developing their aplications in .NET Framework.
Read more
Design patterns to increase performance when using an object-relational mapping and their categorization
Today’s sophisticated software applications are developed using object- oriented techniques. For database access the object-oriented approach hasn’t established – the usage of relational databases is still prevailing. There are a couple of tools that bridge this so called “impedance mismatch”. These tools allow the usage of relational database systems with an object-oriented approach. This is achieved in extending the object-oriented language with an object- oriented database model, often called persistency model. But the transparent usage of such a persistency model often leads to unacceptable slow systems. This paper describes how, and why this can occur. It will then introduce different categories of design patterns to prevent certain performance problems when using an object-relational mapping. Finally, it gives examples for each of these categories, pointing out their application area and their advantages and disadvantages.
Read more
UML Extensions for Design Pattern Compositions
Design patterns document good solutions to recurring problems in a particular context. Composing design patterns may achieve higher level of reuse by solving a set of problems. Design patterns and their compositions are usually modeled by UML diagrams. When a design pattern is applied or composed with other patterns, the pattern-related information may be lost because traditional UML diagrams do not track this information. Thus, it is hard for a designer to identify a design pattern when it is applied or composed. In this paper, we present notations to explicitly represent each pattern in the applications and compositions of design patterns. The notations allow us to maintain pattern-related information. Thus, a design pattern is identifiable and traceable from its application and composition with others.
Read more