Monday, April 28, 2008

Singleton Pattern


Singleton Pattern
Author: Aiesha Adnan

This is my second journal, which i like to share with those who are looking for ways to use Singleton Pattern.

Motivation for learning (problem )

Design patterns are a new technique that is taught in this unit. Creational pattern deals with object instantiation. Factory pattern is the pattern I studied during the lectures. There are other patterns like Singleton Pattern that comes under the creational pattern. Currently I have no knowledge in this pattern. Besides, I have to apply design patterns in my assignments. I have no idea what it is. Therefore, I feel I should have knowledge in this pattern, if I am to use design patterns in the applications that I develop. Therefore I decided to learn about the single pattern, its structure, how to use it in java.

What is Singleton pattern? (insight Solution)
The singleton pattern is a design pattern that is used to restrict instantiation of a class to one object.Java Singleton pattern belongs to the family of design patterns, that govern the instantiation process. Therefore it ensures that at any time there can be only one instance of a singleton(object).

Implementing Singleton pattern (plan of achieving the solutions encountered)
There is actually only one class that needs to be written specially to implement the Singleton pattern. A second client class will always be involved take make requests from the singleton.

Preventing direct instantiation
In order to prevent the direct instantiation create a class with the constructor marked as private. Therefore, those other classes cannot create a new instance.
public class SingletonObjectDemo{
private static SingletonObject singletonObject;

//Note that the constructor is private
private SingletonObjectDemo (){
// Optional Code
}

Using the singleton object
This is the client, which will use this pattern. It creates an object of the singleton object and use it.

public class SingletonObjectDemo{
public static void main(String args[]){

//create the Singleton Object..
SingletonClass obj = SingletonClass.getSingletonObject();

System.out.println("Singleton object obtained"); }
}


Overcoming some practical problems

1. Thread Problems
As with the current way of implementing the access method can be called twice from two different places simultaneously which will lead to the creation of more than one object at a time. It could happen that the access method may be called twice from 2 different classes at the same time and hence more than one singleton object being created. If this happens this would definitely violate the singleton pattern principles. Therefore, add the synchronized keyword to he method as below.

public static synchronized SingletonClass getSingletonObject()

2. Cloning
It is still possible to create a copy of copy of the Object by cloning it using the Object’s clone method.such as below.

SingletonObjectDemo clonedObject = (SingletonObjectDemo) obj.clone();

This again violates the Singleton Design Pattern's objective.Inorder to deal with this, it is necessary to override the override the Object’s clone method which throws a CloneNotSupportedException exception.This will ensure that cloning is not supported.

public Object clone() throws CloneNotSupportedException {
throw new CloneNotSupportedException();
}

Final Implementation

class SingletonClass{

private static SingletonClass singletonObject;

/** A private Constructor prevents any other class from instantiating. */
private SingletonClass(){
// Optional Code
}

public static synchronized SingletonClass getSingletonObject()
{
if (singletonObject == null){
singletonObject = new SingletonClass();
}
return singletonObject;
}

public Object clone()throws CloneNotSupportedException
{

throw new CloneNotSupportedException();
}

}
//this is the client program.
public class SingletonObjectDemo{
public static void main(String args[]){
// SingletonClass obj = new SingletonClass(); Compilation error not allowed

//create the Singleton Object..
SingletonClass obj = SingletonClass.getSingletonObject();

System.out.println("Singleton object");
}
}

Finally, there is an output, which indicates that the object is created.

Consequences of using it.

Singleton pattern can be used in any application which requires an object to be instantiated only once at a time.
Singleton pattern is best when developing a Java Help Module in a project can use a singleton pattern as at any time the developers can use with only one main Help object and use the same object in different screens.

Another usage would be to create a connection pool, which will help to avoid the wastage of resources where, a singleton pattern can be used to maintain a single connection object, which can be used throughout the java applications.
• State objects are often Singletons.
• Singletons are often preferred to global variables because:
o They don't pollute the global namespace (or, in languages with namespaces, their containing namespace) with unnecessary variables.

Conclusion
This journal has helped to understand the singleton pattern structure and how it can be implemented. Singleton pattern provides easy ways for unique object instantiation. In java, it is simple to create a singleton pattern. In the future projects I would be happy to apply singleton pattern.
Total Hours Spent in learning: 12 Hours 30 minutes

Tuesday, April 22, 2008

Xtreme Programming

LEARNING JOURNAL ON XP - WEEK 1

AUTHOR : AIESHATH ADNAN


(this is my first journal, i would like to share it with people who wants to know the basics of Xp)

Date
11/07/2007

What’s Happening
Motivation for learning (problem )----What I think about that (Reflections)
In the second year, I did a project for Information Technology project. This project involved developing an Information System.Inorder to develop the information System, Waterfall model was used. We were able to complete the project. However we faced some problems, like:
• Idealized, does not match reality well.
• Once a stage is finished, some members like the analyst has no more work to do.
• Does not reflect iterative nature of exploratory development.
• Unrealistic to expect accurate requirements so early in project
• System was delivered late in project, delays discovery of serious errors
• Difficult to integrate risk management
• Difficult and expensive to make changes
• Significant administrative overhead, costly for small teams and projects
Since then I have been thinking what could be the model, which I can use to overcome the above-mentioned problems of the waterfall model. Then I came across Extreme Programming (XP), which can be a solution to the problems mentioned above. , I decided to learn about it and here I represent what I learnt.

11/07/2007
What is Extreme programming?(insight solution)
Extreme programming is a software development paradigm encompassing on a set of rules and practices that occur within the context of four framework activities: planning, designing, coding and testing.

11/07/2007 What are the steps in it?(plan of achieving the solutions encountered)

The solution to the problems I faced can be overcome by applying these steps, which are the four framework activities in Extreme programming.

Planning:

The planning phase begins the client providing the functional requirement as a set of user stories. These user stories can be printed or written on card. The user stories include the functions and their priority level to the client. The client can write new user stories at anytime in the development.
The project meets for release planning. The project team evaluates the story an assigns cost, which is measured in development weeks. There by at the end of the meeting a release plan is produced which indicates iteration plans for each individual plan. Once the first project release has been delivered, the Xpers computes the project velocity. The release plans are always modifiable.

Design
The designing of the system architecture follows the KIS (keep it simple) principle. I find that the design phase of XP is very different from in other development methodologies like waterfall model. The software in object-oriented context, XP encourages using the CRC cards. If a difficult design has been identified a spike solution is created. A spike solution is an operational prototype of that portion of the design.. Xp encourages using a construction and a design technique called refactoring. In Xp, the design is viewed as a passing artifact
that can and should be continually modified as the construction follows.

Refactoring is the process of changing a software system in such a way that it does not alter the external behavior of the code yet improves the internal structure. I think that this is unique to XP.

Coding
In Xp before the coding begins, the team should develop a series of unit tests. AS with the unit tests the developer will be able to identify what must be done to pass the unit test.
Again, another unique concept in coding pair programming.Xp recommends that two people work together in the same workstation to create code for a story. During the coding, the developers cannot add anything extra. This means if the developer has something, innovative it cannot be added. Once the pair programmers complete their code, all the codes from other developers are integrated.

Testing
As already indicated in the coding a unit test has to be created before the coding. Just like some of the other development methodologies, Acceptance testing has to be carried out in XP. One or more automated acceptance testing must be created to verify that the user code has been written correctly.

12/07/2007---What is the practical problem associated it?

As with the knowledge I have gained, I discussed it with some friends. They agreed with me to develop a simple Active Ad that analyses the content of a webpage and identifies some key terms.
One of the friends served as the customer, while none of us served as the XP coach. Although I had some knowledge in Xp’s practices and values, I took this opportunity as a challenge, to see how Xp is implemented in real world.
We discussed briefly how the Xp works. There were two user stories. Planning the Game was completed by Production code was written using pair programming.

12/07/2007----Problems identified----
1. Although the customer was always available, there were times that we made assumptions for some parts
2. We also had the difficulty of the concept of the collective ownership: as we were reluctant to fix the errors in the code written by the others.
3. During pair programming, sometimes when one member codes, the other gets bored.
4. As with the integration, most of us tried to collect the codes, rather than integrating and testing it. This brought much confusion during the integration.

No body was confident with the product. As everyone has innovative ways to enhance the product.

15/07/2007---What could be the potential solutions?

Even though the product was developed, I believe that there was only one deficiencies in our application. That is our team’s inadequate introduction to Xp’s Values and practices. Consequently, the following changes could be applied to make it effective.

1. Communicate and get feedback from the customers and the team whenever there is a problem.
2. Make the developers understand that Collective Ownership is something important in Xp.There is no harm in doing that.
3. Allocate time for each developer to work with codes, while the other has to think about the problems that will encounter with the codes. When there is boredom, give sometime for the developer allow the coder to take breaks.
4. IF Xp is a new concept to the team, to start the project choose volunteers

5. Devote some time within the team to discuss in detail the Xp practices and values separated by the team functions. Such as for the developers it is always good to explain the concept of pair programming


13/07/2007---(Knowledge and Learning Acquisition)----

For developers, XP allows to focus on coding and avoid needless paperwork and meetings. It provides a more social atmosphere, more opportunities to learn new skills, and a chance to go home at a decent time each night. It gives you very frequent feelings of achievement, and generally allows you to produce code that you feel good about.
For the Customer (often a Product Manager), XP creates working software faster, and that software tends to have very few defects. It allows you to change your mind whenever you need to, with minimal cost and almost no complaining from the developers. It produces reliable estimates so you can coordinate your schedule easier.
For management, XP delivers working software for less money, and the software is more likely to do what the end users actually want. It cuts risk in a couple ways: 1) It allows you to "pull the plug" on development at almost any time, and still have highly valuable code, and probably even a valuable working (if incomplete) application. 2) It reduces your dependence on individual superstars, and at the same time can improve employee satisfaction and retention