CSC532 Adv. Topics in Software Engineering
CSC532 Adv. Topics in Software Engineering
TERM PAPER ON
DESIGN PATTERNS IN SOFTWARE ENGINEERING
Omkar Swaroop Appikatla
Department of Computer Science
LouisianaTechUniversity
DESIGN PATTERNS
Abstract
Design pattern plays an important role in the software engineering. Independent of the application or the language used, the design pattern helps us in solving a problem which occurs again and again [5]. The experience of the others is implemented and utilized instead of developing the application from the beginning. By implementing the design rules and reusing the components, the chances of getting latent errors reduces to great extent [2]. Among the different categories of design patterns, the creational design patterns concentrate on creation of the objects according to the situation. By applying this pattern, we can have better control on the creation of objects which reduces the design problems.
Introduction
Christopher Alexander is the pioneer to introduce the concept of patterns. People began to use this concept in the field of programming from the year 1897 [2]. This design patterns help the developers to understand better by using better conversions. These patterns avoid small problems which may turn to a major problem later in the implementation. As the developers become more familiar with these patterns, the readability of the code will increase. Thus, improving the already existing pattern will also be simple.
The design patterns can be classified as Creational patterns, Fundamental patterns, Structural patterns, Behavioral patterns, Concurrency patterns, Event handling patterns and Architectural patterns. Among these, the Creational pattern is explained in detail.
1. Creational Patterns
The creational patterns perform one of the major task in the object oriented programming i.e. creation of objects. These patterns help in initialization of objects at the correct moment according to the situation because, in many cases, any object oriented system may need many objects to be created at a certain instance. Some of the methods involved in this creation are by Generic initialization, where the objects need not depend on the class name to be initialize and by theSimplicity method, where the callers need not have much coding in order to initialize object.
The abstract factory pattern, builder pattern, Factory method pattern, lazy initialization pattern, prototype pattern and the singleton pattern come under the category of the creational patterns.
1.1 Abstract factory pattern
The factories having the common features are grouped together without mentioning their specific concrete class [1].
For example, we need to maintain data of phone numbers and zip code of a country; we write the code using two classes for collecting phone numbers and zip code. Later, we may need to do the same work for another country. So, we change the functional code for these classes as the format for the phone number and zip code may differ between different countries. Likewise, if more data is to be added and the same procedure follows, the coding becomes very difficult. To avoid this and make the application more flexible, we group these two classes which will allow us to add variations to the system. This is called the abstract factory method, where we define the abstract factory which will create objects according to the general pattern of the classes created. At the run time, the factory may be coupled with other concrete factories that have their own format [1].
We prefer this kind of pattern when the objects are to be created as a group or as a set which will make them more compatible, when the client should be abstracted from the details of the creation of objects or when providing the group of classes with their relationships and hiding the details of implementation.
The advantage of this pattern is, it will make the application more flexible. The developer need not bother about the features that are going to be added. Moreover, at the run time it can add new features. Even the testing can be simplified by using this pattern [1].
1.2 Builder pattern
We use builder pattern to simplify the process of object creation when the generation of objects become complex [1].Here, we define another class which will help in creating objects of another class. In this process, there will be only single main class which will have a main product with a number of classes within the product [1].
Let us consider that we need to maintain a calendar to store some information about appointments. This appointment may need the details like starting and ending of appointment, location and the number of people attending. In general, we define a class named “Appointment” which will have a constructor that can set the values of a new appointment whenever an object is created.
As there are chances of getting different types of data depending on the type of appointment, creating objects may turn complex. Generally, this can be managed in two ways. One way of doing this is by creating constructer for every type of appointment and other way by having a constructer with much functionality. Unfortunately, both of these methods have problems. If there are many number of constructors calling the methods, it becomes complex. Similarly, if the functionality is high, the debugging turns very complex. In either of the way, creating a subclass will give problems.
To avoid this problem, we use a Builder class. Here, in the above example, we can use “AppointmentBuilder” class which will take the responsibilities of the “Appointment” class and can reduce the coding of the Appointment class. By doing this, we can call the methods in the AppointmentBuilder class which are relevant to the “Appointment class”. The Builder class can also validate the data passed to Appointment class and even enables to create sub class to the existing class [1].
We prefer this kind of pattern when the internal structure of the class looks very complex or when the class needs some objects which are tough to access during creation.
The advantage of this pattern is that the Builder can help the objects to use the system resources for creation. The clients need to only access the Builder object for there resources which makes their work easy. On the otherside, whenever we modify the product, we need to change the Builder and the class which takes responsibilities of the Builder. Therefore,the Builder and the product are considered to be tightly coupled which turns to be a disadvantage [1].
1.3 Factory method Pattern
This pattern deals with creation of object. Here, the type of object to be created depends on the sub class. The sub class will override the product which already exists [1].
Let us consider that we need to prepare an application that needs maintains data which will be useful for our daily life. The data may be name of a person, phone number, appointment, address and so on. The data here may not be a static one.
The data obtained may need to be modified if the appointment, address, phone number or any of the data changes. This turns out to be a big problem in this case.
The application has to generate the fields according to the user, to modify his data which will make the coding of application complex. Moreover, to update these details, the application should be able to have the correct field. Finally, the application becomes tough to maintain this data.
We can manage this problem by making each of the field like address to use its own editors which can be very much useful in the modifications [1].The application is only responsible in requesting the editor which can be invoked for every field which needs to be modified. Generally, this can be done by calling methods like getEditor which implements the Interface like ItemEditor. The application uses this object for again creating a JComponent which helps the user to modify the details in the graphical mode. The editor takes care of the data entered by the user whether the data is valid or not. Thus, without having modifications in our application, we can add new types of fields.
This pattern is specifically used when the type of object to be created is to be decided later or when we not aware at which time the object is to be created.It can be even used when we need many overloaded constructor with the same signature or the same number of parameters [1].
References: