Software architecture is defined as the structured process providing a solution that meets technical and operational requirements of a project while optimizing performance and security. Architecture provides a set of abstract patterns guiding the design of a software system. This provides for problem-solving and planning to a software solution. Once the purpose and specifications of the proposed software is determined the next step is to design a plan for the solution. Design Patterns allows designers to reuse the fundamental concepts of methodologies employed from previous solutions to complete a current project.
These patterns provide a template on how to solve a problem in various situations. According to (Tichy, 2010) design patterns serve to improve the structure of the software, simplify maintenance and help avoid architectural drift. Design patterns also allow for improved communication amongst the software developers which results in a superior product. Patterns are used as they speed up developmental processes by providing tested, proven development paradigms. Reusing design patterns improves code readability for coders. There are two categories in design patterns, Creational design patterns and Structural Design Patterns.
This paper will discuss examples of each underlining their objectives and disadvantages. Structural design patterns Adopter Design Pattern (aka Wrapper) Adopter design pattern converts the interface of one class into another class. This achieved by taking the instance of the class to be converted and uses the methods the adoptee has available to create methods which are expected. It wraps the existing class with a new interface. It allows for impedance by matching an old component to a new system. This becomes particular useful when for instance a company purchases an off the shelf product and wishes to adopt it into their current system.
The disadvantages of this method arises when trying to implement new product with software with legacy code, this can prove to be time consuming and often tedious work. It is difficult to maintain and extend the functionality of most legacy software. Facade Design Pattern The Facade design pattern provides a simple interface to a complex collection of modules or code. It provides a unified interface to a set of interfaces in a subsystem, thereby wrapping a complicated subsystem with a simpler interface.
This is particularly useful when a segment of the client community needs a simplified interface to the overall functionality of a complex subsystem. The main advantage of the facade pattern is that you can divide up a JSEE application into logical groups by business functionality. The disadvantage of facade design pattern is that it is very complicated and requires designers with much experience. Proxy Design Pattern Proxy design pattern provides a surrogate or place holder for another object to control access to it. It adds a wrapper and delegation to protect the real component from undue complexity.
Proxy is a class that functions as an interface to something else such as a network collection or a large object in memory. This is useful when you need support for objects that use large resources and you do not want to instantiate such objects unless they are requested by the client. The advantage of employing this design pattern is that it allows for better performance and lowers cost of ownership. Another advantage is that it is easier to manage. The disadvantage of using Proxy accounts is that it is inherently less secure. Creational Design Patterns Abstract Factory Design
Abstract design pattern provides an interface for creating families of related or dependant objects without specifying their concrete class. It refers to the newly created object through a common interface. The advantage of this abstract factory design is that new objects can be added without changing a single line of code in the framework. The disadvantage is that it does create more code and could introduce added complexity in the DTO. Factory Method Design Factory design Pattern defines an interface for creating an object letting the subclasses decide which class to instantiate.
This method lets a class defer instantiation to subclasses. This can be used when a framework needs to standardize the architectural model for a range of applications to define their own domain objects and provide for instantiation. It allows for isolation of concrete classes and promoting consistency among products. The disadvantage of this pattern is that it is difficult to support with new kinds of products and becomes difficult when expanding. Conclusion This paper looked at several design patterns for software architecture.
Each method is can be employed by determining the needs of your project. Design patterns are reusable templates that function as a guide to developers needs.
References (Gamma, Helm, & Johnson, 1995) Gamma, E. , Helm, R. , & Johnson, R. (1995). Design Patterns. Retrieved from http://www. theperlreview. com/Articles/v0i4/facade. pdf Source Making. (2010,December). Design Patterns. Retrieved from http://sourcemaking. com/design_patterns Tichy, W. F. (2010,December). Essential Software Design Patterns. Retrieved from http://wwwipd. ira. uka. de/~tichy/patterns/overview. html