Application patterns
A design pattern can be defined as a general reusable solution to a common repeating problem in software design. It basically refers to a rough draft or a template of how a problem will be solved under many different solutions. Object-oriented design solutions depict the relationship between classes and objects without specifying the final application classes or objects that are involved. In this way, algorithms are not taken as design patterns because they solve computational problems rather than design problems.
Design patterns are specifically concerned with the design problems at the level of software design, and as such, not all software patterns are design patters.
The 23 Gang of Four are the fundamental patterns in software design. They are often categorized in three groups: creational, structural, and behavioral. Object Modeling Technique is used to describe patterns in the Gang of Four design. Graphical representations of object oriented relationships are represented as follows:
- Object diagrams depict the relationship between a program, and a series of inter-related objects
- Interaction diagrams illustrate the execution of the program as an interaction among related objects
Architectural styles go into the classification of architecture in form of techniques, materials and time period or region. The software architectural style of software or computing system is the structure or structures of the system which encompasses software components, external noticeable properties of those components and the relationships between them. Architectural styles attempt to depict and facilitate communication between stakeholders, document high-level design, and allow iteration of design components and patterns between projects. According to Shaw & Clement a style is a set of design rules that identify the kinds of components and connectors that are utilized to compose a system or subsystem, together with local or external constraints on how the composition is done.
Since architecture embodies both functional and non-functional properties, it is always difficult to compare architectures for different types of systems, or essentially for the same system spanning in different environments. Styles therefore, present a mechanism for categorizing architectures through a definition of the common characteristics. Each style accords an abstraction for the interaction of components, taking in consideration the essence of patterns of interaction while ignoring the incidental details of the rest of the architecture.
In software design, a connector is an abstract mechanism that mediates communication, coordination and cooperation among components. According to Perry & Wolf, connectors are connecting elements that holds the various pieces of software architecture together. Shaw and Clements defines it as an abstraction mechanism that link cooperation, coordination and communication among components. Exam-les of these include shared representation, remote procedure calls, data streams and message passing protocols.
Communication cannot be achieved between the various components of a software solution without connectors. Connectors facilitate the process of transferring data elements between the interfaces without altering it. Internally, a connector may be comprised of a subsystem of components that transform the data for transfer, execute the transfer, and then reverse the transformation for delivery. The internal behavioral abstraction undertaken by the architecture ignores those details. Connectors contracts components because they may, but not often, transform data from the external perspective.
Frameworks are traditionally defined as a set of cooperating classes that constitute a reusable design for a certain class of software. As described in the definition, the operative term” class of software” implies the provision of a specific function within the software solution. Frameworks are always based on patterns that provide general solutions to software problems in specific contexts. The fundamental difference between patterns and frameworks is that patterns provide o definition of how to solve a certain software problem, while frameworks define the implementation of software constructs.
Singleton pattern falls in the creational patterns. With creational patterns objects are dictated on when and how they are created. Singleton pattern provides solutions for instances requiring special behavior that can only be solved through creational techniques. The pattern was formally defined by the Gang of Four and forms the least complicated and the most popular among the design patterns.
In Java for instance, the singleton pattern ensures that there is only one instance of a class created in the Java Virtual Machine. Thus, it is used to provide global point of access to the object. Practically, singletons are used in logging, caches, configuration settings, device driver objects, and thread pools.
Understanding the relationship between frameworks and patterns is a key component to understanding how to design a software solution. The motivation behind implementing frameworks that are based on software design patterns lies in the fact that consistency is achieved through a solution that can magnify productivity. In a changing environment, they can make the solution more extensible. Frameworks significantly reduce the amount of code that is required to implement a certain solution, making the solution more manageable. More precisely, the patterns that are used to create framework create a common vocabulary in a development arena, resulting in easier communication of the design.
A singleton creational pattern is a good addition to a framework in instances where a single instance of an object is essential. Using the example of a simple payment-verification system of an e-commerce business, an explanation of how to use patterns and frameworks to achieve consistency in singleton design format is presented. The requirement for the solution is that it must accept an order from the order-fulfillment system and authenticate the legitimacy of the payment in the Bank Card Verification system or the Charge Card Verification system. Second, the solution requires a secure public interface. This implies that the structure adopted must lend itself to the POSA architecture pattern comprising of a public layer, a domain layer, and a technology layer.
A creational pattern of the solution must factor in the authorization for an account in a sequential manner, necessitating a single instance of the account to be in the solution at a specific time. The singleton pattern therefore, fulfils the requirement. Using the Builder pattern to encapsulate the singleton logic with the additional logic necessary for building the account object, the following solution can be adopted.
The merits of patterns and frameworks in software solutions can only be conceived by those who have seen the productivity brought about by using them. Even the most advanced software professionals will be cautious while creating frameworks early in the product development life cycle. They prefer a refactor solution to a framework after attaining initial functionality implementation. It is essential to realize that a better understanding of the relationship between patterns and relationships aides in the development of consistent software solutions. Patterns and frameworks define.
References
Buschmann, F. R. (1996). Pattern-Oriented Software Architecture, Volume 1: A System of Patterns. . John Wiley & Sons Ltd.
Gamma, E. R. (1995). Design Patterns: Elements of Reusable Object-Oriented Software. MA: Addison-Wesley Professional.
