Singleton Pattern

Singleton Pattern is a design pattern that allows a user to create only one object for a class.
There are three things to be followed to create a singleton pattern or a singleton class.

1. The class should implement a private constructor. (This is done so that the user is not allowed to create an object with the help of new operator).

2. The class should have a private static instance of the same class. (If the class name is Book, then there should be a private static object of Book within the Book class).

3. There should be public static factory method called getInstance() to retrieve the private object to the user.

Code Sample:
public Book{

private static Book oneBook = null;

private Book(){
}

public static Book getInstance(){
if (oneBook == null){
oneBook = new Book();
}
return oneBook;
}

}

The above code may be prone to create multiple objects in case of threading. So, in case of threading, use synchroniation.

public static Book getInstance(){
//Thread safe factory method
if(oneBook == null){
synchronized(Book.class){
oneBook = new Book();
}
}

}

Aggregation vs Composition

In normal terms, they both refer to member object but the survival or existence of the member object without the containing class or object or after the lifetime of the containing class or object makes the difference. Aggregation is also known as a 'has a' relationship because the containing object has a member object and the member object can survive or exist without the enclosing or containing class or can have a meaning after the lifetime of the enclosing object also.
Example ('has a'): Room has a table and the table can exist without the room. The table can have meaning without the room also.

Composition is also known as a 'is a part of' or 'is a' relationship because the member object is a part of the containing class and the member object cannot survive or exist outside the enclosing or containing class or doesnt have a meaning after the lifetime of the enclosing object. Composition is used over inheritance when different roles are to be played by a single entity. The 'is a' relation comes in this case.
Example 1 ('is a part of'): Computer Science Department is a part of the College. The Computer Science Department cannot exist without the college and the department has no meaning after the lifetime of the college.
Example 2 ('is a'): A Person is a supervisor. A Person is a husband. Supervisor and husband are the roles played by a single person. The husband role without the person has no meaning or cannot exist and similarly for the supervisor also.

From the above figure, Battery and Smart Phone explain Aggregation while the other relations explain Composition. The Smart Phone has a Battery. The Battery can exist without the Smart Phone and it has a meaning without the Smart Phone. On the other hand, the IMEI Number is a part of the Smart Phone and the existence of the IMEI number completely depends on the existence of the Smart Phone. The IMEI Number has no meaning without the Smart Phone. While the relation between IMEI Number and the Smart Phone explains the 'is a part of' type of composition, the other relation explains the 'is a' type of composition. The Smart Phone, in this case, plays roles at different times. The Smart Phone is a Camera. The Smart Phone is a Web Browser. The Smart Phone is a Music Player. The Music Player role of the Smart Phone cannot exist when the Smart Phone itself is not available.

Thus, Aggregation and Composition are almost the same conceptually but differ in implementation because, the contained or member object should be deleted in case of composition while the member object should not be deleted in case of aggregation.

Generalization vs Specialization

In normal terms, they both refer to inheritance but the way in which it is implemented or looked into makes the difference. If many similar existing objects are combined to form a superclass to do the job of its subclass', then it is known as Generalization while if some new subclasses are created from an existing superclass to do specific job of the superclass, then it is known as specialization. Both concepts can be implemented using inheritance only. But the order of creation of the subclass and the superclass drives the concept name.

The way or perspective of looking also gives the difference between these two concepts. When you look from the perspective of a base class, it is generalization because the base class has functions or operations that may be commonly used by all of its subclasses. When you look from the perspective of the derived class, it is specialization because even though the common functionalities from the super class are available, the derived classes perform their own operations or functions specific to the purpose of their creation.

From the above figure, if you see from the perspective of the Train, then it is Generalization. The common functions or operations of both the Passenger and Goods Trains are put into the Train such as startTrain, stopTrain, fillFuel. That is, the generic operations of any subclass of Train are included in Train.

If you see from the perspective of the subclasses (Passenger Train or Goods Train), then it is Specialization. The common functions of the superclass (Train) are also included with the specific functions of the subclass such as boardPassengers, cleanToilet, fillWater, fillPantryResources in case of Passenger train and loadGoods, unloadGoods in case of Goods train making the subclass, a class for a specific or special function.

Note: In case of Generalization, it is not necessary that the superclass (Train) should know about the existence of its subclasses (Passenger Train and Goods Train). In case of Specialization, the subclass will always know its superclass.

Design Pattern

What is a Design Pattern?
A Design Pattern is a general repeatable solution to a commonly occurring problem in software design. A Design Pattern is not complete. It is just a solution or idea of how to solve the problem. The real solution has to be implemented using any programming language.

How are Design Patterns clasified?
Design Patterns can be classified into 5 types.
1. Fundamental,
2. Creational,
3. Behavioural,
4. Concurrency and
5. Structural.

Why are Design Patterns useful?
Design Patterns are very useful because they have been experimented by many users in the past and a solution is suggested by many. Most of the times, this solution will work, taking into consideration the situational and environmental factors. These design patterns help us in designing an effective system. These design patterns can also lead to blunder when not used in appropriate situations.

References
Design Pattern in Wikipedia

My Experience with Software Design

As per SSAD which i studied in my second year, more time has to be spent on the design of the software and not in the coding.....

I learnt the same in OOAD also in my third year.... I didnt know how much time will be really saved by spending more time in software design than in coding..... Over the last few months, i went crazy on software design and started reading articles and books and journals related to software design.

So, I thought, let me experiment it. So, I started my mobile computing package from SRS. I prepared SRS document, analysis document and then came to the design part. From December 22nd, till february 19th, i was working on the software design for my mobile computing package, the Multiplayer chess. I wasnt able to complete the overall design. The due date for the package was March 30. I was afraid i will not be able to finish the coding if design takes so long. So, i started coding with my partial design document as my base. To my surprise, i finished my coding for the designed portion of my package within 3 days with ease. I continued my coding to extend the features without continuing the design.

At the end of due date, i realized that, i have added just two small features in that one and a half months over the designed portion of the software which i coded in just 3 days. Moreover, in that one and a half month period, i never touched/modified the coding part which was done with design document as base. But those two small features underwent several changes in coding and still those two features work with some bugs in it....

Then i realized the importance of the Software Design. I did design for my software and reviewed it myself frequently and changed it. After a period of time, i froze my design document and i never came across a situation to change/modify the design document. The code from the design document was so stable and robust. It made coding a nothing factor. The latter part of the software which was coded without the design document consumed a lot of time and contained a lot of bugs and left me unsatisfied and my software incomplete.

So, if you are planning to develop a software, create a design document irrespective of programming languages. Do your coding based on the design document. Make your software, a stable and robust and flexible application.