Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Fall 2010/ch1 4e dj

2010-10-30T18:40:42Z

Djfreema: /* Introduction */

=Introduction=
One of the key tenants of object oriented programming is the ability to specify common attributes for like objects. There are two main ways to do this. The first is by enumerating the elements that are in common, while the second involves defining objects in terms of other objects. Each allows the programmer to specify relationships between objects in their program, but the methods for doing this are radically different. The later method (using like objects) is refereed to as Prototype-based, while the former is Class or Set based.[[#References|[1]]]

=Prototypes vs. Sets=
When defining like behavior, the first method of doing this is by listing all the like components as you define the class. This can be done in a few different ways:
*Abstract items in a class definition serve as placeholders that are to be implemented by all implementing classes. These can be methods, fields, or accessors. A class that has abstract items is called an abstract class.
*Interfaces are a type of abstract class that only defines abstract methods. These classes are used as an answer to multiple inheritance in languages such as Java. Interfaces allow a behavior contract to be used to specify how objects interact. A using piece of code can use any implementing object that follows the contract.

However, the second method, prototyping, does not explicitly define any relationships. Instead, new objects are created by taking a object that is to be used as the prototype and extending the new object to change its functionality.

=Creation using each method=
When using classes and set based creation, instances are (usually) bound to their defining classes. This means that when you create a new object, it must match some defined class. The resulting object is then said to be an instance of the class, and will always reference functionality contained in and defined by the object's class.

When using prototyping, however, a object may be created either [[http://en.wikipedia.org/wiki/Ex_nihilo#Computer_science|"ex nihilo"]] or by cloning another object. When creating an object in a language that supports prototyping, methods and variables can be defined at anytime during the life cycle of the object.[[#References|[1]]] The object also contains its own definition of functionality and storage. This fact allows the functionality of any object to be changed after creation. This allows the programmer to create a new object by cloning an existing object and, at runtime, change functions and storage. An example is below:

=Example of prototype based programming in ruby=
The following example of Prototype based programming shows how objects can be reopened and have their methods redefined in ruby

<pre>
def x.hello(arg)
puts "Hello, #{arg}!"
end

x.hello("world") # => "Hello, world!"

#Now we just need to copy existing objects:

y = x.clone()
y.hello("world") # => "Hello, world!"

#The objects are independent, so each of them can redefine methods without worrying about everyone #else:

z = x.clone()

def x.hello(arg)
puts "Guten Tag, #{arg}!"
end

def z.hello(arg)
puts "Goodbye, #{arg}!"
end

x.hello("world") # => "Guten Tag, world!"
y.hello("world") # => "Hello, world!"
z.hello("world") # => "Goodbye, world!"
</pre>
[[#References|[3]]]

=Criticisms of Prototype based programming=
==Classes as types==
Some argue that, like dynamically typed languages, there are issues with dynamic class definitions. The usual three items cited are Correctness, Safety, and Predictability[[#References|[1]]]
*Prototype-based languages are said to be less correct because of the dynamic nature of the objects. It is difficult to check fully if the object or method you have is what you expect.
*Prototype-based languages are cited as being unsafe because little checking is done at run time on the objects
*Prototype-based languages are also accused of being highly unpredictable due to the lack of a formal definition of the class structure of an underlying object.

==Compiler speed==
Compilers written for prototype-based languages are more complex than those written for class based languages.[[#References|[1]]] This raises concerns over efficiency at run time.

=References=

[[#References|[1]]] Wikipedia. (2010, October) Wikipedia - Prototype Based Programming. [Online]. http://en.wikipedia.org/wiki/Prototype-based_programming

[[#References|[2]]] C2. (2010, October) Prototype Based Programming. [Online]. http://www.c2.com/cgi/wiki?PrototypeBasedProgramming

[[#References|[3]]] taw's blog. (2010, October) Prototype-based Ruby. [Online]. http://t-a-w.blogspot.com/2006/10/prototype-based-ruby.html

CSC/ECE 517 Fall 2010/ch1 4e dj

2010-10-30T18:40:33Z

Djfreema: /* Creation using each method */

=Introduction=
One of the key tenants of object oriented programming is the ability to specify common attributes for like objects. There are two main ways to do this. The first is by enumerating the elements that are in common, while the second involves defining objects in terms of other objects. Each allows the programmer to specify relationships between objects in their program, but the methods for doing this are radically different. The later method (using like objects) is refereed to as Prototype-based, while the former is Class or Set based.

=Prototypes vs. Sets=
When defining like behavior, the first method of doing this is by listing all the like components as you define the class. This can be done in a few different ways:
*Abstract items in a class definition serve as placeholders that are to be implemented by all implementing classes. These can be methods, fields, or accessors. A class that has abstract items is called an abstract class.
*Interfaces are a type of abstract class that only defines abstract methods. These classes are used as an answer to multiple inheritance in languages such as Java. Interfaces allow a behavior contract to be used to specify how objects interact. A using piece of code can use any implementing object that follows the contract.

However, the second method, prototyping, does not explicitly define any relationships. Instead, new objects are created by taking a object that is to be used as the prototype and extending the new object to change its functionality.

=Creation using each method=
When using classes and set based creation, instances are (usually) bound to their defining classes. This means that when you create a new object, it must match some defined class. The resulting object is then said to be an instance of the class, and will always reference functionality contained in and defined by the object's class.

When using prototyping, however, a object may be created either [[http://en.wikipedia.org/wiki/Ex_nihilo#Computer_science|"ex nihilo"]] or by cloning another object. When creating an object in a language that supports prototyping, methods and variables can be defined at anytime during the life cycle of the object.[[#References|[1]]] The object also contains its own definition of functionality and storage. This fact allows the functionality of any object to be changed after creation. This allows the programmer to create a new object by cloning an existing object and, at runtime, change functions and storage. An example is below:

=Example of prototype based programming in ruby=
The following example of Prototype based programming shows how objects can be reopened and have their methods redefined in ruby

<pre>
def x.hello(arg)
puts "Hello, #{arg}!"
end

x.hello("world") # => "Hello, world!"

#Now we just need to copy existing objects:

y = x.clone()
y.hello("world") # => "Hello, world!"

#The objects are independent, so each of them can redefine methods without worrying about everyone #else:

z = x.clone()

def x.hello(arg)
puts "Guten Tag, #{arg}!"
end

def z.hello(arg)
puts "Goodbye, #{arg}!"
end

x.hello("world") # => "Guten Tag, world!"
y.hello("world") # => "Hello, world!"
z.hello("world") # => "Goodbye, world!"
</pre>
[[#References|[3]]]

=Criticisms of Prototype based programming=
==Classes as types==
Some argue that, like dynamically typed languages, there are issues with dynamic class definitions. The usual three items cited are Correctness, Safety, and Predictability[[#References|[1]]]
*Prototype-based languages are said to be less correct because of the dynamic nature of the objects. It is difficult to check fully if the object or method you have is what you expect.
*Prototype-based languages are cited as being unsafe because little checking is done at run time on the objects
*Prototype-based languages are also accused of being highly unpredictable due to the lack of a formal definition of the class structure of an underlying object.

==Compiler speed==
Compilers written for prototype-based languages are more complex than those written for class based languages.[[#References|[1]]] This raises concerns over efficiency at run time.

=References=

[[#References|[1]]] Wikipedia. (2010, October) Wikipedia - Prototype Based Programming. [Online]. http://en.wikipedia.org/wiki/Prototype-based_programming

[[#References|[2]]] C2. (2010, October) Prototype Based Programming. [Online]. http://www.c2.com/cgi/wiki?PrototypeBasedProgramming

[[#References|[3]]] taw's blog. (2010, October) Prototype-based Ruby. [Online]. http://t-a-w.blogspot.com/2006/10/prototype-based-ruby.html

CSC/ECE 517 Fall 2010/ch1 4e dj

2010-10-30T18:39:14Z

Djfreema: /* Example of prototype based programming in ruby */

=Introduction=
One of the key tenants of object oriented programming is the ability to specify common attributes for like objects. There are two main ways to do this. The first is by enumerating the elements that are in common, while the second involves defining objects in terms of other objects. Each allows the programmer to specify relationships between objects in their program, but the methods for doing this are radically different. The later method (using like objects) is refereed to as Prototype-based, while the former is Class or Set based.

=Prototypes vs. Sets=
When defining like behavior, the first method of doing this is by listing all the like components as you define the class. This can be done in a few different ways:
*Abstract items in a class definition serve as placeholders that are to be implemented by all implementing classes. These can be methods, fields, or accessors. A class that has abstract items is called an abstract class.
*Interfaces are a type of abstract class that only defines abstract methods. These classes are used as an answer to multiple inheritance in languages such as Java. Interfaces allow a behavior contract to be used to specify how objects interact. A using piece of code can use any implementing object that follows the contract.

However, the second method, prototyping, does not explicitly define any relationships. Instead, new objects are created by taking a object that is to be used as the prototype and extending the new object to change its functionality.

=Creation using each method=
When using classes and set based creation, instances are (usually) bound to their defining classes. This means that when you create a new object, it must match some defined class. The resulting object is then said to be an instance of the class, and will always reference functionality contained in and defined by the object's class.

When using prototyping, however, a object may be created either [[http://en.wikipedia.org/wiki/Ex_nihilo#Computer_science|"ex nihilo"]] or by cloning another object. When creating an object in a language that supports prototyping, methods and variables can be defined at anytime during the life cycle of the object. The object also contains its own definition of functionality and storage. This fact allows the functionality of any object to be changed after creation. This allows the programmer to create a new object by cloning an existing object and, at runtime, change functions and storage. An example is below:

=Example of prototype based programming in ruby=
The following example of Prototype based programming shows how objects can be reopened and have their methods redefined in ruby

<pre>
def x.hello(arg)
puts "Hello, #{arg}!"
end

x.hello("world") # => "Hello, world!"

#Now we just need to copy existing objects:

y = x.clone()
y.hello("world") # => "Hello, world!"

#The objects are independent, so each of them can redefine methods without worrying about everyone #else:

z = x.clone()

def x.hello(arg)
puts "Guten Tag, #{arg}!"
end

def z.hello(arg)
puts "Goodbye, #{arg}!"
end

x.hello("world") # => "Guten Tag, world!"
y.hello("world") # => "Hello, world!"
z.hello("world") # => "Goodbye, world!"
</pre>
[[#References|[3]]]

=Criticisms of Prototype based programming=
==Classes as types==
Some argue that, like dynamically typed languages, there are issues with dynamic class definitions. The usual three items cited are Correctness, Safety, and Predictability[[#References|[1]]]
*Prototype-based languages are said to be less correct because of the dynamic nature of the objects. It is difficult to check fully if the object or method you have is what you expect.
*Prototype-based languages are cited as being unsafe because little checking is done at run time on the objects
*Prototype-based languages are also accused of being highly unpredictable due to the lack of a formal definition of the class structure of an underlying object.

==Compiler speed==
Compilers written for prototype-based languages are more complex than those written for class based languages.[[#References|[1]]] This raises concerns over efficiency at run time.

=References=

[[#References|[1]]] Wikipedia. (2010, October) Wikipedia - Prototype Based Programming. [Online]. http://en.wikipedia.org/wiki/Prototype-based_programming

[[#References|[2]]] C2. (2010, October) Prototype Based Programming. [Online]. http://www.c2.com/cgi/wiki?PrototypeBasedProgramming

[[#References|[3]]] taw's blog. (2010, October) Prototype-based Ruby. [Online]. http://t-a-w.blogspot.com/2006/10/prototype-based-ruby.html

CSC/ECE 517 Fall 2010/ch1 4e dj

2010-10-30T18:36:23Z

Djfreema: /* Example of prototype based programming in ruby */

=Introduction=
One of the key tenants of object oriented programming is the ability to specify common attributes for like objects. There are two main ways to do this. The first is by enumerating the elements that are in common, while the second involves defining objects in terms of other objects. Each allows the programmer to specify relationships between objects in their program, but the methods for doing this are radically different. The later method (using like objects) is refereed to as Prototype-based, while the former is Class or Set based.

=Prototypes vs. Sets=
When defining like behavior, the first method of doing this is by listing all the like components as you define the class. This can be done in a few different ways:
*Abstract items in a class definition serve as placeholders that are to be implemented by all implementing classes. These can be methods, fields, or accessors. A class that has abstract items is called an abstract class.
*Interfaces are a type of abstract class that only defines abstract methods. These classes are used as an answer to multiple inheritance in languages such as Java. Interfaces allow a behavior contract to be used to specify how objects interact. A using piece of code can use any implementing object that follows the contract.

However, the second method, prototyping, does not explicitly define any relationships. Instead, new objects are created by taking a object that is to be used as the prototype and extending the new object to change its functionality.

=Creation using each method=
When using classes and set based creation, instances are (usually) bound to their defining classes. This means that when you create a new object, it must match some defined class. The resulting object is then said to be an instance of the class, and will always reference functionality contained in and defined by the object's class.

When using prototyping, however, a object may be created either [[http://en.wikipedia.org/wiki/Ex_nihilo#Computer_science|"ex nihilo"]] or by cloning another object. When creating an object in a language that supports prototyping, methods and variables can be defined at anytime during the life cycle of the object. The object also contains its own definition of functionality and storage. This fact allows the functionality of any object to be changed after creation. This allows the programmer to create a new object by cloning an existing object and, at runtime, change functions and storage. An example is below:

=Example of prototype based programming in ruby=
<pre>
def x.hello(arg)
puts "Hello, #{arg}!"
end

x.hello("world") # => "Hello, world!"

#Now we just need to copy existing objects:

y = x.clone()
y.hello("world") # => "Hello, world!"

#The objects are independent, so each of them can redefine methods without worrying about everyone #else:

z = x.clone()

def x.hello(arg)
puts "Guten Tag, #{arg}!"
end

def z.hello(arg)
puts "Goodbye, #{arg}!"
end

x.hello("world") # => "Guten Tag, world!"
y.hello("world") # => "Hello, world!"
z.hello("world") # => "Goodbye, world!"
</pre>
[[#References|[3]]]

=Criticisms of Prototype based programming=
==Classes as types==
Some argue that, like dynamically typed languages, there are issues with dynamic class definitions. The usual three items cited are Correctness, Safety, and Predictability[[#References|[1]]]
*Prototype-based languages are said to be less correct because of the dynamic nature of the objects. It is difficult to check fully if the object or method you have is what you expect.
*Prototype-based languages are cited as being unsafe because little checking is done at run time on the objects
*Prototype-based languages are also accused of being highly unpredictable due to the lack of a formal definition of the class structure of an underlying object.

==Compiler speed==
Compilers written for prototype-based languages are more complex than those written for class based languages.[[#References|[1]]] This raises concerns over efficiency at run time.

=References=

[[#References|[1]]] Wikipedia. (2010, October) Wikipedia - Prototype Based Programming. [Online]. http://en.wikipedia.org/wiki/Prototype-based_programming

[[#References|[2]]] C2. (2010, October) Prototype Based Programming. [Online]. http://www.c2.com/cgi/wiki?PrototypeBasedProgramming

[[#References|[3]]] taw's blog. (2010, October) Prototype-based Ruby. [Online]. http://t-a-w.blogspot.com/2006/10/prototype-based-ruby.html

CSC/ECE 517 Fall 2010/ch1 4e dj

2010-10-30T18:35:57Z

Djfreema: /* Example of prototype based programming in ruby */

=Introduction=
One of the key tenants of object oriented programming is the ability to specify common attributes for like objects. There are two main ways to do this. The first is by enumerating the elements that are in common, while the second involves defining objects in terms of other objects. Each allows the programmer to specify relationships between objects in their program, but the methods for doing this are radically different. The later method (using like objects) is refereed to as Prototype-based, while the former is Class or Set based.

=Prototypes vs. Sets=
When defining like behavior, the first method of doing this is by listing all the like components as you define the class. This can be done in a few different ways:
*Abstract items in a class definition serve as placeholders that are to be implemented by all implementing classes. These can be methods, fields, or accessors. A class that has abstract items is called an abstract class.
*Interfaces are a type of abstract class that only defines abstract methods. These classes are used as an answer to multiple inheritance in languages such as Java. Interfaces allow a behavior contract to be used to specify how objects interact. A using piece of code can use any implementing object that follows the contract.

However, the second method, prototyping, does not explicitly define any relationships. Instead, new objects are created by taking a object that is to be used as the prototype and extending the new object to change its functionality.

=Creation using each method=
When using classes and set based creation, instances are (usually) bound to their defining classes. This means that when you create a new object, it must match some defined class. The resulting object is then said to be an instance of the class, and will always reference functionality contained in and defined by the object's class.

When using prototyping, however, a object may be created either [[http://en.wikipedia.org/wiki/Ex_nihilo#Computer_science|"ex nihilo"]] or by cloning another object. When creating an object in a language that supports prototyping, methods and variables can be defined at anytime during the life cycle of the object. The object also contains its own definition of functionality and storage. This fact allows the functionality of any object to be changed after creation. This allows the programmer to create a new object by cloning an existing object and, at runtime, change functions and storage. An example is below:

=Example of prototype based programming in ruby=
<pre>
def x.hello(arg)
puts "Hello, #{arg}!"
end

x.hello("world") # => "Hello, world!"

#Now we just need to copy existing objects:

y = x.clone()
y.hello("world") # => "Hello, world!"

#The objects are independent, so each of them can redefine methods without worrying about everyone #else:

z = x.clone()

def x.hello(arg)
puts "Guten Tag, #{arg}!"
end

def z.hello(arg)
puts "Goodbye, #{arg}!"
end

x.hello("world") # => "Guten Tag, world!"
y.hello("world") # => "Hello, world!"
z.hello("world") # => "Goodbye, world!"
</pre>

=Criticisms of Prototype based programming=
==Classes as types==
Some argue that, like dynamically typed languages, there are issues with dynamic class definitions. The usual three items cited are Correctness, Safety, and Predictability[[#References|[1]]]
*Prototype-based languages are said to be less correct because of the dynamic nature of the objects. It is difficult to check fully if the object or method you have is what you expect.
*Prototype-based languages are cited as being unsafe because little checking is done at run time on the objects
*Prototype-based languages are also accused of being highly unpredictable due to the lack of a formal definition of the class structure of an underlying object.

==Compiler speed==
Compilers written for prototype-based languages are more complex than those written for class based languages.[[#References|[1]]] This raises concerns over efficiency at run time.

=References=

[[#References|[1]]] Wikipedia. (2010, October) Wikipedia - Prototype Based Programming. [Online]. http://en.wikipedia.org/wiki/Prototype-based_programming

[[#References|[2]]] C2. (2010, October) Prototype Based Programming. [Online]. http://www.c2.com/cgi/wiki?PrototypeBasedProgramming

[[#References|[3]]] taw's blog. (2010, October) Prototype-based Ruby. [Online]. http://t-a-w.blogspot.com/2006/10/prototype-based-ruby.html

CSC/ECE 517 Fall 2010/ch1 4e dj

2010-10-30T18:35:35Z

Djfreema: /* Criticisms of Prototype based programming */

=Introduction=
One of the key tenants of object oriented programming is the ability to specify common attributes for like objects. There are two main ways to do this. The first is by enumerating the elements that are in common, while the second involves defining objects in terms of other objects. Each allows the programmer to specify relationships between objects in their program, but the methods for doing this are radically different. The later method (using like objects) is refereed to as Prototype-based, while the former is Class or Set based.

=Prototypes vs. Sets=
When defining like behavior, the first method of doing this is by listing all the like components as you define the class. This can be done in a few different ways:
*Abstract items in a class definition serve as placeholders that are to be implemented by all implementing classes. These can be methods, fields, or accessors. A class that has abstract items is called an abstract class.
*Interfaces are a type of abstract class that only defines abstract methods. These classes are used as an answer to multiple inheritance in languages such as Java. Interfaces allow a behavior contract to be used to specify how objects interact. A using piece of code can use any implementing object that follows the contract.

However, the second method, prototyping, does not explicitly define any relationships. Instead, new objects are created by taking a object that is to be used as the prototype and extending the new object to change its functionality.

=Creation using each method=
When using classes and set based creation, instances are (usually) bound to their defining classes. This means that when you create a new object, it must match some defined class. The resulting object is then said to be an instance of the class, and will always reference functionality contained in and defined by the object's class.

When using prototyping, however, a object may be created either [[http://en.wikipedia.org/wiki/Ex_nihilo#Computer_science|"ex nihilo"]] or by cloning another object. When creating an object in a language that supports prototyping, methods and variables can be defined at anytime during the life cycle of the object. The object also contains its own definition of functionality and storage. This fact allows the functionality of any object to be changed after creation. This allows the programmer to create a new object by cloning an existing object and, at runtime, change functions and storage. An example is below:

=Example of prototype based programming in ruby=
<pre>
def x.hello(arg)
puts "Hello, #{arg}!"
end

x.hello("world") # => "Hello, world!"

Now we just need to copy existing objects:

y = x.clone()
y.hello("world") # => "Hello, world!"

The objects are independent, so each of them can redefine methods without worrying about everyone else:

z = x.clone()

def x.hello(arg)
puts "Guten Tag, #{arg}!"
end

def z.hello(arg)
puts "Goodbye, #{arg}!"
end

x.hello("world") # => "Guten Tag, world!"
y.hello("world") # => "Hello, world!"
z.hello("world") # => "Goodbye, world!"
</pre>

=Criticisms of Prototype based programming=
==Classes as types==
Some argue that, like dynamically typed languages, there are issues with dynamic class definitions. The usual three items cited are Correctness, Safety, and Predictability[[#References|[1]]]
*Prototype-based languages are said to be less correct because of the dynamic nature of the objects. It is difficult to check fully if the object or method you have is what you expect.
*Prototype-based languages are cited as being unsafe because little checking is done at run time on the objects
*Prototype-based languages are also accused of being highly unpredictable due to the lack of a formal definition of the class structure of an underlying object.

==Compiler speed==
Compilers written for prototype-based languages are more complex than those written for class based languages.[[#References|[1]]] This raises concerns over efficiency at run time.

=References=

[[#References|[1]]] Wikipedia. (2010, October) Wikipedia - Prototype Based Programming. [Online]. http://en.wikipedia.org/wiki/Prototype-based_programming

[[#References|[2]]] C2. (2010, October) Prototype Based Programming. [Online]. http://www.c2.com/cgi/wiki?PrototypeBasedProgramming

[[#References|[3]]] taw's blog. (2010, October) Prototype-based Ruby. [Online]. http://t-a-w.blogspot.com/2006/10/prototype-based-ruby.html

CSC/ECE 517 Fall 2010/ch1 4e dj

2010-10-30T18:35:06Z

Djfreema: /* References */

=Introduction=
One of the key tenants of object oriented programming is the ability to specify common attributes for like objects. There are two main ways to do this. The first is by enumerating the elements that are in common, while the second involves defining objects in terms of other objects. Each allows the programmer to specify relationships between objects in their program, but the methods for doing this are radically different. The later method (using like objects) is refereed to as Prototype-based, while the former is Class or Set based.

=Prototypes vs. Sets=
When defining like behavior, the first method of doing this is by listing all the like components as you define the class. This can be done in a few different ways:
*Abstract items in a class definition serve as placeholders that are to be implemented by all implementing classes. These can be methods, fields, or accessors. A class that has abstract items is called an abstract class.
*Interfaces are a type of abstract class that only defines abstract methods. These classes are used as an answer to multiple inheritance in languages such as Java. Interfaces allow a behavior contract to be used to specify how objects interact. A using piece of code can use any implementing object that follows the contract.

However, the second method, prototyping, does not explicitly define any relationships. Instead, new objects are created by taking a object that is to be used as the prototype and extending the new object to change its functionality.

=Creation using each method=
When using classes and set based creation, instances are (usually) bound to their defining classes. This means that when you create a new object, it must match some defined class. The resulting object is then said to be an instance of the class, and will always reference functionality contained in and defined by the object's class.

When using prototyping, however, a object may be created either [[http://en.wikipedia.org/wiki/Ex_nihilo#Computer_science|"ex nihilo"]] or by cloning another object. When creating an object in a language that supports prototyping, methods and variables can be defined at anytime during the life cycle of the object. The object also contains its own definition of functionality and storage. This fact allows the functionality of any object to be changed after creation. This allows the programmer to create a new object by cloning an existing object and, at runtime, change functions and storage. An example is below:

=Example of prototype based programming in ruby=
<pre>
def x.hello(arg)
puts "Hello, #{arg}!"
end

x.hello("world") # => "Hello, world!"

Now we just need to copy existing objects:

y = x.clone()
y.hello("world") # => "Hello, world!"

The objects are independent, so each of them can redefine methods without worrying about everyone else:

z = x.clone()

def x.hello(arg)
puts "Guten Tag, #{arg}!"
end

def z.hello(arg)
puts "Goodbye, #{arg}!"
end

x.hello("world") # => "Guten Tag, world!"
y.hello("world") # => "Hello, world!"
z.hello("world") # => "Goodbye, world!"
</pre>

=Criticisms of Prototype based programming=
==Classes as types==
Some argue that, like dynamically typed languages, there are issues with dynamic class definitions. The usual three items cited are Correctness, Safety, and Predictability
*Prototype-based languages are said to be less correct because of the dynamic nature of the objects. It is difficult to check fully if the object or method you have is what you expect.
*Prototype-based languages are cited as being unsafe because little checking is done at run time on the objects
*Prototype-based languages are also accused of being highly unpredictable due to the lack of a formal definition of the class structure of an underlying object.

==Compiler speed==
Compilers written for prototype-based languages are more complex than those written for class based languages. This raises concerns over efficiency at run time.

=References=

[[#References|[1]]] Wikipedia. (2010, October) Wikipedia - Prototype Based Programming. [Online]. http://en.wikipedia.org/wiki/Prototype-based_programming

[[#References|[2]]] C2. (2010, October) Prototype Based Programming. [Online]. http://www.c2.com/cgi/wiki?PrototypeBasedProgramming

[[#References|[3]]] taw's blog. (2010, October) Prototype-based Ruby. [Online]. http://t-a-w.blogspot.com/2006/10/prototype-based-ruby.html

CSC/ECE 517 Fall 2010/ch1 4e dj

2010-10-30T02:18:03Z

Djfreema: /* Negatives of Prototype based programming */

=Introduction=
One of the key tenants of object oriented programming is the ability to specify common attributes for like objects. There are two main ways to do this. The first is by enumerating the elements that are in common, while the second involves defining objects in terms of other objects. Each allows the programmer to specify relationships between objects in their program, but the methods for doing this are radically different. The later method (using like objects) is refereed to as Prototype-based, while the former is Class or Set based.

=Prototypes vs. Sets=
When defining like behavior, the first method of doing this is by listing all the like components as you define the class. This can be done in a few different ways:
*Abstract items in a class definition serve as placeholders that are to be implemented by all implementing classes. These can be methods, fields, or accessors. A class that has abstract items is called an abstract class.
*Interfaces are a type of abstract class that only defines abstract methods. These classes are used as an answer to multiple inheritance in languages such as Java. Interfaces allow a behavior contract to be used to specify how objects interact. A using piece of code can use any implementing object that follows the contract.

However, the second method, prototyping, does not explicitly define any relationships. Instead, new objects are created by taking a object that is to be used as the prototype and extending the new object to change its functionality.

=Creation using each method=
When using classes and set based creation, instances are (usually) bound to their defining classes. This means that when you create a new object, it must match some defined class. The resulting object is then said to be an instance of the class, and will always reference functionality contained in and defined by the object's class.

When using prototyping, however, a object may be created either [[http://en.wikipedia.org/wiki/Ex_nihilo#Computer_science|"ex nihilo"]] or by cloning another object. When creating an object in a language that supports prototyping, methods and variables can be defined at anytime during the life cycle of the object. The object also contains its own definition of functionality and storage. This fact allows the functionality of any object to be changed after creation. This allows the programmer to create a new object by cloning an existing object and, at runtime, change functions and storage. An example is below:

=Example of prototype based programming in ruby=
<pre>
def x.hello(arg)
puts "Hello, #{arg}!"
end

x.hello("world") # => "Hello, world!"

Now we just need to copy existing objects:

y = x.clone()
y.hello("world") # => "Hello, world!"

The objects are independent, so each of them can redefine methods without worrying about everyone else:

z = x.clone()

def x.hello(arg)
puts "Guten Tag, #{arg}!"
end

def z.hello(arg)
puts "Goodbye, #{arg}!"
end

x.hello("world") # => "Guten Tag, world!"
y.hello("world") # => "Hello, world!"
z.hello("world") # => "Goodbye, world!"
</pre>

=Criticisms of Prototype based programming=
==Classes as types==
Some argue that, like dynamically typed languages, there are issues with dynamic class definitions. The usual three items cited are Correctness, Safety, and Predictability
*Prototype-based languages are said to be less correct because of the dynamic nature of the objects. It is difficult to check fully if the object or method you have is what you expect.
*Prototype-based languages are cited as being unsafe because little checking is done at run time on the objects
*Prototype-based languages are also accused of being highly unpredictable due to the lack of a formal definition of the class structure of an underlying object.

==Compiler speed==
Compilers written for prototype-based languages are more complex than those written for class based languages. This raises concerns over efficiency at run time.

=References=

http://www.c2.com/cgi/wiki?PrototypeBasedProgramming
http://en.wikipedia.org/wiki/Prototype-based_programming
http://t-a-w.blogspot.com/2006/10/prototype-based-ruby.html

CSC/ECE 517 Fall 2010/ch1 4e dj

2010-10-30T02:10:12Z

Djfreema:

=Introduction=
One of the key tenants of object oriented programming is the ability to specify common attributes for like objects. There are two main ways to do this. The first is by enumerating the elements that are in common, while the second involves defining objects in terms of other objects. Each allows the programmer to specify relationships between objects in their program, but the methods for doing this are radically different. The later method (using like objects) is refereed to as Prototype-based, while the former is Class or Set based.

=Prototypes vs. Sets=
When defining like behavior, the first method of doing this is by listing all the like components as you define the class. This can be done in a few different ways:
*Abstract items in a class definition serve as placeholders that are to be implemented by all implementing classes. These can be methods, fields, or accessors. A class that has abstract items is called an abstract class.
*Interfaces are a type of abstract class that only defines abstract methods. These classes are used as an answer to multiple inheritance in languages such as Java. Interfaces allow a behavior contract to be used to specify how objects interact. A using piece of code can use any implementing object that follows the contract.

However, the second method, prototyping, does not explicitly define any relationships. Instead, new objects are created by taking a object that is to be used as the prototype and extending the new object to change its functionality.

=Creation using each method=
When using classes and set based creation, instances are (usually) bound to their defining classes. This means that when you create a new object, it must match some defined class. The resulting object is then said to be an instance of the class, and will always reference functionality contained in and defined by the object's class.

When using prototyping, however, a object may be created either [[http://en.wikipedia.org/wiki/Ex_nihilo#Computer_science|"ex nihilo"]] or by cloning another object. When creating an object in a language that supports prototyping, methods and variables can be defined at anytime during the life cycle of the object. The object also contains its own definition of functionality and storage. This fact allows the functionality of any object to be changed after creation. This allows the programmer to create a new object by cloning an existing object and, at runtime, change functions and storage. An example is below:

=Example of prototype based programming in ruby=
<pre>
def x.hello(arg)
puts "Hello, #{arg}!"
end

x.hello("world") # => "Hello, world!"

Now we just need to copy existing objects:

y = x.clone()
y.hello("world") # => "Hello, world!"

The objects are independent, so each of them can redefine methods without worrying about everyone else:

z = x.clone()

def x.hello(arg)
puts "Guten Tag, #{arg}!"
end

def z.hello(arg)
puts "Goodbye, #{arg}!"
end

x.hello("world") # => "Guten Tag, world!"
y.hello("world") # => "Hello, world!"
z.hello("world") # => "Goodbye, world!"
</pre>

=Negatives of Prototype based programming=

Compilers written for prototype languages are more complex than those written for class based languages. This raises concerns over efficiency at run time.

=References=

http://www.c2.com/cgi/wiki?PrototypeBasedProgramming
http://en.wikipedia.org/wiki/Prototype-based_programming
http://t-a-w.blogspot.com/2006/10/prototype-based-ruby.html

CSC/ECE 517 Fall 2010/ch1 4e dj

2010-10-30T02:08:28Z

Djfreema: /* References */

=Introduction=
One of the key tenants of object oriented programming is the ability to specify common attributes for like objects. There are two main ways to do this. The first is by enumerating the elements that are in common, while the second involves defining objects in terms of other objects. Each allows the programmer to specify relationships between objects in their program, but the methods for doing this are radically different. The later method (using like objects) is refereed to as Prototype-based, while the former is Class or Set based.

=Prototypes vs. Sets=
When defining like behavior, the first method of doing this is by listing all the like components as you define the class. This can be done in a few different ways:
*Abstract items in a class definition serve as placeholders that are to be implemented by all implementing classes. These can be methods, fields, or accessors. A class that has abstract items is called an abstract class.
*Interfaces are a type of abstract class that only defines abstract methods. These classes are used as an answer to multiple inheritance in languages such as Java. Interfaces allow a behavior contract to be used to specify how objects interact. A using piece of code can use any implementing object that follows the contract.

However, the second method, prototyping, does not explicitly define any relationships. Instead, new objects are created by taking a object that is to be used as the prototype and extending the new object to change its functionality.

=Creation using each method=
When using classes and set based creation, instances are (usually) bound to their defining classes. This means that when you create a new object, it must match some defined class. The resulting object is then said to be an instance of the class, and will always reference functionality contained in and defined by the object's class.

When using prototyping, however, a object may be created either [[http://en.wikipedia.org/wiki/Ex_nihilo#Computer_science|"ex nihilo"]] or by cloning another object. When creating an object in a language that supports prototyping, methods and variables can be defined at anytime during the life cycle of the object. The object also contains its own definition of functionality and storage. This fact allows the functionality of any object to be changed after creation. This allows the programmer to create a new object by cloning an existing object and, at runtime, change functions and storage. An example is below:

=Inheritance in each method=
A class based design requires that all relationships are created explicitly in the source. This means that for a class to be a child of another, that relationship must be explicitly stated in the source at compile time.

An object may have its functionality extended during execution by inclusion of a prototype. This means that a object can be given any aspect while the code is executing. See [[Unbounded Polymorphism]]

=Negatives of Prototype based programming=

Compilers written for prototype languages are more complex than those written for class based languages. This raises concerns over efficiency at run time.

=References=

http://www.c2.com/cgi/wiki?PrototypeBasedProgramming
http://en.wikipedia.org/wiki/Prototype-based_programming
http://t-a-w.blogspot.com/2006/10/prototype-based-ruby.html

CSC/ECE 517 Fall 2010/ch1 4e dj

2010-10-30T02:07:19Z

Djfreema: /* Creation using each method */

=Introduction=
One of the key tenants of object oriented programming is the ability to specify common attributes for like objects. There are two main ways to do this. The first is by enumerating the elements that are in common, while the second involves defining objects in terms of other objects. Each allows the programmer to specify relationships between objects in their program, but the methods for doing this are radically different. The later method (using like objects) is refereed to as Prototype-based, while the former is Class or Set based.

=Prototypes vs. Sets=
When defining like behavior, the first method of doing this is by listing all the like components as you define the class. This can be done in a few different ways:
*Abstract items in a class definition serve as placeholders that are to be implemented by all implementing classes. These can be methods, fields, or accessors. A class that has abstract items is called an abstract class.
*Interfaces are a type of abstract class that only defines abstract methods. These classes are used as an answer to multiple inheritance in languages such as Java. Interfaces allow a behavior contract to be used to specify how objects interact. A using piece of code can use any implementing object that follows the contract.

However, the second method, prototyping, does not explicitly define any relationships. Instead, new objects are created by taking a object that is to be used as the prototype and extending the new object to change its functionality.

=Creation using each method=
When using classes and set based creation, instances are (usually) bound to their defining classes. This means that when you create a new object, it must match some defined class. The resulting object is then said to be an instance of the class, and will always reference functionality contained in and defined by the object's class.

When using prototyping, however, a object may be created either [[http://en.wikipedia.org/wiki/Ex_nihilo#Computer_science|"ex nihilo"]] or by cloning another object. When creating an object in a language that supports prototyping, methods and variables can be defined at anytime during the life cycle of the object. The object also contains its own definition of functionality and storage. This fact allows the functionality of any object to be changed after creation. This allows the programmer to create a new object by cloning an existing object and, at runtime, change functions and storage. An example is below:

=Inheritance in each method=
A class based design requires that all relationships are created explicitly in the source. This means that for a class to be a child of another, that relationship must be explicitly stated in the source at compile time.

An object may have its functionality extended during execution by inclusion of a prototype. This means that a object can be given any aspect while the code is executing. See [[Unbounded Polymorphism]]

=Negatives of Prototype based programming=

Compilers written for prototype languages are more complex than those written for class based languages. This raises concerns over efficiency at run time.

=References=

http://www.c2.com/cgi/wiki?PrototypeBasedProgramming
http://en.wikipedia.org/wiki/Prototype-based_programming

CSC/ECE 517 Fall 2010/ch1 4e dj

2010-10-30T01:55:12Z

Djfreema: Re worded stuff

CSC/ECE 517 Fall 2010/ch1 4e dj

2010-10-20T20:23:23Z

Djfreema: Expanded article

Page Stub for Dzoba and Jeremy for Prototype-based programming

=Introduction=
Prototype based programming is centered around the idea of developing object oriented code by developing functionality at the object level, and then abstracting the code into prototypes. This allows the programmer the ability to develop objects without the overhead of determining class relations, associations, and requirements.

=Prototypes vs. classes=
A class is a definition of an objects behavior and data fields. This definition generally does not change throughout the execution of the code.

A prototype is an object that is to be used as a basis for developing another object. Not only does a prototype contain data, but it also contains behaviors for the object.

=Creation using each method=
A class can be created through its constructor. This restricts creation to explicit calls to the new method of the class, and prevents changing the objects behavior after the object is instantiated.

A prototype may be created either ''[[ex nihilo]]'' or by cloning another class.

=Inheritance in each method=
A class based design requires that all relationships are created explicitly in the source. This means that for a class to be a child of another, that relationship must be explicitly stated in the source at compile time.

An object may have its functionality extended during execution by inclusion of a prototype. This means that a object can be given any aspect while the code is executing. See [[Unbounded Polymorphism]]

http://www.c2.com/cgi/wiki?PrototypeBasedProgramming
http://en.wikipedia.org/wiki/Prototype-based_programming

CSC/ECE 517 Fall 2010/ch1 4e dj

2010-10-20T07:29:02Z

Djfreema:

CSC/ECE 517 Fall 2010/ch1 4e dj

2010-10-19T20:19:17Z

Djfreema:

Page Stub for Dzoba and Jeremy for Prototype-based programming

CSC/ECE 517 Fall 2010/ch3 3f lj

2010-10-14T02:30:34Z

Djfreema: /* Singleton pattern */

'''Singleton Pattern in Static and Dynamic languages'''

=Singleton pattern=

A [http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29| design pattern], like singleton, is a way for a software developer to handle situations using a known solution that has been proven to be effective in the past. Design patterns also make communicating ideas and concepts between programmers more efficient and understandable.

In the Singleton design pattern we create a single instance of a Singleton class. Any instantiation of that Singleton class references the same instance of the class. The pattern also provides a global point of access for the functionality contained in the sole instance of the class.

===Class Diagram===
[[Image:IC73826.gif|500px|center]]

This diagram is a Universal Modeling Languages (UML) diagram of how a Singleton class would look if implemented in Java.
===Sequence Diagram===
[[Image:CR2.gif|500px|center]]
This diagram illustrates how the Singleton class creates an instance of the Singleton object. The client classes then create instances of the Singleton class which handles access to the Singleton object.

=Implementation=
When this pattern is implemented then it must only have one instantiation of a class and that class must satisfy the global access principles. The pattern requires a mechanism to access the singleton class without instantiating another class object and a mechanism to persist the value of class members among class objects. [[#References|[1]]]

==Creating the instance==
===Early Instantiation===
The instance can be created with a static constructor in static languages. (See the java example below) This means that the single instance is created on program start up and all new methods are private and never used except by the singleton class itself.

In static languages, this is accomplished by setting the constructors to private and controlling creation of instance of the object from within the object itself.

In dynamic languages, this is done by changing the access level of the constructor to prevent use outside the class just as in the static patterns.
===Late Instantiation===
The instance of the class can be created after class loading. (See the C++ example) This can be done by only allocating the instance on the first access of the instance variable.

==Accessing the instance==

In static languages, such as Java, the Singleton class will have a method which returns the instance of the Singleton class so that the other classes can use the functionality encapsulated in the Singleton class.

In dynamic languages, such as Ruby, if a class needs to access the functionality within the Singleton class then it simply needs to access the instance variable @instance and all the functionality therein.

=Examples=
==Java==

Java's API includes a Singleton class which implements the static version of the Singleton pattern. Java's implementation of the Singleton pattern only allows the programmer to create one instance of the Singleton class. The Singleton class automatically creates INSTANCE when it is initialized. The getInstance() method returns the single instance of the class that has been initialized. Java also utilizes a constructor to initialize the Singleton class.
<pre>
private static final Singleton INSTANCE = new Singleton();

// Private constructor prevents instantiation from other classes
private Singleton() {
}

public static Singleton getInstance() {
return INSTANCE;
}
</pre>
[[#References|[1]]]

==Ruby==

Ruby implements the Singleton pattern by privatizing the "new" method and creates an instance variable called @instance. This implementation guarantees that the class will not be able create more than one instantiation of itself and that the system will have the global access privileges since the @instance variable has a global scope. [[#References|[6]]]

<pre>
class genericFactory
include Singleton
end
</pre>
[[#References|[1]]]

<pre>
class Logger
def initialize
@log = File.open("log.txt", "a")
end

@@instance = Logger.new

def self.instance
return @@instance
end

def log(msg)
@log.puts(msg)
end

private_class_method :new
end

Logger.instance.log('message 1')

</pre>
[[#References|[6]]]

==C++==
<pre>
// Declaration
class Singleton {
public:
static Singleton* Instance();
protected:
Singleton();
private:
static Singleton* _instance;
}

// Implementation
Singleton* Singleton::_instance = 0;

Singleton* Singleton::Instance() {
if (_instance == 0) {
_instance = new Singleton;
}
return _instance;
}
</pre>
[[#References|[3]]]

=Benefits=

*This pattern allows the programmer to control the instances of a particular object, it ensures that all objects use the same instance of a class.[[#References|[3]]]

*The Singleton class has the ability to control the instantiation process since it implements the instantiation functionality.[[#References|[3]]]

=Drawbacks=

*Unit tests are much harder to write when using the Singleton pattern.[[#References|[3]]]

*This pattern reduces the potential for parallelism within a program since the threads must be serialized.[[#References|[3]]]

*The overhead of checking whether there is an instance of a class that already exists every time an objects requests a reference. Although the overhead is minuscule, this could be a serious problem for systems which don't have the resources to waste. [[#References|[3]]]

*There may be some development confusion with implementing the singleton class (especially one defined in a class library) because developers may forget that they cannot use the "new" keyword to instantiate the object.[[#References|[3]]]

*The singleton design pattern doesn't address the issue of deleting the single object. Some languages implement memory management which means that the Singleton class can only be unallocated by itself since it holds a private reference to the instance of itself. In languages that don't provide memory management, then the single instance can be deleted but it will cause a dangling reference to that object.[[#References|[3]]]

=References=

[[#References|[1]]] Wikipedia. (2010, October) Wikipedia - Singleton_Pattern. [Online]. http://en.wikipedia.org/wiki/Singleton_pattern#Traditional_simple_way

[[#References|[2]]] Freeman, Eric, Elisabeth Freeman, Kathy Sierra, and Bert Bates. (October 2004) Head First design patterns. [Print.]

[[#References|[3]]] C# Corner (2010, October) Creational Patterns - Singleton. [Online]. http://www.c-sharpcorner.com/UploadFile/susanabraham/CreationalPatterns06042005050058AM/CreationalPatterns.aspx

[[#References|[4]]] Source Making (2010, October) Singleton Design Pattern. [Online]. http://sourcemaking.com/design_patterns/singleton

[[#References|[5]]] JavaBeginner.com (2010, October) Java Singleton Design Pattern. [Online]. http://www.javabeginner.com/learn-java/java-singleton-design-pattern

[[#References|[6]]] Dalibor Nasevic (2010, October) Ruby Singleton Pattern Again. [Online]. http://dalibornasevic.com/posts/9-ruby-singleton-pattern-again

CSC/ECE 517 Fall 2010/ch3 3f lj

2010-10-14T02:30:16Z

Djfreema: /* Singleton pattern */

'''Singleton Pattern in Static and Dynamic languages'''

=Singleton pattern=

A [http://en.wikipedia.org/wiki/Design_pattern_computer_science| design pattern], like singleton, is a way for a software developer to handle situations using a known solution that has been proven to be effective in the past. Design patterns also make communicating ideas and concepts between programmers more efficient and understandable.

In the Singleton design pattern we create a single instance of a Singleton class. Any instantiation of that Singleton class references the same instance of the class. The pattern also provides a global point of access for the functionality contained in the sole instance of the class.

===Class Diagram===
[[Image:IC73826.gif|500px|center]]

This diagram is a Universal Modeling Languages (UML) diagram of how a Singleton class would look if implemented in Java.
===Sequence Diagram===
[[Image:CR2.gif|500px|center]]
This diagram illustrates how the Singleton class creates an instance of the Singleton object. The client classes then create instances of the Singleton class which handles access to the Singleton object.

=Implementation=
When this pattern is implemented then it must only have one instantiation of a class and that class must satisfy the global access principles. The pattern requires a mechanism to access the singleton class without instantiating another class object and a mechanism to persist the value of class members among class objects. [[#References|[1]]]

==Creating the instance==
===Early Instantiation===
The instance can be created with a static constructor in static languages. (See the java example below) This means that the single instance is created on program start up and all new methods are private and never used except by the singleton class itself.

In static languages, this is accomplished by setting the constructors to private and controlling creation of instance of the object from within the object itself.

In dynamic languages, this is done by changing the access level of the constructor to prevent use outside the class just as in the static patterns.
===Late Instantiation===
The instance of the class can be created after class loading. (See the C++ example) This can be done by only allocating the instance on the first access of the instance variable.

==Accessing the instance==

In static languages, such as Java, the Singleton class will have a method which returns the instance of the Singleton class so that the other classes can use the functionality encapsulated in the Singleton class.

In dynamic languages, such as Ruby, if a class needs to access the functionality within the Singleton class then it simply needs to access the instance variable @instance and all the functionality therein.

=Examples=
==Java==

Java's API includes a Singleton class which implements the static version of the Singleton pattern. Java's implementation of the Singleton pattern only allows the programmer to create one instance of the Singleton class. The Singleton class automatically creates INSTANCE when it is initialized. The getInstance() method returns the single instance of the class that has been initialized. Java also utilizes a constructor to initialize the Singleton class.
<pre>
private static final Singleton INSTANCE = new Singleton();

// Private constructor prevents instantiation from other classes
private Singleton() {
}

public static Singleton getInstance() {
return INSTANCE;
}
</pre>
[[#References|[1]]]

==Ruby==

Ruby implements the Singleton pattern by privatizing the "new" method and creates an instance variable called @instance. This implementation guarantees that the class will not be able create more than one instantiation of itself and that the system will have the global access privileges since the @instance variable has a global scope. [[#References|[6]]]

<pre>
class genericFactory
include Singleton
end
</pre>
[[#References|[1]]]

<pre>
class Logger
def initialize
@log = File.open("log.txt", "a")
end

@@instance = Logger.new

def self.instance
return @@instance
end

def log(msg)
@log.puts(msg)
end

private_class_method :new
end

Logger.instance.log('message 1')

</pre>
[[#References|[6]]]

==C++==
<pre>
// Declaration
class Singleton {
public:
static Singleton* Instance();
protected:
Singleton();
private:
static Singleton* _instance;
}

// Implementation
Singleton* Singleton::_instance = 0;

Singleton* Singleton::Instance() {
if (_instance == 0) {
_instance = new Singleton;
}
return _instance;
}
</pre>
[[#References|[3]]]

=Benefits=

*This pattern allows the programmer to control the instances of a particular object, it ensures that all objects use the same instance of a class.[[#References|[3]]]

*The Singleton class has the ability to control the instantiation process since it implements the instantiation functionality.[[#References|[3]]]

=Drawbacks=

*Unit tests are much harder to write when using the Singleton pattern.[[#References|[3]]]

*This pattern reduces the potential for parallelism within a program since the threads must be serialized.[[#References|[3]]]

*The overhead of checking whether there is an instance of a class that already exists every time an objects requests a reference. Although the overhead is minuscule, this could be a serious problem for systems which don't have the resources to waste. [[#References|[3]]]

*There may be some development confusion with implementing the singleton class (especially one defined in a class library) because developers may forget that they cannot use the "new" keyword to instantiate the object.[[#References|[3]]]

*The singleton design pattern doesn't address the issue of deleting the single object. Some languages implement memory management which means that the Singleton class can only be unallocated by itself since it holds a private reference to the instance of itself. In languages that don't provide memory management, then the single instance can be deleted but it will cause a dangling reference to that object.[[#References|[3]]]

=References=

[[#References|[1]]] Wikipedia. (2010, October) Wikipedia - Singleton_Pattern. [Online]. http://en.wikipedia.org/wiki/Singleton_pattern#Traditional_simple_way

[[#References|[2]]] Freeman, Eric, Elisabeth Freeman, Kathy Sierra, and Bert Bates. (October 2004) Head First design patterns. [Print.]

[[#References|[3]]] C# Corner (2010, October) Creational Patterns - Singleton. [Online]. http://www.c-sharpcorner.com/UploadFile/susanabraham/CreationalPatterns06042005050058AM/CreationalPatterns.aspx

[[#References|[4]]] Source Making (2010, October) Singleton Design Pattern. [Online]. http://sourcemaking.com/design_patterns/singleton

[[#References|[5]]] JavaBeginner.com (2010, October) Java Singleton Design Pattern. [Online]. http://www.javabeginner.com/learn-java/java-singleton-design-pattern

[[#References|[6]]] Dalibor Nasevic (2010, October) Ruby Singleton Pattern Again. [Online]. http://dalibornasevic.com/posts/9-ruby-singleton-pattern-again

CSC/ECE 517 Fall 2010/ch3 3f lj

2010-10-14T02:30:06Z

Djfreema: /* Singleton pattern */

'''Singleton Pattern in Static and Dynamic languages'''

=Singleton pattern=

A [http://en.wikipedia.org/wiki/Design_pattern_computer_science|design pattern], like singleton, is a way for a software developer to handle situations using a known solution that has been proven to be effective in the past. Design patterns also make communicating ideas and concepts between programmers more efficient and understandable.

In the Singleton design pattern we create a single instance of a Singleton class. Any instantiation of that Singleton class references the same instance of the class. The pattern also provides a global point of access for the functionality contained in the sole instance of the class.

===Class Diagram===
[[Image:IC73826.gif|500px|center]]

This diagram is a Universal Modeling Languages (UML) diagram of how a Singleton class would look if implemented in Java.
===Sequence Diagram===
[[Image:CR2.gif|500px|center]]
This diagram illustrates how the Singleton class creates an instance of the Singleton object. The client classes then create instances of the Singleton class which handles access to the Singleton object.

=Implementation=
When this pattern is implemented then it must only have one instantiation of a class and that class must satisfy the global access principles. The pattern requires a mechanism to access the singleton class without instantiating another class object and a mechanism to persist the value of class members among class objects. [[#References|[1]]]

==Creating the instance==
===Early Instantiation===
The instance can be created with a static constructor in static languages. (See the java example below) This means that the single instance is created on program start up and all new methods are private and never used except by the singleton class itself.

In static languages, this is accomplished by setting the constructors to private and controlling creation of instance of the object from within the object itself.

In dynamic languages, this is done by changing the access level of the constructor to prevent use outside the class just as in the static patterns.
===Late Instantiation===
The instance of the class can be created after class loading. (See the C++ example) This can be done by only allocating the instance on the first access of the instance variable.

==Accessing the instance==

In static languages, such as Java, the Singleton class will have a method which returns the instance of the Singleton class so that the other classes can use the functionality encapsulated in the Singleton class.

In dynamic languages, such as Ruby, if a class needs to access the functionality within the Singleton class then it simply needs to access the instance variable @instance and all the functionality therein.

=Examples=
==Java==

Java's API includes a Singleton class which implements the static version of the Singleton pattern. Java's implementation of the Singleton pattern only allows the programmer to create one instance of the Singleton class. The Singleton class automatically creates INSTANCE when it is initialized. The getInstance() method returns the single instance of the class that has been initialized. Java also utilizes a constructor to initialize the Singleton class.
<pre>
private static final Singleton INSTANCE = new Singleton();

// Private constructor prevents instantiation from other classes
private Singleton() {
}

public static Singleton getInstance() {
return INSTANCE;
}
</pre>
[[#References|[1]]]

==Ruby==

Ruby implements the Singleton pattern by privatizing the "new" method and creates an instance variable called @instance. This implementation guarantees that the class will not be able create more than one instantiation of itself and that the system will have the global access privileges since the @instance variable has a global scope. [[#References|[6]]]

<pre>
class genericFactory
include Singleton
end
</pre>
[[#References|[1]]]

<pre>
class Logger
def initialize
@log = File.open("log.txt", "a")
end

@@instance = Logger.new

def self.instance
return @@instance
end

def log(msg)
@log.puts(msg)
end

private_class_method :new
end

Logger.instance.log('message 1')

</pre>
[[#References|[6]]]

==C++==
<pre>
// Declaration
class Singleton {
public:
static Singleton* Instance();
protected:
Singleton();
private:
static Singleton* _instance;
}

// Implementation
Singleton* Singleton::_instance = 0;

Singleton* Singleton::Instance() {
if (_instance == 0) {
_instance = new Singleton;
}
return _instance;
}
</pre>
[[#References|[3]]]

=Benefits=

*This pattern allows the programmer to control the instances of a particular object, it ensures that all objects use the same instance of a class.[[#References|[3]]]

*The Singleton class has the ability to control the instantiation process since it implements the instantiation functionality.[[#References|[3]]]

=Drawbacks=

*Unit tests are much harder to write when using the Singleton pattern.[[#References|[3]]]

*This pattern reduces the potential for parallelism within a program since the threads must be serialized.[[#References|[3]]]

*The overhead of checking whether there is an instance of a class that already exists every time an objects requests a reference. Although the overhead is minuscule, this could be a serious problem for systems which don't have the resources to waste. [[#References|[3]]]

*There may be some development confusion with implementing the singleton class (especially one defined in a class library) because developers may forget that they cannot use the "new" keyword to instantiate the object.[[#References|[3]]]

*The singleton design pattern doesn't address the issue of deleting the single object. Some languages implement memory management which means that the Singleton class can only be unallocated by itself since it holds a private reference to the instance of itself. In languages that don't provide memory management, then the single instance can be deleted but it will cause a dangling reference to that object.[[#References|[3]]]

=References=

[[#References|[1]]] Wikipedia. (2010, October) Wikipedia - Singleton_Pattern. [Online]. http://en.wikipedia.org/wiki/Singleton_pattern#Traditional_simple_way

[[#References|[2]]] Freeman, Eric, Elisabeth Freeman, Kathy Sierra, and Bert Bates. (October 2004) Head First design patterns. [Print.]

[[#References|[3]]] C# Corner (2010, October) Creational Patterns - Singleton. [Online]. http://www.c-sharpcorner.com/UploadFile/susanabraham/CreationalPatterns06042005050058AM/CreationalPatterns.aspx

[[#References|[4]]] Source Making (2010, October) Singleton Design Pattern. [Online]. http://sourcemaking.com/design_patterns/singleton

[[#References|[5]]] JavaBeginner.com (2010, October) Java Singleton Design Pattern. [Online]. http://www.javabeginner.com/learn-java/java-singleton-design-pattern

[[#References|[6]]] Dalibor Nasevic (2010, October) Ruby Singleton Pattern Again. [Online]. http://dalibornasevic.com/posts/9-ruby-singleton-pattern-again

CSC/ECE 517 Fall 2010/ch3 3f lj

2010-10-14T02:29:37Z

Djfreema: /* Singleton pattern */

'''Singleton Pattern in Static and Dynamic languages'''

=Singleton pattern=

A [[http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29]|design pattern], like singleton, is a way for a software developer to handle situations using a known solution that has been proven to be effective in the past. Design patterns also make communicating ideas and concepts between programmers more efficient and understandable.

In the Singleton design pattern we create a single instance of a Singleton class. Any instantiation of that Singleton class references the same instance of the class. The pattern also provides a global point of access for the functionality contained in the sole instance of the class.

===Class Diagram===
[[Image:IC73826.gif|500px|center]]

This diagram is a Universal Modeling Languages (UML) diagram of how a Singleton class would look if implemented in Java.
===Sequence Diagram===
[[Image:CR2.gif|500px|center]]
This diagram illustrates how the Singleton class creates an instance of the Singleton object. The client classes then create instances of the Singleton class which handles access to the Singleton object.
=Implementation=
When this pattern is implemented then it must only have one instantiation of a class and that class must satisfy the global access principles. The pattern requires a mechanism to access the singleton class without instantiating another class object and a mechanism to persist the value of class members among class objects. [[#References|[1]]]

==Creating the instance==
===Early Instantiation===
The instance can be created with a static constructor in static languages. (See the java example below) This means that the single instance is created on program start up and all new methods are private and never used except by the singleton class itself.

In static languages, this is accomplished by setting the constructors to private and controlling creation of instance of the object from within the object itself.

In dynamic languages, this is done by changing the access level of the constructor to prevent use outside the class just as in the static patterns.
===Late Instantiation===
The instance of the class can be created after class loading. (See the C++ example) This can be done by only allocating the instance on the first access of the instance variable.

==Accessing the instance==

In static languages, such as Java, the Singleton class will have a method which returns the instance of the Singleton class so that the other classes can use the functionality encapsulated in the Singleton class.

In dynamic languages, such as Ruby, if a class needs to access the functionality within the Singleton class then it simply needs to access the instance variable @instance and all the functionality therein.

=Examples=
==Java==

Java's API includes a Singleton class which implements the static version of the Singleton pattern. Java's implementation of the Singleton pattern only allows the programmer to create one instance of the Singleton class. The Singleton class automatically creates INSTANCE when it is initialized. The getInstance() method returns the single instance of the class that has been initialized. Java also utilizes a constructor to initialize the Singleton class.
<pre>
private static final Singleton INSTANCE = new Singleton();

// Private constructor prevents instantiation from other classes
private Singleton() {
}

public static Singleton getInstance() {
return INSTANCE;
}
</pre>
[[#References|[1]]]

==Ruby==

Ruby implements the Singleton pattern by privatizing the "new" method and creates an instance variable called @instance. This implementation guarantees that the class will not be able create more than one instantiation of itself and that the system will have the global access privileges since the @instance variable has a global scope. [[#References|[6]]]

<pre>
class genericFactory
include Singleton
end
</pre>
[[#References|[1]]]

<pre>
class Logger
def initialize
@log = File.open("log.txt", "a")
end

@@instance = Logger.new

def self.instance
return @@instance
end

def log(msg)
@log.puts(msg)
end

private_class_method :new
end

Logger.instance.log('message 1')

</pre>
[[#References|[6]]]

==C++==
<pre>
// Declaration
class Singleton {
public:
static Singleton* Instance();
protected:
Singleton();
private:
static Singleton* _instance;
}

// Implementation
Singleton* Singleton::_instance = 0;

Singleton* Singleton::Instance() {
if (_instance == 0) {
_instance = new Singleton;
}
return _instance;
}
</pre>
[[#References|[3]]]

=Benefits=

*This pattern allows the programmer to control the instances of a particular object, it ensures that all objects use the same instance of a class.[[#References|[3]]]

*The Singleton class has the ability to control the instantiation process since it implements the instantiation functionality.[[#References|[3]]]

=Drawbacks=

*Unit tests are much harder to write when using the Singleton pattern.[[#References|[3]]]

*This pattern reduces the potential for parallelism within a program since the threads must be serialized.[[#References|[3]]]

*The overhead of checking whether there is an instance of a class that already exists every time an objects requests a reference. Although the overhead is minuscule, this could be a serious problem for systems which don't have the resources to waste. [[#References|[3]]]

*There may be some development confusion with implementing the singleton class (especially one defined in a class library) because developers may forget that they cannot use the "new" keyword to instantiate the object.[[#References|[3]]]

*The singleton design pattern doesn't address the issue of deleting the single object. Some languages implement memory management which means that the Singleton class can only be unallocated by itself since it holds a private reference to the instance of itself. In languages that don't provide memory management, then the single instance can be deleted but it will cause a dangling reference to that object.[[#References|[3]]]

=References=

[[#References|[1]]] Wikipedia. (2010, October) Wikipedia - Singleton_Pattern. [Online]. http://en.wikipedia.org/wiki/Singleton_pattern#Traditional_simple_way

[[#References|[2]]] Freeman, Eric, Elisabeth Freeman, Kathy Sierra, and Bert Bates. (October 2004) Head First design patterns. [Print.]

[[#References|[3]]] C# Corner (2010, October) Creational Patterns - Singleton. [Online]. http://www.c-sharpcorner.com/UploadFile/susanabraham/CreationalPatterns06042005050058AM/CreationalPatterns.aspx

[[#References|[4]]] Source Making (2010, October) Singleton Design Pattern. [Online]. http://sourcemaking.com/design_patterns/singleton

[[#References|[5]]] JavaBeginner.com (2010, October) Java Singleton Design Pattern. [Online]. http://www.javabeginner.com/learn-java/java-singleton-design-pattern

[[#References|[6]]] Dalibor Nasevic (2010, October) Ruby Singleton Pattern Again. [Online]. http://dalibornasevic.com/posts/9-ruby-singleton-pattern-again

CSC/ECE 517 Fall 2010/ch3 3f lj

2010-10-14T02:27:37Z

Djfreema: /* Singleton pattern */

'''Singleton Pattern in Static and Dynamic languages'''

=Singleton pattern=

A [http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29|[design pattern]], like singleton, is a way for a software developer to handle situations using a known solution that has been proven to be effective in the past. Design patterns also make communicating ideas and concepts between programmers more efficient and understandable.

In the Singleton design pattern we create a single instance of a Singleton class. Any instantiation of that Singleton class references the same instance of the class. The pattern also provides a global point of access for the functionality contained in the sole instance of the class.

===Class Diagram===
[[Image:IC73826.gif|500px|center]]

This diagram is a Universal Modeling Languages (UML) diagram of how a Singleton class would look if implemented in Java.
===Sequence Diagram===
[[Image:CR2.gif|500px|center]]

=Implementation=
When this pattern is implemented then it must only have one instantiation of a class and that class must satisfy the global access principles. The pattern requires a mechanism to access the singleton class without instantiating another class object and a mechanism to persist the value of class members among class objects. [[#References|[1]]]

==Creating the instance==
===Early Instantiation===
The instance can be created with a static constructor in static languages. (See the java example below) This means that the single instance is created on program start up and all new methods are private and never used except by the singleton class itself.

In static languages, this is accomplished by setting the constructors to private and controlling creation of instance of the object from within the object itself.

In dynamic languages, this is done by changing the access level of the constructor to prevent use outside the class just as in the static patterns.
===Late Instantiation===
The instance of the class can be created after class loading. (See the C++ example) This can be done by only allocating the instance on the first access of the instance variable.

==Accessing the instance==

In static languages, such as Java, the Singleton class will have a method which returns the instance of the Singleton class so that the other classes can use the functionality encapsulated in the Singleton class.

In dynamic languages, such as Ruby, if a class needs to access the functionality within the Singleton class then it simply needs to access the instance variable @instance and all the functionality therein.

=Examples=
==Java==

Java's API includes a Singleton class which implements the static version of the Singleton pattern. Java's implementation of the Singleton pattern only allows the programmer to create one instance of the Singleton class. The Singleton class automatically creates INSTANCE when it is initialized. The getInstance() method returns the single instance of the class that has been initialized. Java also utilizes a constructor to initialize the Singleton class.
<pre>
private static final Singleton INSTANCE = new Singleton();

// Private constructor prevents instantiation from other classes
private Singleton() {
}

public static Singleton getInstance() {
return INSTANCE;
}
</pre>
[[#References|[1]]]

==Ruby==

Ruby implements the Singleton pattern by privatizing the "new" method and creates an instance variable called @instance. This implementation guarantees that the class will not be able create more than one instantiation of itself and that the system will have the global access privileges since the @instance variable has a global scope. [[#References|[6]]]

<pre>
class genericFactory
include Singleton
end
</pre>
[[#References|[1]]]

<pre>
class Logger
def initialize
@log = File.open("log.txt", "a")
end

@@instance = Logger.new

def self.instance
return @@instance
end

def log(msg)
@log.puts(msg)
end

private_class_method :new
end

Logger.instance.log('message 1')

</pre>
[[#References|[6]]]

==C++==
<pre>
// Declaration
class Singleton {
public:
static Singleton* Instance();
protected:
Singleton();
private:
static Singleton* _instance;
}

// Implementation
Singleton* Singleton::_instance = 0;

Singleton* Singleton::Instance() {
if (_instance == 0) {
_instance = new Singleton;
}
return _instance;
}
</pre>
[[#References|[3]]]

=Benefits=

*This pattern allows the programmer to control the instances of a particular object, it ensures that all objects use the same instance of a class.[[#References|[3]]]

*The Singleton class has the ability to control the instantiation process since it implements the instantiation functionality.[[#References|[3]]]

=Drawbacks=

*Unit tests are much harder to write when using the Singleton pattern.[[#References|[3]]]

*This pattern reduces the potential for parallelism within a program since the threads must be serialized.[[#References|[3]]]

*The overhead of checking whether there is an instance of a class that already exists every time an objects requests a reference. Although the overhead is minuscule, this could be a serious problem for systems which don't have the resources to waste. [[#References|[3]]]

*There may be some development confusion with implementing the singleton class (especially one defined in a class library) because developers may forget that they cannot use the "new" keyword to instantiate the object.[[#References|[3]]]

*The singleton design pattern doesn't address the issue of deleting the single object. Some languages implement memory management which means that the Singleton class can only be unallocated by itself since it holds a private reference to the instance of itself. In languages that don't provide memory management, then the single instance can be deleted but it will cause a dangling reference to that object.[[#References|[3]]]

=References=

[[#References|[1]]] Wikipedia. (2010, October) Wikipedia - Singleton_Pattern. [Online]. http://en.wikipedia.org/wiki/Singleton_pattern#Traditional_simple_way

[[#References|[2]]] Freeman, Eric, Elisabeth Freeman, Kathy Sierra, and Bert Bates. (October 2004) Head First design patterns. [Print.]

[[#References|[3]]] C# Corner (2010, October) Creational Patterns - Singleton. [Online]. http://www.c-sharpcorner.com/UploadFile/susanabraham/CreationalPatterns06042005050058AM/CreationalPatterns.aspx

[[#References|[4]]] Source Making (2010, October) Singleton Design Pattern. [Online]. http://sourcemaking.com/design_patterns/singleton

[[#References|[5]]] JavaBeginner.com (2010, October) Java Singleton Design Pattern. [Online]. http://www.javabeginner.com/learn-java/java-singleton-design-pattern

[[#References|[6]]] Dalibor Nasevic (2010, October) Ruby Singleton Pattern Again. [Online]. http://dalibornasevic.com/posts/9-ruby-singleton-pattern-again

CSC/ECE 517 Fall 2010/ch3 3f lj

2010-10-14T02:27:15Z

Djfreema: /* Singleton pattern */

'''Singleton Pattern in Static and Dynamic languages'''

=Singleton pattern=

A [http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29|design&nbsppattern], like singleton, is a way for a software developer to handle situations using a known solution that has been proven to be effective in the past. Design patterns also make communicating ideas and concepts between programmers more efficient and understandable.

In the Singleton design pattern we create a single instance of a Singleton class. Any instantiation of that Singleton class references the same instance of the class. The pattern also provides a global point of access for the functionality contained in the sole instance of the class.

===Class Diagram===
[[Image:IC73826.gif|500px|center]]

This diagram is a Universal Modeling Languages (UML) diagram of how a Singleton class would look if implemented in Java.
===Sequence Diagram===
[[Image:CR2.gif|500px|center]]

=Implementation=
When this pattern is implemented then it must only have one instantiation of a class and that class must satisfy the global access principles. The pattern requires a mechanism to access the singleton class without instantiating another class object and a mechanism to persist the value of class members among class objects. [[#References|[1]]]

==Creating the instance==
===Early Instantiation===
The instance can be created with a static constructor in static languages. (See the java example below) This means that the single instance is created on program start up and all new methods are private and never used except by the singleton class itself.

In static languages, this is accomplished by setting the constructors to private and controlling creation of instance of the object from within the object itself.

In dynamic languages, this is done by changing the access level of the constructor to prevent use outside the class just as in the static patterns.
===Late Instantiation===
The instance of the class can be created after class loading. (See the C++ example) This can be done by only allocating the instance on the first access of the instance variable.

==Accessing the instance==

In static languages, such as Java, the Singleton class will have a method which returns the instance of the Singleton class so that the other classes can use the functionality encapsulated in the Singleton class.

In dynamic languages, such as Ruby, if a class needs to access the functionality within the Singleton class then it simply needs to access the instance variable @instance and all the functionality therein.

=Examples=
==Java==

Java's API includes a Singleton class which implements the static version of the Singleton pattern. Java's implementation of the Singleton pattern only allows the programmer to create one instance of the Singleton class. The Singleton class automatically creates INSTANCE when it is initialized. The getInstance() method returns the single instance of the class that has been initialized. Java also utilizes a constructor to initialize the Singleton class.
<pre>
private static final Singleton INSTANCE = new Singleton();

// Private constructor prevents instantiation from other classes
private Singleton() {
}

public static Singleton getInstance() {
return INSTANCE;
}
</pre>
[[#References|[1]]]

==Ruby==

Ruby implements the Singleton pattern by privatizing the "new" method and creates an instance variable called @instance. This implementation guarantees that the class will not be able create more than one instantiation of itself and that the system will have the global access privileges since the @instance variable has a global scope. [[#References|[6]]]

<pre>
class genericFactory
include Singleton
end
</pre>
[[#References|[1]]]

<pre>
class Logger
def initialize
@log = File.open("log.txt", "a")
end

@@instance = Logger.new

def self.instance
return @@instance
end

def log(msg)
@log.puts(msg)
end

private_class_method :new
end

Logger.instance.log('message 1')

</pre>
[[#References|[6]]]

==C++==
<pre>
// Declaration
class Singleton {
public:
static Singleton* Instance();
protected:
Singleton();
private:
static Singleton* _instance;
}

// Implementation
Singleton* Singleton::_instance = 0;

Singleton* Singleton::Instance() {
if (_instance == 0) {
_instance = new Singleton;
}
return _instance;
}
</pre>
[[#References|[3]]]

=Benefits=

*This pattern allows the programmer to control the instances of a particular object, it ensures that all objects use the same instance of a class.[[#References|[3]]]

*The Singleton class has the ability to control the instantiation process since it implements the instantiation functionality.[[#References|[3]]]

=Drawbacks=

*Unit tests are much harder to write when using the Singleton pattern.[[#References|[3]]]

*This pattern reduces the potential for parallelism within a program since the threads must be serialized.[[#References|[3]]]

*The overhead of checking whether there is an instance of a class that already exists every time an objects requests a reference. Although the overhead is minuscule, this could be a serious problem for systems which don't have the resources to waste. [[#References|[3]]]

*There may be some development confusion with implementing the singleton class (especially one defined in a class library) because developers may forget that they cannot use the "new" keyword to instantiate the object.[[#References|[3]]]

*The singleton design pattern doesn't address the issue of deleting the single object. Some languages implement memory management which means that the Singleton class can only be unallocated by itself since it holds a private reference to the instance of itself. In languages that don't provide memory management, then the single instance can be deleted but it will cause a dangling reference to that object.[[#References|[3]]]

=References=

[[#References|[1]]] Wikipedia. (2010, October) Wikipedia - Singleton_Pattern. [Online]. http://en.wikipedia.org/wiki/Singleton_pattern#Traditional_simple_way

[[#References|[2]]] Freeman, Eric, Elisabeth Freeman, Kathy Sierra, and Bert Bates. (October 2004) Head First design patterns. [Print.]

[[#References|[3]]] C# Corner (2010, October) Creational Patterns - Singleton. [Online]. http://www.c-sharpcorner.com/UploadFile/susanabraham/CreationalPatterns06042005050058AM/CreationalPatterns.aspx

[[#References|[4]]] Source Making (2010, October) Singleton Design Pattern. [Online]. http://sourcemaking.com/design_patterns/singleton

[[#References|[5]]] JavaBeginner.com (2010, October) Java Singleton Design Pattern. [Online]. http://www.javabeginner.com/learn-java/java-singleton-design-pattern

[[#References|[6]]] Dalibor Nasevic (2010, October) Ruby Singleton Pattern Again. [Online]. http://dalibornasevic.com/posts/9-ruby-singleton-pattern-again

CSC/ECE 517 Fall 2010/ch3 3f lj

2010-10-14T02:26:57Z

Djfreema: /* Singleton pattern */

'''Singleton Pattern in Static and Dynamic languages'''

=Singleton pattern=

A [http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29|design pattern], like singleton, is a way for a software developer to handle situations using a known solution that has been proven to be effective in the past. Design patterns also make communicating ideas and concepts between programmers more efficient and understandable.

In the Singleton design pattern we create a single instance of a Singleton class. Any instantiation of that Singleton class references the same instance of the class. The pattern also provides a global point of access for the functionality contained in the sole instance of the class.

===Class Diagram===
[[Image:IC73826.gif|500px|center]]

This diagram is a Universal Modeling Languages (UML) diagram of how a Singleton class would look if implemented in Java.
===Sequence Diagram===
[[Image:CR2.gif|500px|center]]

=Implementation=
When this pattern is implemented then it must only have one instantiation of a class and that class must satisfy the global access principles. The pattern requires a mechanism to access the singleton class without instantiating another class object and a mechanism to persist the value of class members among class objects. [[#References|[1]]]

==Creating the instance==
===Early Instantiation===
The instance can be created with a static constructor in static languages. (See the java example below) This means that the single instance is created on program start up and all new methods are private and never used except by the singleton class itself.

In static languages, this is accomplished by setting the constructors to private and controlling creation of instance of the object from within the object itself.

In dynamic languages, this is done by changing the access level of the constructor to prevent use outside the class just as in the static patterns.
===Late Instantiation===
The instance of the class can be created after class loading. (See the C++ example) This can be done by only allocating the instance on the first access of the instance variable.

==Accessing the instance==

In static languages, such as Java, the Singleton class will have a method which returns the instance of the Singleton class so that the other classes can use the functionality encapsulated in the Singleton class.

In dynamic languages, such as Ruby, if a class needs to access the functionality within the Singleton class then it simply needs to access the instance variable @instance and all the functionality therein.

=Examples=
==Java==

Java's API includes a Singleton class which implements the static version of the Singleton pattern. Java's implementation of the Singleton pattern only allows the programmer to create one instance of the Singleton class. The Singleton class automatically creates INSTANCE when it is initialized. The getInstance() method returns the single instance of the class that has been initialized. Java also utilizes a constructor to initialize the Singleton class.
<pre>
private static final Singleton INSTANCE = new Singleton();

// Private constructor prevents instantiation from other classes
private Singleton() {
}

public static Singleton getInstance() {
return INSTANCE;
}
</pre>
[[#References|[1]]]

==Ruby==

Ruby implements the Singleton pattern by privatizing the "new" method and creates an instance variable called @instance. This implementation guarantees that the class will not be able create more than one instantiation of itself and that the system will have the global access privileges since the @instance variable has a global scope. [[#References|[6]]]

<pre>
class genericFactory
include Singleton
end
</pre>
[[#References|[1]]]

<pre>
class Logger
def initialize
@log = File.open("log.txt", "a")
end

@@instance = Logger.new

def self.instance
return @@instance
end

def log(msg)
@log.puts(msg)
end

private_class_method :new
end

Logger.instance.log('message 1')

</pre>
[[#References|[6]]]

==C++==
<pre>
// Declaration
class Singleton {
public:
static Singleton* Instance();
protected:
Singleton();
private:
static Singleton* _instance;
}

// Implementation
Singleton* Singleton::_instance = 0;

Singleton* Singleton::Instance() {
if (_instance == 0) {
_instance = new Singleton;
}
return _instance;
}
</pre>
[[#References|[3]]]

=Benefits=

*This pattern allows the programmer to control the instances of a particular object, it ensures that all objects use the same instance of a class.[[#References|[3]]]

*The Singleton class has the ability to control the instantiation process since it implements the instantiation functionality.[[#References|[3]]]

=Drawbacks=

*Unit tests are much harder to write when using the Singleton pattern.[[#References|[3]]]

*This pattern reduces the potential for parallelism within a program since the threads must be serialized.[[#References|[3]]]

*The overhead of checking whether there is an instance of a class that already exists every time an objects requests a reference. Although the overhead is minuscule, this could be a serious problem for systems which don't have the resources to waste. [[#References|[3]]]

*There may be some development confusion with implementing the singleton class (especially one defined in a class library) because developers may forget that they cannot use the "new" keyword to instantiate the object.[[#References|[3]]]

*The singleton design pattern doesn't address the issue of deleting the single object. Some languages implement memory management which means that the Singleton class can only be unallocated by itself since it holds a private reference to the instance of itself. In languages that don't provide memory management, then the single instance can be deleted but it will cause a dangling reference to that object.[[#References|[3]]]

=References=

[[#References|[1]]] Wikipedia. (2010, October) Wikipedia - Singleton_Pattern. [Online]. http://en.wikipedia.org/wiki/Singleton_pattern#Traditional_simple_way

[[#References|[2]]] Freeman, Eric, Elisabeth Freeman, Kathy Sierra, and Bert Bates. (October 2004) Head First design patterns. [Print.]

[[#References|[3]]] C# Corner (2010, October) Creational Patterns - Singleton. [Online]. http://www.c-sharpcorner.com/UploadFile/susanabraham/CreationalPatterns06042005050058AM/CreationalPatterns.aspx

[[#References|[4]]] Source Making (2010, October) Singleton Design Pattern. [Online]. http://sourcemaking.com/design_patterns/singleton

[[#References|[5]]] JavaBeginner.com (2010, October) Java Singleton Design Pattern. [Online]. http://www.javabeginner.com/learn-java/java-singleton-design-pattern

[[#References|[6]]] Dalibor Nasevic (2010, October) Ruby Singleton Pattern Again. [Online]. http://dalibornasevic.com/posts/9-ruby-singleton-pattern-again

CSC/ECE 517 Fall 2010/ch3 3f lj

2010-10-14T02:26:41Z

Djfreema: /* Singleton pattern */

'''Singleton Pattern in Static and Dynamic languages'''

=Singleton pattern=

A [http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29|"design pattern"], like singleton, is a way for a software developer to handle situations using a known solution that has been proven to be effective in the past. Design patterns also make communicating ideas and concepts between programmers more efficient and understandable.

In the Singleton design pattern we create a single instance of a Singleton class. Any instantiation of that Singleton class references the same instance of the class. The pattern also provides a global point of access for the functionality contained in the sole instance of the class.

===Class Diagram===
[[Image:IC73826.gif|500px|center]]

This diagram is a Universal Modeling Languages (UML) diagram of how a Singleton class would look if implemented in Java.
===Sequence Diagram===
[[Image:CR2.gif|500px|center]]

=Implementation=
When this pattern is implemented then it must only have one instantiation of a class and that class must satisfy the global access principles. The pattern requires a mechanism to access the singleton class without instantiating another class object and a mechanism to persist the value of class members among class objects. [[#References|[1]]]

==Creating the instance==
===Early Instantiation===
The instance can be created with a static constructor in static languages. (See the java example below) This means that the single instance is created on program start up and all new methods are private and never used except by the singleton class itself.

In static languages, this is accomplished by setting the constructors to private and controlling creation of instance of the object from within the object itself.

In dynamic languages, this is done by changing the access level of the constructor to prevent use outside the class just as in the static patterns.
===Late Instantiation===
The instance of the class can be created after class loading. (See the C++ example) This can be done by only allocating the instance on the first access of the instance variable.

==Accessing the instance==

In static languages, such as Java, the Singleton class will have a method which returns the instance of the Singleton class so that the other classes can use the functionality encapsulated in the Singleton class.

In dynamic languages, such as Ruby, if a class needs to access the functionality within the Singleton class then it simply needs to access the instance variable @instance and all the functionality therein.

=Examples=
==Java==

Java's API includes a Singleton class which implements the static version of the Singleton pattern. Java's implementation of the Singleton pattern only allows the programmer to create one instance of the Singleton class. The Singleton class automatically creates INSTANCE when it is initialized. The getInstance() method returns the single instance of the class that has been initialized. Java also utilizes a constructor to initialize the Singleton class.
<pre>
private static final Singleton INSTANCE = new Singleton();

// Private constructor prevents instantiation from other classes
private Singleton() {
}

public static Singleton getInstance() {
return INSTANCE;
}
</pre>
[[#References|[1]]]

==Ruby==

Ruby implements the Singleton pattern by privatizing the "new" method and creates an instance variable called @instance. This implementation guarantees that the class will not be able create more than one instantiation of itself and that the system will have the global access privileges since the @instance variable has a global scope. [[#References|[6]]]

<pre>
class genericFactory
include Singleton
end
</pre>
[[#References|[1]]]

<pre>
class Logger
def initialize
@log = File.open("log.txt", "a")
end

@@instance = Logger.new

def self.instance
return @@instance
end

def log(msg)
@log.puts(msg)
end

private_class_method :new
end

Logger.instance.log('message 1')

</pre>
[[#References|[6]]]

==C++==
<pre>
// Declaration
class Singleton {
public:
static Singleton* Instance();
protected:
Singleton();
private:
static Singleton* _instance;
}

// Implementation
Singleton* Singleton::_instance = 0;

Singleton* Singleton::Instance() {
if (_instance == 0) {
_instance = new Singleton;
}
return _instance;
}
</pre>
[[#References|[3]]]

=Benefits=

*This pattern allows the programmer to control the instances of a particular object, it ensures that all objects use the same instance of a class.[[#References|[3]]]

*The Singleton class has the ability to control the instantiation process since it implements the instantiation functionality.[[#References|[3]]]

=Drawbacks=

*Unit tests are much harder to write when using the Singleton pattern.[[#References|[3]]]

*This pattern reduces the potential for parallelism within a program since the threads must be serialized.[[#References|[3]]]

*The overhead of checking whether there is an instance of a class that already exists every time an objects requests a reference. Although the overhead is minuscule, this could be a serious problem for systems which don't have the resources to waste. [[#References|[3]]]

*There may be some development confusion with implementing the singleton class (especially one defined in a class library) because developers may forget that they cannot use the "new" keyword to instantiate the object.[[#References|[3]]]

*The singleton design pattern doesn't address the issue of deleting the single object. Some languages implement memory management which means that the Singleton class can only be unallocated by itself since it holds a private reference to the instance of itself. In languages that don't provide memory management, then the single instance can be deleted but it will cause a dangling reference to that object.[[#References|[3]]]

=References=

[[#References|[1]]] Wikipedia. (2010, October) Wikipedia - Singleton_Pattern. [Online]. http://en.wikipedia.org/wiki/Singleton_pattern#Traditional_simple_way

[[#References|[2]]] Freeman, Eric, Elisabeth Freeman, Kathy Sierra, and Bert Bates. (October 2004) Head First design patterns. [Print.]

[[#References|[3]]] C# Corner (2010, October) Creational Patterns - Singleton. [Online]. http://www.c-sharpcorner.com/UploadFile/susanabraham/CreationalPatterns06042005050058AM/CreationalPatterns.aspx

[[#References|[4]]] Source Making (2010, October) Singleton Design Pattern. [Online]. http://sourcemaking.com/design_patterns/singleton

[[#References|[5]]] JavaBeginner.com (2010, October) Java Singleton Design Pattern. [Online]. http://www.javabeginner.com/learn-java/java-singleton-design-pattern

[[#References|[6]]] Dalibor Nasevic (2010, October) Ruby Singleton Pattern Again. [Online]. http://dalibornasevic.com/posts/9-ruby-singleton-pattern-again

CSC/ECE 517 Fall 2010/ch3 3f lj

2010-10-14T02:26:17Z

Djfreema: /* Singleton pattern */

'''Singleton Pattern in Static and Dynamic languages'''

=Singleton pattern=

A [[http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29|design pattern]], like singleton, is a way for a software developer to handle situations using a known solution that has been proven to be effective in the past. Design patterns also make communicating ideas and concepts between programmers more efficient and understandable.

In the Singleton design pattern we create a single instance of a Singleton class. Any instantiation of that Singleton class references the same instance of the class. The pattern also provides a global point of access for the functionality contained in the sole instance of the class.

===Class Diagram===
[[Image:IC73826.gif|500px|center]]

This diagram is a Universal Modeling Languages (UML) diagram of how a Singleton class would look if implemented in Java.
===Sequence Diagram===
[[Image:CR2.gif|500px|center]]

=Implementation=
When this pattern is implemented then it must only have one instantiation of a class and that class must satisfy the global access principles. The pattern requires a mechanism to access the singleton class without instantiating another class object and a mechanism to persist the value of class members among class objects. [[#References|[1]]]

==Creating the instance==
===Early Instantiation===
The instance can be created with a static constructor in static languages. (See the java example below) This means that the single instance is created on program start up and all new methods are private and never used except by the singleton class itself.

In static languages, this is accomplished by setting the constructors to private and controlling creation of instance of the object from within the object itself.

In dynamic languages, this is done by changing the access level of the constructor to prevent use outside the class just as in the static patterns.
===Late Instantiation===
The instance of the class can be created after class loading. (See the C++ example) This can be done by only allocating the instance on the first access of the instance variable.

==Accessing the instance==

In static languages, such as Java, the Singleton class will have a method which returns the instance of the Singleton class so that the other classes can use the functionality encapsulated in the Singleton class.

In dynamic languages, such as Ruby, if a class needs to access the functionality within the Singleton class then it simply needs to access the instance variable @instance and all the functionality therein.

=Examples=
==Java==

Java's API includes a Singleton class which implements the static version of the Singleton pattern. Java's implementation of the Singleton pattern only allows the programmer to create one instance of the Singleton class. The Singleton class automatically creates INSTANCE when it is initialized. The getInstance() method returns the single instance of the class that has been initialized. Java also utilizes a constructor to initialize the Singleton class.
<pre>
private static final Singleton INSTANCE = new Singleton();

// Private constructor prevents instantiation from other classes
private Singleton() {
}

public static Singleton getInstance() {
return INSTANCE;
}
</pre>
[[#References|[1]]]

==Ruby==

Ruby implements the Singleton pattern by privatizing the "new" method and creates an instance variable called @instance. This implementation guarantees that the class will not be able create more than one instantiation of itself and that the system will have the global access privileges since the @instance variable has a global scope. [[#References|[6]]]

<pre>
class genericFactory
include Singleton
end
</pre>
[[#References|[1]]]

<pre>
class Logger
def initialize
@log = File.open("log.txt", "a")
end

@@instance = Logger.new

def self.instance
return @@instance
end

def log(msg)
@log.puts(msg)
end

private_class_method :new
end

Logger.instance.log('message 1')

</pre>
[[#References|[6]]]

==C++==
<pre>
// Declaration
class Singleton {
public:
static Singleton* Instance();
protected:
Singleton();
private:
static Singleton* _instance;
}

// Implementation
Singleton* Singleton::_instance = 0;

Singleton* Singleton::Instance() {
if (_instance == 0) {
_instance = new Singleton;
}
return _instance;
}
</pre>
[[#References|[3]]]

=Benefits=

*This pattern allows the programmer to control the instances of a particular object, it ensures that all objects use the same instance of a class.[[#References|[3]]]

*The Singleton class has the ability to control the instantiation process since it implements the instantiation functionality.[[#References|[3]]]

=Drawbacks=

*Unit tests are much harder to write when using the Singleton pattern.[[#References|[3]]]

*This pattern reduces the potential for parallelism within a program since the threads must be serialized.[[#References|[3]]]

*The overhead of checking whether there is an instance of a class that already exists every time an objects requests a reference. Although the overhead is minuscule, this could be a serious problem for systems which don't have the resources to waste. [[#References|[3]]]

*There may be some development confusion with implementing the singleton class (especially one defined in a class library) because developers may forget that they cannot use the "new" keyword to instantiate the object.[[#References|[3]]]

*The singleton design pattern doesn't address the issue of deleting the single object. Some languages implement memory management which means that the Singleton class can only be unallocated by itself since it holds a private reference to the instance of itself. In languages that don't provide memory management, then the single instance can be deleted but it will cause a dangling reference to that object.[[#References|[3]]]

=References=

[[#References|[1]]] Wikipedia. (2010, October) Wikipedia - Singleton_Pattern. [Online]. http://en.wikipedia.org/wiki/Singleton_pattern#Traditional_simple_way

[[#References|[2]]] Freeman, Eric, Elisabeth Freeman, Kathy Sierra, and Bert Bates. (October 2004) Head First design patterns. [Print.]

[[#References|[3]]] C# Corner (2010, October) Creational Patterns - Singleton. [Online]. http://www.c-sharpcorner.com/UploadFile/susanabraham/CreationalPatterns06042005050058AM/CreationalPatterns.aspx

[[#References|[4]]] Source Making (2010, October) Singleton Design Pattern. [Online]. http://sourcemaking.com/design_patterns/singleton

[[#References|[5]]] JavaBeginner.com (2010, October) Java Singleton Design Pattern. [Online]. http://www.javabeginner.com/learn-java/java-singleton-design-pattern

[[#References|[6]]] Dalibor Nasevic (2010, October) Ruby Singleton Pattern Again. [Online]. http://dalibornasevic.com/posts/9-ruby-singleton-pattern-again

CSC/ECE 517 Fall 2010/ch3 3f lj

2010-10-14T02:22:15Z

Djfreema: /* Late Instantiation */

'''Singleton Pattern in Static and Dynamic languages'''

=Singleton pattern=

In the Singleton design pattern we create a single instance of a Singleton class. Any instantiation of that Singleton class references the same instance of the class. The pattern also provides a global point of access for the functionality contained in the sole instance of the class. A design pattern is a way for a software developer to handle situations using a known solution that has been proven to be effective in the past. Design patterns also make communicating ideas and concepts between programmers more efficient and understandable.

===Class Diagram===
[[Image:IC73826.gif|500px|center]]

This diagram is a Universal Modeling Languages (UML) diagram of how a Singleton class would look if implemented in Java.
===Sequence Diagram===
[[Image:CR2.gif|500px|center]]

=Implementation=
When this pattern is implemented then it must only have one instantiation of a class and that class must satisfy the global access principles. The pattern requires a mechanism to access the singleton class without instantiating another class object and a mechanism to persist the value of class members among class objects. [[#References|[1]]]

==Creating the instance==
===Early Instantiation===
The instance can be created with a static constructor in static languages. (See the java example below) This means that the single instance is created on program start up and all new methods are private and never used except by the singleton class itself.

In static languages, this is accomplished by setting the constructors to private and controlling creation of instance of the object from within the object itself.

In dynamic languages, this is done by changing the access level of the constructor to prevent use outside the class just as in the static patterns.
===Late Instantiation===
The instance of the class can be created after class loading. (See the C++ example) This can be done by only allocating the instance on the first access of the instance variable.

==Accessing the instance==

In static languages, such as Java, the Singleton class will have a method which returns the instance of the Singleton class so that the other classes can use the functionality encapsulated in the Singleton class.

In dynamic languages, such as Ruby, if a class needs to access the functionality within the Singleton class then it simply needs to access the instance variable @instance and all the functionality therein.

=Examples=
==Java==

Java's API includes a Singleton class which implements the static version of the Singleton pattern. Java's implementation of the Singleton pattern only allows the programmer to create one instance of the Singleton class. The Singleton class automatically creates INSTANCE when it is initialized. The getInstance() method returns the single instance of the class that has been initialized. Java also utilizes a constructor to initialize the Singleton class.
<pre>
private static final Singleton INSTANCE = new Singleton();

// Private constructor prevents instantiation from other classes
private Singleton() {
}

public static Singleton getInstance() {
return INSTANCE;
}
</pre>
[[#References|[1]]]

==Ruby==

Ruby implements the Singleton pattern by privatizing the "new" method and creates an instance variable called @instance. This implementation guarantees that the class will not be able create more than one instantiation of itself and that the system will have the global access privileges since the @instance variable has a global scope. [[#References|[6]]]

<pre>
class genericFactory
include Singleton
end
</pre>
[[#References|[1]]]

<pre>
class Logger
def initialize
@log = File.open("log.txt", "a")
end

@@instance = Logger.new

def self.instance
return @@instance
end

def log(msg)
@log.puts(msg)
end

private_class_method :new
end

Logger.instance.log('message 1')

</pre>
[[#References|[6]]]

==C++==
<pre>
// Declaration
class Singleton {
public:
static Singleton* Instance();
protected:
Singleton();
private:
static Singleton* _instance;
}

// Implementation
Singleton* Singleton::_instance = 0;

Singleton* Singleton::Instance() {
if (_instance == 0) {
_instance = new Singleton;
}
return _instance;
}
</pre>
[[#References|[3]]]

=Benefits=

*This pattern allows the programmer to control the instances of a particular object, it ensures that all objects use the same instance of a class.[[#References|[3]]]

*The Singleton class has the ability to control the instantiation process since it implements the instantiation functionality.[[#References|[3]]]

=Drawbacks=

*Unit tests are much harder to write when using the Singleton pattern.[[#References|[3]]]

*This pattern reduces the potential for parallelism within a program since the threads must be serialized.[[#References|[3]]]

*The overhead of checking whether there is an instance of a class that already exists every time an objects requests a reference. Although the overhead is minuscule, this could be a serious problem for systems which don't have the resources to waste. [[#References|[3]]]

*There may be some development confusion with implementing the singleton class (especially one defined in a class library) because developers may forget that they cannot use the "new" keyword to instantiate the object.[[#References|[3]]]

*The singleton design pattern doesn't address the issue of deleting the single object. Some languages implement memory management which means that the Singleton class can only be unallocated by itself since it holds a private reference to the instance of itself. In languages that don't provide memory management, then the single instance can be deleted but it will cause a dangling reference to that object.[[#References|[3]]]

=References=

[[#References|[1]]] Wikipedia. (2010, October) Wikipedia - Singleton_Pattern. [Online]. http://en.wikipedia.org/wiki/Singleton_pattern#Traditional_simple_way

[[#References|[2]]] Freeman, Eric, Elisabeth Freeman, Kathy Sierra, and Bert Bates. (October 2004) Head First design patterns. [Print.]

[[#References|[3]]] C# Corner (2010, October) Creational Patterns - Singleton. [Online]. http://www.c-sharpcorner.com/UploadFile/susanabraham/CreationalPatterns06042005050058AM/CreationalPatterns.aspx

[[#References|[4]]] Source Making (2010, October) Singleton Design Pattern. [Online]. http://sourcemaking.com/design_patterns/singleton

[[#References|[5]]] JavaBeginner.com (2010, October) Java Singleton Design Pattern. [Online]. http://www.javabeginner.com/learn-java/java-singleton-design-pattern

[[#References|[6]]] Dalibor Nasevic (2010, October) Ruby Singleton Pattern Again. [Online]. http://dalibornasevic.com/posts/9-ruby-singleton-pattern-again

CSC/ECE 517 Fall 2010/ch3 3f lj

2010-10-14T02:20:55Z

Djfreema: /* Ruby */

'''Singleton Pattern in Static and Dynamic languages'''

=Singleton pattern=

In the Singleton design pattern we create a single instance of a Singleton class. Any instantiation of that Singleton class references the same instance of the class. The pattern also provides a global point of access for the functionality contained in the sole instance of the class. A design pattern is a way for a software developer to handle situations using a known solution that has been proven to be effective in the past. Design patterns also make communicating ideas and concepts between programmers more efficient and understandable.

===Class Diagram===
[[Image:IC73826.gif|500px|center]]

This diagram is a Universal Modeling Languages (UML) diagram of how a Singleton class would look if implemented in Java.
===Sequence Diagram===
[[Image:CR2.gif|500px|center]]

=Implementation=
When this pattern is implemented then it must only have one instantiation of a class and that class must satisfy the global access principles. The pattern requires a mechanism to access the singleton class without instantiating another class object and a mechanism to persist the value of class members among class objects. [[#References|[1]]]

==Creating the instance==
===Early Instantiation===
The instance can be created with a static constructor in static languages. (See the java example below) This means that the single instance is created on program start up and all new methods are private and never used except by the singleton class itself.

In static languages, this is accomplished by setting the constructors to private and controlling creation of instance of the object from within the object itself.

In dynamic languages, this is done by changing the access level of the constructor to prevent use outside the class just as in the static patterns.
===Late Instantiation===
The instance of the class can be created after class loading. This can be done by only allocating the instance on the first access of the instance variable.

==Accessing the instance==

In static languages, such as Java, the Singleton class will have a method which returns the instance of the Singleton class so that the other classes can use the functionality encapsulated in the Singleton class.

In dynamic languages, such as Ruby, if a class needs to access the functionality within the Singleton class then it simply needs to access the instance variable @instance and all the functionality therein.

=Examples=
==Java==

Java's API includes a Singleton class which implements the static version of the Singleton pattern. Java's implementation of the Singleton pattern only allows the programmer to create one instance of the Singleton class. The Singleton class automatically creates INSTANCE when it is initialized. The getInstance() method returns the single instance of the class that has been initialized. Java also utilizes a constructor to initialize the Singleton class.
<pre>
private static final Singleton INSTANCE = new Singleton();

// Private constructor prevents instantiation from other classes
private Singleton() {
}

public static Singleton getInstance() {
return INSTANCE;
}
</pre>
[[#References|[1]]]

==Ruby==

Ruby implements the Singleton pattern by privatizing the "new" method and creates an instance variable called @instance. This implementation guarantees that the class will not be able create more than one instantiation of itself and that the system will have the global access privileges since the @instance variable has a global scope. [[#References|[6]]]

<pre>
class genericFactory
include Singleton
end
</pre>
[[#References|[1]]]

<pre>
class Logger
def initialize
@log = File.open("log.txt", "a")
end

@@instance = Logger.new

def self.instance
return @@instance
end

def log(msg)
@log.puts(msg)
end

private_class_method :new
end

Logger.instance.log('message 1')

</pre>
[[#References|[6]]]

==C++==
<pre>
// Declaration
class Singleton {
public:
static Singleton* Instance();
protected:
Singleton();
private:
static Singleton* _instance;
}

// Implementation
Singleton* Singleton::_instance = 0;

Singleton* Singleton::Instance() {
if (_instance == 0) {
_instance = new Singleton;
}
return _instance;
}
</pre>
[[#References|[3]]]

=Benefits=

*This pattern allows the programmer to control the instances of a particular object, it ensures that all objects use the same instance of a class.[[#References|[3]]]

*The Singleton class has the ability to control the instantiation process since it implements the instantiation functionality.[[#References|[3]]]

=Drawbacks=

*Unit tests are much harder to write when using the Singleton pattern.[[#References|[3]]]

*This pattern reduces the potential for parallelism within a program since the threads must be serialized.[[#References|[3]]]

*The overhead of checking whether there is an instance of a class that already exists every time an objects requests a reference. Although the overhead is minuscule, this could be a serious problem for systems which don't have the resources to waste. [[#References|[3]]]

*There may be some development confusion with implementing the singleton class (especially one defined in a class library) because developers may forget that they cannot use the "new" keyword to instantiate the object.[[#References|[3]]]

*The singleton design pattern doesn't address the issue of deleting the single object. Some languages implement memory management which means that the Singleton class can only be unallocated by itself since it holds a private reference to the instance of itself. In languages that don't provide memory management, then the single instance can be deleted but it will cause a dangling reference to that object.[[#References|[3]]]

=References=

[[#References|[1]]] Wikipedia. (2010, October) Wikipedia - Singleton_Pattern. [Online]. http://en.wikipedia.org/wiki/Singleton_pattern#Traditional_simple_way

[[#References|[2]]] Freeman, Eric, Elisabeth Freeman, Kathy Sierra, and Bert Bates. (October 2004) Head First design patterns. [Print.]

[[#References|[3]]] C# Corner (2010, October) Creational Patterns - Singleton. [Online]. http://www.c-sharpcorner.com/UploadFile/susanabraham/CreationalPatterns06042005050058AM/CreationalPatterns.aspx

[[#References|[4]]] Source Making (2010, October) Singleton Design Pattern. [Online]. http://sourcemaking.com/design_patterns/singleton

[[#References|[5]]] JavaBeginner.com (2010, October) Java Singleton Design Pattern. [Online]. http://www.javabeginner.com/learn-java/java-singleton-design-pattern

[[#References|[6]]] Dalibor Nasevic (2010, October) Ruby Singleton Pattern Again. [Online]. http://dalibornasevic.com/posts/9-ruby-singleton-pattern-again

CSC/ECE 517 Fall 2010/ch3 3f lj

2010-10-14T02:19:39Z

Djfreema: /* Ruby */

'''Singleton Pattern in Static and Dynamic languages'''

=Singleton pattern=

In the Singleton design pattern we create a single instance of a Singleton class. Any instantiation of that Singleton class references the same instance of the class. The pattern also provides a global point of access for the functionality contained in the sole instance of the class. A design pattern is a way for a software developer to handle situations using a known solution that has been proven to be effective in the past. Design patterns also make communicating ideas and concepts between programmers more efficient and understandable.

===Class Diagram===
[[Image:IC73826.gif|500px|center]]
===Sequence Diagram===
[[Image:CR2.gif|500px|center]]

=Implementation=
When this pattern is implemented then it must only have one instantiation of a class and that class must satisfy the global access principles. The pattern requires a mechanism to access the singleton class without instantiating another class object and a mechanism to persist the value of class members among class objects. [[#References|[1]]]

==Creating the instance==
===Early Instantiation===
The instance can be created with a static constructor in static languages. (See the java example below) This means that the single instance is created on program start up and all new methods are private and never used except by the singleton class itself.

In static languages, this is accomplished by setting the constructors to private and controlling creation of instance of the object from within the object itself.

In dynamic languages, this is done by changing the access level of the constructor to prevent use outside the class just as in the static patterns.
===Late Instantiation===
The instance of the class can be created after class loading. This can be done by only allocating the instance on the first access of the instance variable.

==Accessing the instance==

In static languages, such as Java, the Singleton class will have a method which returns the instance of the Singleton class so that the other classes can use the functionality encapsulated in the Singleton class.

In dynamic languages, such as Ruby, if a class needs to access the functionality within the Singleton class then it simply needs to access the instance variable @instance and all the functionality therein.

=Examples=
==Java==

Java's API includes a Singleton class which implements the static version of the Singleton pattern. Java's implementation of the Singleton pattern only allows the programmer to create one instance of the Singleton class. The Singleton class automatically creates INSTANCE when it is initialized. The getInstance() method returns the single instance of the class that has been initialized. Java also utilizes a constructor to initialize the Singleton class.
<pre>
private static final Singleton INSTANCE = new Singleton();

// Private constructor prevents instantiation from other classes
private Singleton() {
}

public static Singleton getInstance() {
return INSTANCE;
}
</pre>
[[#References|[1]]]

==Ruby==

Ruby implements the Singleton pattern by privatizing the "new" method and creates an instance variable called @instance. This implementation guarantees that the class will not be able create more than one instantiation of itself and that the system will have the global access privileges since the @instance variable has a global scope.

<pre>
class genericFactory
include Singleton
end
</pre>
[[#References|[1]]]

<pre>
class Logger
def initialize
@log = File.open("log.txt", "a")
end

@@instance = Logger.new

def self.instance
return @@instance
end

def log(msg)
@log.puts(msg)
end

private_class_method :new
end

Logger.instance.log('message 1')

</pre>
[[#References|[6]]]

==C++==
<pre>
// Declaration
class Singleton {
public:
static Singleton* Instance();
protected:
Singleton();
private:
static Singleton* _instance;
}

// Implementation
Singleton* Singleton::_instance = 0;

Singleton* Singleton::Instance() {
if (_instance == 0) {
_instance = new Singleton;
}
return _instance;
}
</pre>
[[#References|[3]]]

=Benefits=

*This pattern allows the programmer to control the instances of a particular object, it ensures that all objects use the same instance of a class.[[#References|[3]]]

*The Singleton class has the ability to control the instantiation process since it implements the instantiation functionality.[[#References|[3]]]

=Drawbacks=

*Unit tests are much harder to write when using the Singleton pattern.[[#References|[3]]]

*This pattern reduces the potential for parallelism within a program since the threads must be serialized.[[#References|[3]]]

*The overhead of checking whether there is an instance of a class that already exists every time an objects requests a reference. Although the overhead is minuscule, this could be a serious problem for systems which don't have the resources to waste. [[#References|[3]]]

*There may be some development confusion with implementing the singleton class (especially one defined in a class library) because developers may forget that they cannot use the "new" keyword to instantiate the object.[[#References|[3]]]

*The singleton design pattern doesn't address the issue of deleting the single object. Some languages implement memory management which means that the Singleton class can only be unallocated by itself since it holds a private reference to the instance of itself. In languages that don't provide memory management, then the single instance can be deleted but it will cause a dangling reference to that object.[[#References|[3]]]

=References=

[[#References|[1]]] Wikipedia. (2010, October) Wikipedia - Singleton_Pattern. [Online]. http://en.wikipedia.org/wiki/Singleton_pattern#Traditional_simple_way

[[#References|[2]]] Freeman, Eric, Elisabeth Freeman, Kathy Sierra, and Bert Bates. (October 2004) Head First design patterns. [Print.]

[[#References|[3]]] C# Corner (2010, October) Creational Patterns - Singleton. [Online]. http://www.c-sharpcorner.com/UploadFile/susanabraham/CreationalPatterns06042005050058AM/CreationalPatterns.aspx

[[#References|[4]]] Source Making (2010, October) Singleton Design Pattern. [Online]. http://sourcemaking.com/design_patterns/singleton

[[#References|[5]]] JavaBeginner.com (2010, October) Java Singleton Design Pattern. [Online]. http://www.javabeginner.com/learn-java/java-singleton-design-pattern

[[#References|[6]]] Dalibor Nasevic (2010, October) Ruby Singleton Pattern Again. [Online]. http://dalibornasevic.com/posts/9-ruby-singleton-pattern-again

CSC/ECE 517 Fall 2010/ch3 3f lj

2010-10-14T02:18:55Z

Djfreema: /* References */

'''Singleton Pattern in Static and Dynamic languages'''

=Singleton pattern=

In the Singleton design pattern we create a single instance of a Singleton class. Any instantiation of that Singleton class references the same instance of the class. The pattern also provides a global point of access for the functionality contained in the sole instance of the class. A design pattern is a way for a software developer to handle situations using a known solution that has been proven to be effective in the past. Design patterns also make communicating ideas and concepts between programmers more efficient and understandable.

===Class Diagram===
[[Image:IC73826.gif|500px|center]]
===Sequence Diagram===
[[Image:CR2.gif|500px|center]]

=Implementation=
When this pattern is implemented then it must only have one instantiation of a class and that class must satisfy the global access principles. The pattern requires a mechanism to access the singleton class without instantiating another class object and a mechanism to persist the value of class members among class objects. [[#References|[1]]]

==Creating the instance==
===Early Instantiation===
The instance can be created with a static constructor in static languages. (See the java example below) This means that the single instance is created on program start up and all new methods are private and never used except by the singleton class itself.

In static languages, this is accomplished by setting the constructors to private and controlling creation of instance of the object from within the object itself.

In dynamic languages, this is done by changing the access level of the constructor to prevent use outside the class just as in the static patterns.
===Late Instantiation===
The instance of the class can be created after class loading. This can be done by only allocating the instance on the first access of the instance variable.

==Accessing the instance==

In static languages, such as Java, the Singleton class will have a method which returns the instance of the Singleton class so that the other classes can use the functionality encapsulated in the Singleton class.

In dynamic languages, such as Ruby, if a class needs to access the functionality within the Singleton class then it simply needs to access the instance variable @instance and all the functionality therein.

=Examples=
==Java==

Java's API includes a Singleton class which implements the static version of the Singleton pattern. Java's implementation of the Singleton pattern only allows the programmer to create one instance of the Singleton class. The Singleton class automatically creates INSTANCE when it is initialized. The getInstance() method returns the single instance of the class that has been initialized. Java also utilizes a constructor to initialize the Singleton class.
<pre>
private static final Singleton INSTANCE = new Singleton();

// Private constructor prevents instantiation from other classes
private Singleton() {
}

public static Singleton getInstance() {
return INSTANCE;
}
</pre>
[[#References|[1]]]

==Ruby==

Ruby implements the Singleton pattern by privatizing the "new" method and creates an instance variable called @instance. This implementation guarantees that the class will not be able create more than one instantiation of itself and that the system will have the global access privileges since the @instance variable has a global scope.

<pre>
class genericFactory
include Singleton
end
</pre>
[[#References|[1]]]

<pre>
class Logger
def initialize
@log = File.open("log.txt", "a")
end

@@instance = Logger.new

def self.instance
return @@instance
end

def log(msg)
@log.puts(msg)
end

private_class_method :new
end

Logger.instance.log('message 1')

</pre>

==C++==
<pre>
// Declaration
class Singleton {
public:
static Singleton* Instance();
protected:
Singleton();
private:
static Singleton* _instance;
}

// Implementation
Singleton* Singleton::_instance = 0;

Singleton* Singleton::Instance() {
if (_instance == 0) {
_instance = new Singleton;
}
return _instance;
}
</pre>
[[#References|[3]]]

=Benefits=

*This pattern allows the programmer to control the instances of a particular object, it ensures that all objects use the same instance of a class.[[#References|[3]]]

*The Singleton class has the ability to control the instantiation process since it implements the instantiation functionality.[[#References|[3]]]

=Drawbacks=

*Unit tests are much harder to write when using the Singleton pattern.[[#References|[3]]]

*This pattern reduces the potential for parallelism within a program since the threads must be serialized.[[#References|[3]]]

*The overhead of checking whether there is an instance of a class that already exists every time an objects requests a reference. Although the overhead is minuscule, this could be a serious problem for systems which don't have the resources to waste. [[#References|[3]]]

*There may be some development confusion with implementing the singleton class (especially one defined in a class library) because developers may forget that they cannot use the "new" keyword to instantiate the object.[[#References|[3]]]

*The singleton design pattern doesn't address the issue of deleting the single object. Some languages implement memory management which means that the Singleton class can only be unallocated by itself since it holds a private reference to the instance of itself. In languages that don't provide memory management, then the single instance can be deleted but it will cause a dangling reference to that object.[[#References|[3]]]

=References=

[[#References|[1]]] Wikipedia. (2010, October) Wikipedia - Singleton_Pattern. [Online]. http://en.wikipedia.org/wiki/Singleton_pattern#Traditional_simple_way

[[#References|[2]]] Freeman, Eric, Elisabeth Freeman, Kathy Sierra, and Bert Bates. (October 2004) Head First design patterns. [Print.]

[[#References|[3]]] C# Corner (2010, October) Creational Patterns - Singleton. [Online]. http://www.c-sharpcorner.com/UploadFile/susanabraham/CreationalPatterns06042005050058AM/CreationalPatterns.aspx

[[#References|[4]]] Source Making (2010, October) Singleton Design Pattern. [Online]. http://sourcemaking.com/design_patterns/singleton

[[#References|[5]]] JavaBeginner.com (2010, October) Java Singleton Design Pattern. [Online]. http://www.javabeginner.com/learn-java/java-singleton-design-pattern

[[#References|[6]]] Dalibor Nasevic (2010, October) Ruby Singleton Pattern Again. [Online]. http://dalibornasevic.com/posts/9-ruby-singleton-pattern-again

CSC/ECE 517 Fall 2010/ch3 3f lj

2010-10-14T02:17:39Z

Djfreema: /* Ruby */

'''Singleton Pattern in Static and Dynamic languages'''

=Singleton pattern=

In the Singleton design pattern we create a single instance of a Singleton class. Any instantiation of that Singleton class references the same instance of the class. The pattern also provides a global point of access for the functionality contained in the sole instance of the class. A design pattern is a way for a software developer to handle situations using a known solution that has been proven to be effective in the past. Design patterns also make communicating ideas and concepts between programmers more efficient and understandable.

===Class Diagram===
[[Image:IC73826.gif|500px|center]]
===Sequence Diagram===
[[Image:CR2.gif|500px|center]]

=Implementation=
When this pattern is implemented then it must only have one instantiation of a class and that class must satisfy the global access principles. The pattern requires a mechanism to access the singleton class without instantiating another class object and a mechanism to persist the value of class members among class objects. [[#References|[1]]]

==Creating the instance==
===Early Instantiation===
The instance can be created with a static constructor in static languages. (See the java example below) This means that the single instance is created on program start up and all new methods are private and never used except by the singleton class itself.

In static languages, this is accomplished by setting the constructors to private and controlling creation of instance of the object from within the object itself.

In dynamic languages, this is done by changing the access level of the constructor to prevent use outside the class just as in the static patterns.
===Late Instantiation===
The instance of the class can be created after class loading. This can be done by only allocating the instance on the first access of the instance variable.

==Accessing the instance==

In static languages, such as Java, the Singleton class will have a method which returns the instance of the Singleton class so that the other classes can use the functionality encapsulated in the Singleton class.

In dynamic languages, such as Ruby, if a class needs to access the functionality within the Singleton class then it simply needs to access the instance variable @instance and all the functionality therein.

=Examples=
==Java==

Java's API includes a Singleton class which implements the static version of the Singleton pattern. Java's implementation of the Singleton pattern only allows the programmer to create one instance of the Singleton class. The Singleton class automatically creates INSTANCE when it is initialized. The getInstance() method returns the single instance of the class that has been initialized. Java also utilizes a constructor to initialize the Singleton class.
<pre>
private static final Singleton INSTANCE = new Singleton();

// Private constructor prevents instantiation from other classes
private Singleton() {
}

public static Singleton getInstance() {
return INSTANCE;
}
</pre>
[[#References|[1]]]

==Ruby==

Ruby implements the Singleton pattern by privatizing the "new" method and creates an instance variable called @instance. This implementation guarantees that the class will not be able create more than one instantiation of itself and that the system will have the global access privileges since the @instance variable has a global scope.

<pre>
class genericFactory
include Singleton
end
</pre>
[[#References|[1]]]

<pre>
class Logger
def initialize
@log = File.open("log.txt", "a")
end

@@instance = Logger.new

def self.instance
return @@instance
end

def log(msg)
@log.puts(msg)
end

private_class_method :new
end

Logger.instance.log('message 1')

</pre>

==C++==
<pre>
// Declaration
class Singleton {
public:
static Singleton* Instance();
protected:
Singleton();
private:
static Singleton* _instance;
}

// Implementation
Singleton* Singleton::_instance = 0;

Singleton* Singleton::Instance() {
if (_instance == 0) {
_instance = new Singleton;
}
return _instance;
}
</pre>
[[#References|[3]]]

=Benefits=

*This pattern allows the programmer to control the instances of a particular object, it ensures that all objects use the same instance of a class.[[#References|[3]]]

*The Singleton class has the ability to control the instantiation process since it implements the instantiation functionality.[[#References|[3]]]

=Drawbacks=

*Unit tests are much harder to write when using the Singleton pattern.[[#References|[3]]]

*This pattern reduces the potential for parallelism within a program since the threads must be serialized.[[#References|[3]]]

*The overhead of checking whether there is an instance of a class that already exists every time an objects requests a reference. Although the overhead is minuscule, this could be a serious problem for systems which don't have the resources to waste. [[#References|[3]]]

*There may be some development confusion with implementing the singleton class (especially one defined in a class library) because developers may forget that they cannot use the "new" keyword to instantiate the object.[[#References|[3]]]

*The singleton design pattern doesn't address the issue of deleting the single object. Some languages implement memory management which means that the Singleton class can only be unallocated by itself since it holds a private reference to the instance of itself. In languages that don't provide memory management, then the single instance can be deleted but it will cause a dangling reference to that object.[[#References|[3]]]

=References=

[[#References|[1]]] Wikipedia. (2010, October) Wikipedia - Singleton_Pattern. [Online]. http://en.wikipedia.org/wiki/Singleton_pattern#Traditional_simple_way

[[#References|[2]]] Freeman, Eric, Elisabeth Freeman, Kathy Sierra, and Bert Bates. (October 2004) Head First design patterns. [Print.]

[[#References|[3]]] C# Corner (2010, October) Creational Patterns - Singleton. [Online]. http://www.c-sharpcorner.com/UploadFile/susanabraham/CreationalPatterns06042005050058AM/CreationalPatterns.aspx

[[#References|[4]]] Source Making (2010, October) Singleton Design Pattern. [Online]. http://sourcemaking.com/design_patterns/singleton

[[#References|[5]]] JavaBeginner.com (2010, October) Java Singleton Design Pattern. [Online]. http://www.javabeginner.com/learn-java/java-singleton-design-pattern

CSC/ECE 517 Fall 2010/ch3 3f lj

2010-10-14T02:15:55Z

Djfreema: /* Benefits */

'''Singleton Pattern in Static and Dynamic languages'''

=Singleton pattern=

In the Singleton design pattern we create a single instance of a Singleton class. Any instantiation of that Singleton class references the same instance of the class. The pattern also provides a global point of access for the functionality contained in the sole instance of the class. A design pattern is a way for a software developer to handle situations using a known solution that has been proven to be effective in the past. Design patterns also make communicating ideas and concepts between programmers more efficient and understandable.

===Class Diagram===
[[Image:IC73826.gif|500px|center]]
===Sequence Diagram===
[[Image:CR2.gif|500px|center]]

=Implementation=
When this pattern is implemented then it must only have one instantiation of a class and that class must satisfy the global access principles. The pattern requires a mechanism to access the singleton class without instantiating another class object and a mechanism to persist the value of class members among class objects. [[#References|[1]]]

==Creating the instance==
===Early Instantiation===
The instance can be created with a static constructor in static languages. (See the java example below) This means that the single instance is created on program start up and all new methods are private and never used except by the singleton class itself.

In static languages, this is accomplished by setting the constructors to private and controlling creation of instance of the object from within the object itself.

In dynamic languages, this is done by changing the access level of the constructor to prevent use outside the class just as in the static patterns.
===Late Instantiation===
The instance of the class can be created after class loading. This can be done by only allocating the instance on the first access of the instance variable.

==Accessing the instance==

In static languages, such as Java, the Singleton class will have a method which returns the instance of the Singleton class so that the other classes can use the functionality encapsulated in the Singleton class.

In dynamic languages, such as Ruby, if a class needs to access the functionality within the Singleton class then it simply needs to access the instance variable @instance and all the functionality therein.

=Examples=
==Java==

Java's API includes a Singleton class which implements the static version of the Singleton pattern. Java's implementation of the Singleton pattern only allows the programmer to create one instance of the Singleton class. The Singleton class automatically creates INSTANCE when it is initialized. The getInstance() method returns the single instance of the class that has been initialized. Java also utilizes a constructor to initialize the Singleton class.
<pre>
private static final Singleton INSTANCE = new Singleton();

// Private constructor prevents instantiation from other classes
private Singleton() {
}

public static Singleton getInstance() {
return INSTANCE;
}
</pre>
[[#References|[1]]]

==Ruby==

Ruby implements the Singleton pattern by privatizing the "new" method and creates an instance variable called @instance. This implementation guarantees that the class will not be able create more than one instantiation of itself and that the system will have the global access privileges since the @instance variable has a global scope.

<pre>
class genericFactory
include Singleton
end
</pre>
[[#References|[1]]]

==C++==
<pre>
// Declaration
class Singleton {
public:
static Singleton* Instance();
protected:
Singleton();
private:
static Singleton* _instance;
}

// Implementation
Singleton* Singleton::_instance = 0;

Singleton* Singleton::Instance() {
if (_instance == 0) {
_instance = new Singleton;
}
return _instance;
}
</pre>
[[#References|[3]]]

=Benefits=

*This pattern allows the programmer to control the instances of a particular object, it ensures that all objects use the same instance of a class.[[#References|[3]]]

*The Singleton class has the ability to control the instantiation process since it implements the instantiation functionality.[[#References|[3]]]

=Drawbacks=

*Unit tests are much harder to write when using the Singleton pattern.[[#References|[3]]]

*This pattern reduces the potential for parallelism within a program since the threads must be serialized.[[#References|[3]]]

*The overhead of checking whether there is an instance of a class that already exists every time an objects requests a reference. Although the overhead is minuscule, this could be a serious problem for systems which don't have the resources to waste. [[#References|[3]]]

*There may be some development confusion with implementing the singleton class (especially one defined in a class library) because developers may forget that they cannot use the "new" keyword to instantiate the object.[[#References|[3]]]

*The singleton design pattern doesn't address the issue of deleting the single object. Some languages implement memory management which means that the Singleton class can only be unallocated by itself since it holds a private reference to the instance of itself. In languages that don't provide memory management, then the single instance can be deleted but it will cause a dangling reference to that object.[[#References|[3]]]

=References=

[[#References|[1]]] Wikipedia. (2010, October) Wikipedia - Singleton_Pattern. [Online]. http://en.wikipedia.org/wiki/Singleton_pattern#Traditional_simple_way

[[#References|[2]]] Freeman, Eric, Elisabeth Freeman, Kathy Sierra, and Bert Bates. (October 2004) Head First design patterns. [Print.]

[[#References|[3]]] C# Corner (2010, October) Creational Patterns - Singleton. [Online]. http://www.c-sharpcorner.com/UploadFile/susanabraham/CreationalPatterns06042005050058AM/CreationalPatterns.aspx

[[#References|[4]]] Source Making (2010, October) Singleton Design Pattern. [Online]. http://sourcemaking.com/design_patterns/singleton

[[#References|[5]]] JavaBeginner.com (2010, October) Java Singleton Design Pattern. [Online]. http://www.javabeginner.com/learn-java/java-singleton-design-pattern

CSC/ECE 517 Fall 2010/ch3 3f lj

2010-10-14T02:15:45Z

Djfreema: /* Drawbacks */

'''Singleton Pattern in Static and Dynamic languages'''

=Singleton pattern=

In the Singleton design pattern we create a single instance of a Singleton class. Any instantiation of that Singleton class references the same instance of the class. The pattern also provides a global point of access for the functionality contained in the sole instance of the class. A design pattern is a way for a software developer to handle situations using a known solution that has been proven to be effective in the past. Design patterns also make communicating ideas and concepts between programmers more efficient and understandable.

===Class Diagram===
[[Image:IC73826.gif|500px|center]]
===Sequence Diagram===
[[Image:CR2.gif|500px|center]]

=Implementation=
When this pattern is implemented then it must only have one instantiation of a class and that class must satisfy the global access principles. The pattern requires a mechanism to access the singleton class without instantiating another class object and a mechanism to persist the value of class members among class objects. [[#References|[1]]]

==Creating the instance==
===Early Instantiation===
The instance can be created with a static constructor in static languages. (See the java example below) This means that the single instance is created on program start up and all new methods are private and never used except by the singleton class itself.

In static languages, this is accomplished by setting the constructors to private and controlling creation of instance of the object from within the object itself.

In dynamic languages, this is done by changing the access level of the constructor to prevent use outside the class just as in the static patterns.
===Late Instantiation===
The instance of the class can be created after class loading. This can be done by only allocating the instance on the first access of the instance variable.

==Accessing the instance==

In static languages, such as Java, the Singleton class will have a method which returns the instance of the Singleton class so that the other classes can use the functionality encapsulated in the Singleton class.

In dynamic languages, such as Ruby, if a class needs to access the functionality within the Singleton class then it simply needs to access the instance variable @instance and all the functionality therein.

=Examples=
==Java==

Java's API includes a Singleton class which implements the static version of the Singleton pattern. Java's implementation of the Singleton pattern only allows the programmer to create one instance of the Singleton class. The Singleton class automatically creates INSTANCE when it is initialized. The getInstance() method returns the single instance of the class that has been initialized. Java also utilizes a constructor to initialize the Singleton class.
<pre>
private static final Singleton INSTANCE = new Singleton();

// Private constructor prevents instantiation from other classes
private Singleton() {
}

public static Singleton getInstance() {
return INSTANCE;
}
</pre>
[[#References|[1]]]

==Ruby==

Ruby implements the Singleton pattern by privatizing the "new" method and creates an instance variable called @instance. This implementation guarantees that the class will not be able create more than one instantiation of itself and that the system will have the global access privileges since the @instance variable has a global scope.

<pre>
class genericFactory
include Singleton
end
</pre>
[[#References|[1]]]

==C++==
<pre>
// Declaration
class Singleton {
public:
static Singleton* Instance();
protected:
Singleton();
private:
static Singleton* _instance;
}

// Implementation
Singleton* Singleton::_instance = 0;

Singleton* Singleton::Instance() {
if (_instance == 0) {
_instance = new Singleton;
}
return _instance;
}
</pre>
[[#References|[3]]]

=Benefits=

*This pattern allows the programmer to control the instances of a particular object, it ensures that all objects use the same instance of a class.

*The Singleton class has the ability to control the instantiation process since it implements the instantiation functionality.

=Drawbacks=

*Unit tests are much harder to write when using the Singleton pattern.[[#References|[3]]]

*This pattern reduces the potential for parallelism within a program since the threads must be serialized.[[#References|[3]]]

*The overhead of checking whether there is an instance of a class that already exists every time an objects requests a reference. Although the overhead is minuscule, this could be a serious problem for systems which don't have the resources to waste. [[#References|[3]]]

*There may be some development confusion with implementing the singleton class (especially one defined in a class library) because developers may forget that they cannot use the "new" keyword to instantiate the object.[[#References|[3]]]

*The singleton design pattern doesn't address the issue of deleting the single object. Some languages implement memory management which means that the Singleton class can only be unallocated by itself since it holds a private reference to the instance of itself. In languages that don't provide memory management, then the single instance can be deleted but it will cause a dangling reference to that object.[[#References|[3]]]

=References=

[[#References|[1]]] Wikipedia. (2010, October) Wikipedia - Singleton_Pattern. [Online]. http://en.wikipedia.org/wiki/Singleton_pattern#Traditional_simple_way

[[#References|[2]]] Freeman, Eric, Elisabeth Freeman, Kathy Sierra, and Bert Bates. (October 2004) Head First design patterns. [Print.]

[[#References|[3]]] C# Corner (2010, October) Creational Patterns - Singleton. [Online]. http://www.c-sharpcorner.com/UploadFile/susanabraham/CreationalPatterns06042005050058AM/CreationalPatterns.aspx

[[#References|[4]]] Source Making (2010, October) Singleton Design Pattern. [Online]. http://sourcemaking.com/design_patterns/singleton

[[#References|[5]]] JavaBeginner.com (2010, October) Java Singleton Design Pattern. [Online]. http://www.javabeginner.com/learn-java/java-singleton-design-pattern

CSC/ECE 517 Fall 2010/ch3 3f lj

2010-10-14T02:15:18Z

Djfreema: /* C++ */

'''Singleton Pattern in Static and Dynamic languages'''

=Singleton pattern=

In the Singleton design pattern we create a single instance of a Singleton class. Any instantiation of that Singleton class references the same instance of the class. The pattern also provides a global point of access for the functionality contained in the sole instance of the class. A design pattern is a way for a software developer to handle situations using a known solution that has been proven to be effective in the past. Design patterns also make communicating ideas and concepts between programmers more efficient and understandable.

===Class Diagram===
[[Image:IC73826.gif|500px|center]]
===Sequence Diagram===
[[Image:CR2.gif|500px|center]]

=Implementation=
When this pattern is implemented then it must only have one instantiation of a class and that class must satisfy the global access principles. The pattern requires a mechanism to access the singleton class without instantiating another class object and a mechanism to persist the value of class members among class objects. [[#References|[1]]]

==Creating the instance==
===Early Instantiation===
The instance can be created with a static constructor in static languages. (See the java example below) This means that the single instance is created on program start up and all new methods are private and never used except by the singleton class itself.

In static languages, this is accomplished by setting the constructors to private and controlling creation of instance of the object from within the object itself.

In dynamic languages, this is done by changing the access level of the constructor to prevent use outside the class just as in the static patterns.
===Late Instantiation===
The instance of the class can be created after class loading. This can be done by only allocating the instance on the first access of the instance variable.

==Accessing the instance==

In static languages, such as Java, the Singleton class will have a method which returns the instance of the Singleton class so that the other classes can use the functionality encapsulated in the Singleton class.

In dynamic languages, such as Ruby, if a class needs to access the functionality within the Singleton class then it simply needs to access the instance variable @instance and all the functionality therein.

=Examples=
==Java==

Java's API includes a Singleton class which implements the static version of the Singleton pattern. Java's implementation of the Singleton pattern only allows the programmer to create one instance of the Singleton class. The Singleton class automatically creates INSTANCE when it is initialized. The getInstance() method returns the single instance of the class that has been initialized. Java also utilizes a constructor to initialize the Singleton class.
<pre>
private static final Singleton INSTANCE = new Singleton();

// Private constructor prevents instantiation from other classes
private Singleton() {
}

public static Singleton getInstance() {
return INSTANCE;
}
</pre>
[[#References|[1]]]

==Ruby==

Ruby implements the Singleton pattern by privatizing the "new" method and creates an instance variable called @instance. This implementation guarantees that the class will not be able create more than one instantiation of itself and that the system will have the global access privileges since the @instance variable has a global scope.

<pre>
class genericFactory
include Singleton
end
</pre>
[[#References|[1]]]

==C++==
<pre>
// Declaration
class Singleton {
public:
static Singleton* Instance();
protected:
Singleton();
private:
static Singleton* _instance;
}

// Implementation
Singleton* Singleton::_instance = 0;

Singleton* Singleton::Instance() {
if (_instance == 0) {
_instance = new Singleton;
}
return _instance;
}
</pre>
[[#References|[3]]]

=Benefits=

*This pattern allows the programmer to control the instances of a particular object, it ensures that all objects use the same instance of a class.

*The Singleton class has the ability to control the instantiation process since it implements the instantiation functionality.

=Drawbacks=

*Unit tests are much harder to write when using the Singleton pattern

*This pattern reduces the potential for parallelism within a program since the threads must be serialized.

*The overhead of checking whether there is an instance of a class that already exists every time an objects requests a reference. Although the overhead is minuscule, this could be a serious problem for systems which don't have the resources to waste.

*There may be some development confusion with implementing the singleton class (especially one defined in a class library) because developers may forget that they cannot use the "new" keyword to instantiate the object.

*The singleton design pattern doesn't address the issue of deleting the single object. Some languages implement memory management which means that the Singleton class can only be unallocated by itself since it holds a private reference to the instance of itself. In languages that don't provide memory management, then the single instance can be deleted but it will cause a dangling reference to that object.

=References=

[[#References|[1]]] Wikipedia. (2010, October) Wikipedia - Singleton_Pattern. [Online]. http://en.wikipedia.org/wiki/Singleton_pattern#Traditional_simple_way

[[#References|[2]]] Freeman, Eric, Elisabeth Freeman, Kathy Sierra, and Bert Bates. (October 2004) Head First design patterns. [Print.]

[[#References|[3]]] C# Corner (2010, October) Creational Patterns - Singleton. [Online]. http://www.c-sharpcorner.com/UploadFile/susanabraham/CreationalPatterns06042005050058AM/CreationalPatterns.aspx

[[#References|[4]]] Source Making (2010, October) Singleton Design Pattern. [Online]. http://sourcemaking.com/design_patterns/singleton

[[#References|[5]]] JavaBeginner.com (2010, October) Java Singleton Design Pattern. [Online]. http://www.javabeginner.com/learn-java/java-singleton-design-pattern

CSC/ECE 517 Fall 2010/ch3 3f lj

2010-10-14T02:14:06Z

Djfreema: /* Singleton pattern */

'''Singleton Pattern in Static and Dynamic languages'''

=Singleton pattern=

In the Singleton design pattern we create a single instance of a Singleton class. Any instantiation of that Singleton class references the same instance of the class. The pattern also provides a global point of access for the functionality contained in the sole instance of the class. A design pattern is a way for a software developer to handle situations using a known solution that has been proven to be effective in the past. Design patterns also make communicating ideas and concepts between programmers more efficient and understandable.

===Class Diagram===
[[Image:IC73826.gif|500px|center]]
===Sequence Diagram===
[[Image:CR2.gif|500px|center]]

=Implementation=
When this pattern is implemented then it must only have one instantiation of a class and that class must satisfy the global access principles. The pattern requires a mechanism to access the singleton class without instantiating another class object and a mechanism to persist the value of class members among class objects. [[#References|[1]]]

==Creating the instance==
===Early Instantiation===
The instance can be created with a static constructor in static languages. (See the java example below) This means that the single instance is created on program start up and all new methods are private and never used except by the singleton class itself.

In static languages, this is accomplished by setting the constructors to private and controlling creation of instance of the object from within the object itself.

In dynamic languages, this is done by changing the access level of the constructor to prevent use outside the class just as in the static patterns.
===Late Instantiation===
The instance of the class can be created after class loading. This can be done by only allocating the instance on the first access of the instance variable.

==Accessing the instance==

In static languages, such as Java, the Singleton class will have a method which returns the instance of the Singleton class so that the other classes can use the functionality encapsulated in the Singleton class.

In dynamic languages, such as Ruby, if a class needs to access the functionality within the Singleton class then it simply needs to access the instance variable @instance and all the functionality therein.

=Examples=
==Java==

Java's API includes a Singleton class which implements the static version of the Singleton pattern. Java's implementation of the Singleton pattern only allows the programmer to create one instance of the Singleton class. The Singleton class automatically creates INSTANCE when it is initialized. The getInstance() method returns the single instance of the class that has been initialized. Java also utilizes a constructor to initialize the Singleton class.
<pre>
private static final Singleton INSTANCE = new Singleton();

// Private constructor prevents instantiation from other classes
private Singleton() {
}

public static Singleton getInstance() {
return INSTANCE;
}
</pre>
[[#References|[1]]]

==Ruby==

Ruby implements the Singleton pattern by privatizing the "new" method and creates an instance variable called @instance. This implementation guarantees that the class will not be able create more than one instantiation of itself and that the system will have the global access privileges since the @instance variable has a global scope.

<pre>
class genericFactory
include Singleton
end
</pre>
[[#References|[1]]]

==C++==
<pre>
// Declaration
class Singleton {
public:
static Singleton* Instance();
protected:
Singleton();
private:
static Singleton* _instance;
}

// Implementation
Singleton* Singleton::_instance = 0;

Singleton* Singleton::Instance() {
if (_instance == 0) {
_instance = new Singleton;
}
return _instance;
}
</pre>
[[#References|[1]]]

=Benefits=

*This pattern allows the programmer to control the instances of a particular object, it ensures that all objects use the same instance of a class.

*The Singleton class has the ability to control the instantiation process since it implements the instantiation functionality.

=Drawbacks=

*Unit tests are much harder to write when using the Singleton pattern

*This pattern reduces the potential for parallelism within a program since the threads must be serialized.

*The overhead of checking whether there is an instance of a class that already exists every time an objects requests a reference. Although the overhead is minuscule, this could be a serious problem for systems which don't have the resources to waste.

*There may be some development confusion with implementing the singleton class (especially one defined in a class library) because developers may forget that they cannot use the "new" keyword to instantiate the object.

*The singleton design pattern doesn't address the issue of deleting the single object. Some languages implement memory management which means that the Singleton class can only be unallocated by itself since it holds a private reference to the instance of itself. In languages that don't provide memory management, then the single instance can be deleted but it will cause a dangling reference to that object.

=References=

[[#References|[1]]] Wikipedia. (2010, October) Wikipedia - Singleton_Pattern. [Online]. http://en.wikipedia.org/wiki/Singleton_pattern#Traditional_simple_way

[[#References|[2]]] Freeman, Eric, Elisabeth Freeman, Kathy Sierra, and Bert Bates. (October 2004) Head First design patterns. [Print.]

[[#References|[3]]] C# Corner (2010, October) Creational Patterns - Singleton. [Online]. http://www.c-sharpcorner.com/UploadFile/susanabraham/CreationalPatterns06042005050058AM/CreationalPatterns.aspx

[[#References|[4]]] Source Making (2010, October) Singleton Design Pattern. [Online]. http://sourcemaking.com/design_patterns/singleton

[[#References|[5]]] JavaBeginner.com (2010, October) Java Singleton Design Pattern. [Online]. http://www.javabeginner.com/learn-java/java-singleton-design-pattern

CSC/ECE 517 Fall 2010/ch3 3f lj

2010-10-14T02:13:45Z

Djfreema:

'''Singleton Pattern in Static and Dynamic languages'''

=Singleton pattern=
==test==
In the Singleton design pattern we create a single instance of a Singleton class. Any instantiation of that Singleton class references the same instance of the class. The pattern also provides a global point of access for the functionality contained in the sole instance of the class. A design pattern is a way for a software developer to handle situations using a known solution that has been proven to be effective in the past. Design patterns also make communicating ideas and concepts between programmers more efficient and understandable.

===Class Diagram===
[[Image:IC73826.gif|500px|center]]
===Sequence Diagram===
[[Image:CR2.gif|500px|center]]

=Implementation=
When this pattern is implemented then it must only have one instantiation of a class and that class must satisfy the global access principles. The pattern requires a mechanism to access the singleton class without instantiating another class object and a mechanism to persist the value of class members among class objects. [[#References|[1]]]

==Creating the instance==
===Early Instantiation===
The instance can be created with a static constructor in static languages. (See the java example below) This means that the single instance is created on program start up and all new methods are private and never used except by the singleton class itself.

In static languages, this is accomplished by setting the constructors to private and controlling creation of instance of the object from within the object itself.

In dynamic languages, this is done by changing the access level of the constructor to prevent use outside the class just as in the static patterns.
===Late Instantiation===
The instance of the class can be created after class loading. This can be done by only allocating the instance on the first access of the instance variable.

==Accessing the instance==

In static languages, such as Java, the Singleton class will have a method which returns the instance of the Singleton class so that the other classes can use the functionality encapsulated in the Singleton class.

In dynamic languages, such as Ruby, if a class needs to access the functionality within the Singleton class then it simply needs to access the instance variable @instance and all the functionality therein.

=Examples=
==Java==

Java's API includes a Singleton class which implements the static version of the Singleton pattern. Java's implementation of the Singleton pattern only allows the programmer to create one instance of the Singleton class. The Singleton class automatically creates INSTANCE when it is initialized. The getInstance() method returns the single instance of the class that has been initialized. Java also utilizes a constructor to initialize the Singleton class.
<pre>
private static final Singleton INSTANCE = new Singleton();

// Private constructor prevents instantiation from other classes
private Singleton() {
}

public static Singleton getInstance() {
return INSTANCE;
}
</pre>
[[#References|[1]]]

==Ruby==

Ruby implements the Singleton pattern by privatizing the "new" method and creates an instance variable called @instance. This implementation guarantees that the class will not be able create more than one instantiation of itself and that the system will have the global access privileges since the @instance variable has a global scope.

<pre>
class genericFactory
include Singleton
end
</pre>
[[#References|[1]]]

==C++==
<pre>
// Declaration
class Singleton {
public:
static Singleton* Instance();
protected:
Singleton();
private:
static Singleton* _instance;
}

// Implementation
Singleton* Singleton::_instance = 0;

Singleton* Singleton::Instance() {
if (_instance == 0) {
_instance = new Singleton;
}
return _instance;
}
</pre>
[[#References|[1]]]

=Benefits=

*This pattern allows the programmer to control the instances of a particular object, it ensures that all objects use the same instance of a class.

*The Singleton class has the ability to control the instantiation process since it implements the instantiation functionality.

=Drawbacks=

*Unit tests are much harder to write when using the Singleton pattern

*This pattern reduces the potential for parallelism within a program since the threads must be serialized.

*The overhead of checking whether there is an instance of a class that already exists every time an objects requests a reference. Although the overhead is minuscule, this could be a serious problem for systems which don't have the resources to waste.

*There may be some development confusion with implementing the singleton class (especially one defined in a class library) because developers may forget that they cannot use the "new" keyword to instantiate the object.

*The singleton design pattern doesn't address the issue of deleting the single object. Some languages implement memory management which means that the Singleton class can only be unallocated by itself since it holds a private reference to the instance of itself. In languages that don't provide memory management, then the single instance can be deleted but it will cause a dangling reference to that object.

=References=

[[#References|[1]]] Wikipedia. (2010, October) Wikipedia - Singleton_Pattern. [Online]. http://en.wikipedia.org/wiki/Singleton_pattern#Traditional_simple_way

[[#References|[2]]] Freeman, Eric, Elisabeth Freeman, Kathy Sierra, and Bert Bates. (October 2004) Head First design patterns. [Print.]

[[#References|[3]]] C# Corner (2010, October) Creational Patterns - Singleton. [Online]. http://www.c-sharpcorner.com/UploadFile/susanabraham/CreationalPatterns06042005050058AM/CreationalPatterns.aspx

[[#References|[4]]] Source Making (2010, October) Singleton Design Pattern. [Online]. http://sourcemaking.com/design_patterns/singleton

[[#References|[5]]] JavaBeginner.com (2010, October) Java Singleton Design Pattern. [Online]. http://www.javabeginner.com/learn-java/java-singleton-design-pattern

CSC/ECE 517 Fall 2010/ch3 3f lj

2010-10-14T02:09:53Z

Djfreema: /* Java */

'''Singleton Pattern in Static and Dynamic languages'''

=Singleton pattern=
==Defintions==
In the Singleton design pattern we create a single instance of a Singleton class. Any instantiation of that Singleton class references the same instance of the class. The pattern also provides a global point of access for the functionality contained in the sole instance of the class. A design pattern is a way for a software developer to handle situations using a known solution that has been proven to be effective in the past. Design patterns also make communicating ideas and concepts between programmers more efficient and understandable.

===Class Diagram===
[[Image:IC73826.gif|500px|center]]
===Sequence Diagram===
[[Image:CR2.gif|500px|center]]

=Implementation=
When this pattern is implemented then it must only have one instantiation of a class and that class must satisfy the global access principles. The pattern requires a mechanism to access the singleton class without instantiating another class object and a mechanism to persist the value of class members among class objects. [[#References|[1]]]

==Creating the instance==
===Early Instantiation===
The instance can be created with a static constructor in static languages. (See the java example below) This means that the single instance is created on program start up and all new methods are private and never used except by the singleton class itself.

In static languages, this is accomplished by setting the constructors to private and controlling creation of instance of the object from within the object itself.

In dynamic languages, this is done by changing the access level of the constructor to prevent use outside the class just as in the static patterns.
===Late Instantiation===
The instance of the class can be created after class loading. This can be done by only allocating the instance on the first access of the instance variable.

==Accessing the instance==

In static languages, such as Java, the Singleton class will have a method which returns the instance of the Singleton class so that the other classes can use the functionality encapsulated in the Singleton class.

In dynamic languages, such as Ruby, if a class needs to access the functionality within the Singleton class then it simply needs to access the instance variable @instance and all the functionality therein.

=Examples=
==Java==

Java's API includes a Singleton class which implements the static version of the Singleton pattern. Java's implementation of the Singleton pattern only allows the programmer to create one instance of the Singleton class. The Singleton class automatically creates INSTANCE when it is initialized. The getInstance() method returns the single instance of the class that has been initialized. Java also utilizes a constructor to initialize the Singleton class.
<pre>
private static final Singleton INSTANCE = new Singleton();

// Private constructor prevents instantiation from other classes
private Singleton() {
}

public static Singleton getInstance() {
return INSTANCE;
}
</pre>
[[#References|[1]]]

==Ruby==

Ruby implements the Singleton pattern by privatizing the "new" method and creates an instance variable called @instance. This implementation guarantees that the class will not be able create more than one instantiation of itself and that the system will have the global access privileges since the @instance variable has a global scope.

<pre>
class genericFactory
include Singleton
end
</pre>
[[#References|[1]]]

==C++==
<pre>
// Declaration
class Singleton {
public:
static Singleton* Instance();
protected:
Singleton();
private:
static Singleton* _instance;
}

// Implementation
Singleton* Singleton::_instance = 0;

Singleton* Singleton::Instance() {
if (_instance == 0) {
_instance = new Singleton;
}
return _instance;
}
</pre>
[[#References|[1]]]

=Benefits=

*This pattern allows the programmer to control the instances of a particular object, it ensures that all objects use the same instance of a class.

*The Singleton class has the ability to control the instantiation process since it implements the instantiation functionality.

=Drawbacks=

*Unit tests are much harder to write when using the Singleton pattern

*This pattern reduces the potential for parallelism within a program since the threads must be serialized.

*The overhead of checking whether there is an instance of a class that already exists every time an objects requests a reference. Although the overhead is minuscule, this could be a serious problem for systems which don't have the resources to waste.

*There may be some development confusion with implementing the singleton class (especially one defined in a class library) because developers may forget that they cannot use the "new" keyword to instantiate the object.

*The singleton design pattern doesn't address the issue of deleting the single object. Some languages implement memory management which means that the Singleton class can only be unallocated by itself since it holds a private reference to the instance of itself. In languages that don't provide memory management, then the single instance can be deleted but it will cause a dangling reference to that object.

=References=

[[#References|[1]]] Wikipedia. (2010, October) Wikipedia - Singleton_Pattern. [Online]. http://en.wikipedia.org/wiki/Singleton_pattern#Traditional_simple_way

[[#References|[2]]] Freeman, Eric, Elisabeth Freeman, Kathy Sierra, and Bert Bates. (October 2004) Head First design patterns. [Print.]

[[#References|[3]]] C# Corner (2010, October) Creational Patterns - Singleton. [Online]. http://www.c-sharpcorner.com/UploadFile/susanabraham/CreationalPatterns06042005050058AM/CreationalPatterns.aspx

[[#References|[4]]] Source Making (2010, October) Singleton Design Pattern. [Online]. http://sourcemaking.com/design_patterns/singleton

[[#References|[5]]] JavaBeginner.com (2010, October) Java Singleton Design Pattern. [Online]. http://www.javabeginner.com/learn-java/java-singleton-design-pattern

CSC/ECE 517 Fall 2010/ch3 3f lj

2010-10-14T02:09:42Z

Djfreema: /* Ruby */

'''Singleton Pattern in Static and Dynamic languages'''

=Singleton pattern=
==Defintions==
In the Singleton design pattern we create a single instance of a Singleton class. Any instantiation of that Singleton class references the same instance of the class. The pattern also provides a global point of access for the functionality contained in the sole instance of the class. A design pattern is a way for a software developer to handle situations using a known solution that has been proven to be effective in the past. Design patterns also make communicating ideas and concepts between programmers more efficient and understandable.

===Class Diagram===
[[Image:IC73826.gif|500px|center]]
===Sequence Diagram===
[[Image:CR2.gif|500px|center]]

=Implementation=
When this pattern is implemented then it must only have one instantiation of a class and that class must satisfy the global access principles. The pattern requires a mechanism to access the singleton class without instantiating another class object and a mechanism to persist the value of class members among class objects. [[#References|[1]]]

==Creating the instance==
===Early Instantiation===
The instance can be created with a static constructor in static languages. (See the java example below) This means that the single instance is created on program start up and all new methods are private and never used except by the singleton class itself.

In static languages, this is accomplished by setting the constructors to private and controlling creation of instance of the object from within the object itself.

In dynamic languages, this is done by changing the access level of the constructor to prevent use outside the class just as in the static patterns.
===Late Instantiation===
The instance of the class can be created after class loading. This can be done by only allocating the instance on the first access of the instance variable.

==Accessing the instance==

In static languages, such as Java, the Singleton class will have a method which returns the instance of the Singleton class so that the other classes can use the functionality encapsulated in the Singleton class.

In dynamic languages, such as Ruby, if a class needs to access the functionality within the Singleton class then it simply needs to access the instance variable @instance and all the functionality therein.

=Examples=
==Java==

Java's API includes a Singleton class which implements the static version of the Singleton pattern. Java's implementation of the Singleton pattern only allows the programmer to create one instance of the Singleton class. The Singleton class automatically creates INSTANCE when it is initialized. The getInstance() method returns the single instance of the class that has been initialized. Java also utilizes a constructor to initialize the Singleton class.
<pre>
private static final Singleton INSTANCE = new Singleton();

// Private constructor prevents instantiation from other classes
private Singleton() {
}

public static Singleton getInstance() {
return INSTANCE;
}
</pre>

==Ruby==

Ruby implements the Singleton pattern by privatizing the "new" method and creates an instance variable called @instance. This implementation guarantees that the class will not be able create more than one instantiation of itself and that the system will have the global access privileges since the @instance variable has a global scope.

<pre>
class genericFactory
include Singleton
end
</pre>
[[#References|[1]]]

==C++==
<pre>
// Declaration
class Singleton {
public:
static Singleton* Instance();
protected:
Singleton();
private:
static Singleton* _instance;
}

// Implementation
Singleton* Singleton::_instance = 0;

Singleton* Singleton::Instance() {
if (_instance == 0) {
_instance = new Singleton;
}
return _instance;
}
</pre>
[[#References|[1]]]

=Benefits=

*This pattern allows the programmer to control the instances of a particular object, it ensures that all objects use the same instance of a class.

*The Singleton class has the ability to control the instantiation process since it implements the instantiation functionality.

=Drawbacks=

*Unit tests are much harder to write when using the Singleton pattern

*This pattern reduces the potential for parallelism within a program since the threads must be serialized.

*The overhead of checking whether there is an instance of a class that already exists every time an objects requests a reference. Although the overhead is minuscule, this could be a serious problem for systems which don't have the resources to waste.

*There may be some development confusion with implementing the singleton class (especially one defined in a class library) because developers may forget that they cannot use the "new" keyword to instantiate the object.

*The singleton design pattern doesn't address the issue of deleting the single object. Some languages implement memory management which means that the Singleton class can only be unallocated by itself since it holds a private reference to the instance of itself. In languages that don't provide memory management, then the single instance can be deleted but it will cause a dangling reference to that object.

=References=

[[#References|[1]]] Wikipedia. (2010, October) Wikipedia - Singleton_Pattern. [Online]. http://en.wikipedia.org/wiki/Singleton_pattern#Traditional_simple_way

[[#References|[2]]] Freeman, Eric, Elisabeth Freeman, Kathy Sierra, and Bert Bates. (October 2004) Head First design patterns. [Print.]

[[#References|[3]]] C# Corner (2010, October) Creational Patterns - Singleton. [Online]. http://www.c-sharpcorner.com/UploadFile/susanabraham/CreationalPatterns06042005050058AM/CreationalPatterns.aspx

[[#References|[4]]] Source Making (2010, October) Singleton Design Pattern. [Online]. http://sourcemaking.com/design_patterns/singleton

[[#References|[5]]] JavaBeginner.com (2010, October) Java Singleton Design Pattern. [Online]. http://www.javabeginner.com/learn-java/java-singleton-design-pattern

CSC/ECE 517 Fall 2010/ch3 3f lj

2010-10-14T02:08:21Z

Djfreema: /* References */

'''Singleton Pattern in Static and Dynamic languages'''

=Singleton pattern=
==Defintions==
In the Singleton design pattern we create a single instance of a Singleton class. Any instantiation of that Singleton class references the same instance of the class. The pattern also provides a global point of access for the functionality contained in the sole instance of the class. A design pattern is a way for a software developer to handle situations using a known solution that has been proven to be effective in the past. Design patterns also make communicating ideas and concepts between programmers more efficient and understandable.

===Class Diagram===
[[Image:IC73826.gif|500px|center]]
===Sequence Diagram===
[[Image:CR2.gif|500px|center]]

=Implementation=
When this pattern is implemented then it must only have one instantiation of a class and that class must satisfy the global access principles. The pattern requires a mechanism to access the singleton class without instantiating another class object and a mechanism to persist the value of class members among class objects. [[#References|[1]]]

==Creating the instance==
===Early Instantiation===
The instance can be created with a static constructor in static languages. (See the java example below) This means that the single instance is created on program start up and all new methods are private and never used except by the singleton class itself.

In static languages, this is accomplished by setting the constructors to private and controlling creation of instance of the object from within the object itself.

In dynamic languages, this is done by changing the access level of the constructor to prevent use outside the class just as in the static patterns.
===Late Instantiation===
The instance of the class can be created after class loading. This can be done by only allocating the instance on the first access of the instance variable.

==Accessing the instance==

In static languages, such as Java, the Singleton class will have a method which returns the instance of the Singleton class so that the other classes can use the functionality encapsulated in the Singleton class.

In dynamic languages, such as Ruby, if a class needs to access the functionality within the Singleton class then it simply needs to access the instance variable @instance and all the functionality therein.

=Examples=
==Java==

Java's API includes a Singleton class which implements the static version of the Singleton pattern. Java's implementation of the Singleton pattern only allows the programmer to create one instance of the Singleton class. The Singleton class automatically creates INSTANCE when it is initialized. The getInstance() method returns the single instance of the class that has been initialized. Java also utilizes a constructor to initialize the Singleton class.
<pre>
private static final Singleton INSTANCE = new Singleton();

// Private constructor prevents instantiation from other classes
private Singleton() {
}

public static Singleton getInstance() {
return INSTANCE;
}
</pre>

==Ruby==

Ruby implements the Singleton pattern by privatizing the "new" method and creates an instance variable called @instance. This implementation guarantees that the class will not be able create more than one instantiation of itself and that the system will have the global access privileges since the @instance variable has a global scope.

<pre>
class genericFactory
include Singleton
end
</pre>

==C++==
<pre>
// Declaration
class Singleton {
public:
static Singleton* Instance();
protected:
Singleton();
private:
static Singleton* _instance;
}

// Implementation
Singleton* Singleton::_instance = 0;

Singleton* Singleton::Instance() {
if (_instance == 0) {
_instance = new Singleton;
}
return _instance;
}
</pre>
[[#References|[1]]]

=Drawbacks=

*Unit tests are much harder to write when using the Singleton pattern

*This pattern reduces the potential for parallelism within a program since the threads must be serialized.

*The overhead of checking whether there is an instance of a class that already exists every time an objects requests a reference. Although the overhead is minuscule, this could be a serious problem for systems which don't have the resources to waste.

*There may be some development confusion with implementing the singleton class (especially one defined in a class library) because developers may forget that they cannot use the "new" keyword to instantiate the object.

*The singleton design pattern doesn't address the issue of deleting the single object. Some languages implement memory management which means that the Singleton class can only be unallocated by itself since it holds a private reference to the instance of itself. In languages that don't provide memory management, then the single instance can be deleted but it will cause a dangling reference to that object.

=References=

[[#References|[1]]] Wikipedia. (2010, October) Wikipedia - Singleton_Pattern. [Online]. http://en.wikipedia.org/wiki/Singleton_pattern#Traditional_simple_way

[[#References|[2]]] Freeman, Eric, Elisabeth Freeman, Kathy Sierra, and Bert Bates. (October 2004) Head First design patterns. [Print.]

[[#References|[3]]] C# Corner (2010, October) Creational Patterns - Singleton. [Online]. http://www.c-sharpcorner.com/UploadFile/susanabraham/CreationalPatterns06042005050058AM/CreationalPatterns.aspx

[[#References|[4]]] Source Making (2010, October) Singleton Design Pattern. [Online]. http://sourcemaking.com/design_patterns/singleton

[[#References|[5]]] JavaBeginner.com (2010, October) Java Singleton Design Pattern. [Online]. http://www.javabeginner.com/learn-java/java-singleton-design-pattern

CSC/ECE 517 Fall 2010/ch3 3f lj

2010-10-14T02:07:37Z

Djfreema: /* References */

'''Singleton Pattern in Static and Dynamic languages'''

=Singleton pattern=
==Defintions==
In the Singleton design pattern we create a single instance of a Singleton class. Any instantiation of that Singleton class references the same instance of the class. The pattern also provides a global point of access for the functionality contained in the sole instance of the class. A design pattern is a way for a software developer to handle situations using a known solution that has been proven to be effective in the past. Design patterns also make communicating ideas and concepts between programmers more efficient and understandable.

===Class Diagram===
[[Image:IC73826.gif|500px|center]]
===Sequence Diagram===
[[Image:CR2.gif|500px|center]]

=Implementation=
When this pattern is implemented then it must only have one instantiation of a class and that class must satisfy the global access principles. The pattern requires a mechanism to access the singleton class without instantiating another class object and a mechanism to persist the value of class members among class objects. [[#References|[1]]]

==Creating the instance==
===Early Instantiation===
The instance can be created with a static constructor in static languages. (See the java example below) This means that the single instance is created on program start up and all new methods are private and never used except by the singleton class itself.

In static languages, this is accomplished by setting the constructors to private and controlling creation of instance of the object from within the object itself.

In dynamic languages, this is done by changing the access level of the constructor to prevent use outside the class just as in the static patterns.
===Late Instantiation===
The instance of the class can be created after class loading. This can be done by only allocating the instance on the first access of the instance variable.

==Accessing the instance==

In static languages, such as Java, the Singleton class will have a method which returns the instance of the Singleton class so that the other classes can use the functionality encapsulated in the Singleton class.

In dynamic languages, such as Ruby, if a class needs to access the functionality within the Singleton class then it simply needs to access the instance variable @instance and all the functionality therein.

=Examples=
==Java==

Java's API includes a Singleton class which implements the static version of the Singleton pattern. Java's implementation of the Singleton pattern only allows the programmer to create one instance of the Singleton class. The Singleton class automatically creates INSTANCE when it is initialized. The getInstance() method returns the single instance of the class that has been initialized. Java also utilizes a constructor to initialize the Singleton class.
<pre>
private static final Singleton INSTANCE = new Singleton();

// Private constructor prevents instantiation from other classes
private Singleton() {
}

public static Singleton getInstance() {
return INSTANCE;
}
</pre>

==Ruby==

Ruby implements the Singleton pattern by privatizing the "new" method and creates an instance variable called @instance. This implementation guarantees that the class will not be able create more than one instantiation of itself and that the system will have the global access privileges since the @instance variable has a global scope.

<pre>
class genericFactory
include Singleton
end
</pre>

==C++==
<pre>
// Declaration
class Singleton {
public:
static Singleton* Instance();
protected:
Singleton();
private:
static Singleton* _instance;
}

// Implementation
Singleton* Singleton::_instance = 0;

Singleton* Singleton::Instance() {
if (_instance == 0) {
_instance = new Singleton;
}
return _instance;
}
</pre>
[[#References|[1]]]

=Drawbacks=

*Unit tests are much harder to write when using the Singleton pattern

*This pattern reduces the potential for parallelism within a program since the threads must be serialized.

*The overhead of checking whether there is an instance of a class that already exists every time an objects requests a reference. Although the overhead is minuscule, this could be a serious problem for systems which don't have the resources to waste.

*There may be some development confusion with implementing the singleton class (especially one defined in a class library) because developers may forget that they cannot use the "new" keyword to instantiate the object.

*The singleton design pattern doesn't address the issue of deleting the single object. Some languages implement memory management which means that the Singleton class can only be unallocated by itself since it holds a private reference to the instance of itself. In languages that don't provide memory management, then the single instance can be deleted but it will cause a dangling reference to that object.

=References=

[[#References|[1]]] Wikipedia. (2010, October) Wikipedia - Singleton_Pattern. [Online]. http://en.wikipedia.org/wiki/Singleton_pattern#Traditional_simple_way

[[#References|[2]]] Freeman, Eric, Elisabeth Freeman, Kathy Sierra, and Bert Bates. (October 2004) Head First design patterns. [Print.]

[[#References|[3]]] C# Corner (2010, October) Creational Patterns - Singleton. [Online]. http://www.c-sharpcorner.com/UploadFile/susanabraham/CreationalPatterns06042005050058AM/CreationalPatterns.aspx

[[#References|[4]]] Source Making (2010, October) Singleton Design Pattern. http://sourcemaking.com/design_patterns/singleton

[[#References|[5]]] JavaBeginner.com (2010, October) Java Singleton Design Pattern http://www.javabeginner.com/learn-java/java-singleton-design-pattern

CSC/ECE 517 Fall 2010/ch3 3f lj

2010-10-14T02:06:26Z

Djfreema: /* References */

'''Singleton Pattern in Static and Dynamic languages'''

=Singleton pattern=
==Defintions==
In the Singleton design pattern we create a single instance of a Singleton class. Any instantiation of that Singleton class references the same instance of the class. The pattern also provides a global point of access for the functionality contained in the sole instance of the class. A design pattern is a way for a software developer to handle situations using a known solution that has been proven to be effective in the past. Design patterns also make communicating ideas and concepts between programmers more efficient and understandable.

===Class Diagram===
[[Image:IC73826.gif|500px|center]]
===Sequence Diagram===
[[Image:CR2.gif|500px|center]]

=Implementation=
When this pattern is implemented then it must only have one instantiation of a class and that class must satisfy the global access principles. The pattern requires a mechanism to access the singleton class without instantiating another class object and a mechanism to persist the value of class members among class objects. [[#References|[1]]]

==Creating the instance==
===Early Instantiation===
The instance can be created with a static constructor in static languages. (See the java example below) This means that the single instance is created on program start up and all new methods are private and never used except by the singleton class itself.

In static languages, this is accomplished by setting the constructors to private and controlling creation of instance of the object from within the object itself.

In dynamic languages, this is done by changing the access level of the constructor to prevent use outside the class just as in the static patterns.
===Late Instantiation===
The instance of the class can be created after class loading. This can be done by only allocating the instance on the first access of the instance variable.

==Accessing the instance==

In static languages, such as Java, the Singleton class will have a method which returns the instance of the Singleton class so that the other classes can use the functionality encapsulated in the Singleton class.

In dynamic languages, such as Ruby, if a class needs to access the functionality within the Singleton class then it simply needs to access the instance variable @instance and all the functionality therein.

=Examples=
==Java==

Java's API includes a Singleton class which implements the static version of the Singleton pattern. Java's implementation of the Singleton pattern only allows the programmer to create one instance of the Singleton class. The Singleton class automatically creates INSTANCE when it is initialized. The getInstance() method returns the single instance of the class that has been initialized. Java also utilizes a constructor to initialize the Singleton class.
<pre>
private static final Singleton INSTANCE = new Singleton();

// Private constructor prevents instantiation from other classes
private Singleton() {
}

public static Singleton getInstance() {
return INSTANCE;
}
</pre>

==Ruby==

Ruby implements the Singleton pattern by privatizing the "new" method and creates an instance variable called @instance. This implementation guarantees that the class will not be able create more than one instantiation of itself and that the system will have the global access privileges since the @instance variable has a global scope.

<pre>
class genericFactory
include Singleton
end
</pre>

==C++==
<pre>
// Declaration
class Singleton {
public:
static Singleton* Instance();
protected:
Singleton();
private:
static Singleton* _instance;
}

// Implementation
Singleton* Singleton::_instance = 0;

Singleton* Singleton::Instance() {
if (_instance == 0) {
_instance = new Singleton;
}
return _instance;
}
</pre>
[[#References|[1]]]

=Drawbacks=

*Unit tests are much harder to write when using the Singleton pattern

*This pattern reduces the potential for parallelism within a program since the threads must be serialized.

*The overhead of checking whether there is an instance of a class that already exists every time an objects requests a reference. Although the overhead is minuscule, this could be a serious problem for systems which don't have the resources to waste.

*There may be some development confusion with implementing the singleton class (especially one defined in a class library) because developers may forget that they cannot use the "new" keyword to instantiate the object.

*The singleton design pattern doesn't address the issue of deleting the single object. Some languages implement memory management which means that the Singleton class can only be unallocated by itself since it holds a private reference to the instance of itself. In languages that don't provide memory management, then the single instance can be deleted but it will cause a dangling reference to that object.

=References=

[[#References|[1]]] Wikipedia. (2010, October) Wikipedia - Singleton_Pattern. [Online]. http://en.wikipedia.org/wiki/Singleton_pattern#Traditional_simple_way

[[#References|[2]]] Freeman, Eric, Elisabeth Freeman, Kathy Sierra, and Bert Bates. (October 2004) Head First design patterns. [Print.]

[[#References|[3]]] C# Corner (2010, October) Creational Patterns - Singleton. [Online]. http://www.c-sharpcorner.com/UploadFile/susanabraham/CreationalPatterns06042005050058AM/CreationalPatterns.aspx

[[#References|[3]]] Source Making (2010, October) Singleton Design Pattern. http://sourcemaking.com/design_patterns/singleton

CSC/ECE 517 Fall 2010/ch3 3f lj

2010-10-14T02:04:23Z

Djfreema: /* References */

'''Singleton Pattern in Static and Dynamic languages'''

=Singleton pattern=
==Defintions==
In the Singleton design pattern we create a single instance of a Singleton class. Any instantiation of that Singleton class references the same instance of the class. The pattern also provides a global point of access for the functionality contained in the sole instance of the class. A design pattern is a way for a software developer to handle situations using a known solution that has been proven to be effective in the past. Design patterns also make communicating ideas and concepts between programmers more efficient and understandable.

===Class Diagram===
[[Image:IC73826.gif|500px|center]]
===Sequence Diagram===
[[Image:CR2.gif|500px|center]]

=Implementation=
When this pattern is implemented then it must only have one instantiation of a class and that class must satisfy the global access principles. The pattern requires a mechanism to access the singleton class without instantiating another class object and a mechanism to persist the value of class members among class objects. [[#References|[1]]]

==Creating the instance==
===Early Instantiation===
The instance can be created with a static constructor in static languages. (See the java example below) This means that the single instance is created on program start up and all new methods are private and never used except by the singleton class itself.

In static languages, this is accomplished by setting the constructors to private and controlling creation of instance of the object from within the object itself.

In dynamic languages, this is done by changing the access level of the constructor to prevent use outside the class just as in the static patterns.
===Late Instantiation===
The instance of the class can be created after class loading. This can be done by only allocating the instance on the first access of the instance variable.

==Accessing the instance==

In static languages, such as Java, the Singleton class will have a method which returns the instance of the Singleton class so that the other classes can use the functionality encapsulated in the Singleton class.

In dynamic languages, such as Ruby, if a class needs to access the functionality within the Singleton class then it simply needs to access the instance variable @instance and all the functionality therein.

=Examples=
==Java==

Java's API includes a Singleton class which implements the static version of the Singleton pattern. Java's implementation of the Singleton pattern only allows the programmer to create one instance of the Singleton class. The Singleton class automatically creates INSTANCE when it is initialized. The getInstance() method returns the single instance of the class that has been initialized. Java also utilizes a constructor to initialize the Singleton class.
<pre>
private static final Singleton INSTANCE = new Singleton();

// Private constructor prevents instantiation from other classes
private Singleton() {
}

public static Singleton getInstance() {
return INSTANCE;
}
</pre>

==Ruby==

Ruby implements the Singleton pattern by privatizing the "new" method and creates an instance variable called @instance. This implementation guarantees that the class will not be able create more than one instantiation of itself and that the system will have the global access privileges since the @instance variable has a global scope.

<pre>
class genericFactory
include Singleton
end
</pre>

==C++==
<pre>
// Declaration
class Singleton {
public:
static Singleton* Instance();
protected:
Singleton();
private:
static Singleton* _instance;
}

// Implementation
Singleton* Singleton::_instance = 0;

Singleton* Singleton::Instance() {
if (_instance == 0) {
_instance = new Singleton;
}
return _instance;
}
</pre>
[[#References|[1]]]

=Drawbacks=

*Unit tests are much harder to write when using the Singleton pattern

*This pattern reduces the potential for parallelism within a program since the threads must be serialized.

*The overhead of checking whether there is an instance of a class that already exists every time an objects requests a reference. Although the overhead is minuscule, this could be a serious problem for systems which don't have the resources to waste.

*There may be some development confusion with implementing the singleton class (especially one defined in a class library) because developers may forget that they cannot use the "new" keyword to instantiate the object.

*The singleton design pattern doesn't address the issue of deleting the single object. Some languages implement memory management which means that the Singleton class can only be unallocated by itself since it holds a private reference to the instance of itself. In languages that don't provide memory management, then the single instance can be deleted but it will cause a dangling reference to that object.

=References=

[[#References|[1]]] Wikipedia. (2010, October) Wikipedia - Singleton_Pattern. [Online]. http://en.wikipedia.org/wiki/Singleton_pattern#Traditional_simple_way

[[#References|[2]]] Freeman, Eric, Elisabeth Freeman, Kathy Sierra, and Bert Bates. (October 2004) Head First design patterns. [Print.]

[[#References|[3]]] C# Corner (2010, October) Creational Patterns - Singleton. [Online]. http://www.c-sharpcorner.com/UploadFile/susanabraham/CreationalPatterns06042005050058AM/CreationalPatterns.aspx

CSC/ECE 517 Fall 2010/ch3 3f lj

2010-10-14T02:03:12Z

Djfreema: /* References */

'''Singleton Pattern in Static and Dynamic languages'''

=Singleton pattern=
==Defintions==
In the Singleton design pattern we create a single instance of a Singleton class. Any instantiation of that Singleton class references the same instance of the class. The pattern also provides a global point of access for the functionality contained in the sole instance of the class. A design pattern is a way for a software developer to handle situations using a known solution that has been proven to be effective in the past. Design patterns also make communicating ideas and concepts between programmers more efficient and understandable.

===Class Diagram===
[[Image:IC73826.gif|500px|center]]
===Sequence Diagram===
[[Image:CR2.gif|500px|center]]

=Implementation=
When this pattern is implemented then it must only have one instantiation of a class and that class must satisfy the global access principles. The pattern requires a mechanism to access the singleton class without instantiating another class object and a mechanism to persist the value of class members among class objects. [[#References|[1]]]

==Creating the instance==
===Early Instantiation===
The instance can be created with a static constructor in static languages. (See the java example below) This means that the single instance is created on program start up and all new methods are private and never used except by the singleton class itself.

In static languages, this is accomplished by setting the constructors to private and controlling creation of instance of the object from within the object itself.

In dynamic languages, this is done by changing the access level of the constructor to prevent use outside the class just as in the static patterns.
===Late Instantiation===
The instance of the class can be created after class loading. This can be done by only allocating the instance on the first access of the instance variable.

==Accessing the instance==

In static languages, such as Java, the Singleton class will have a method which returns the instance of the Singleton class so that the other classes can use the functionality encapsulated in the Singleton class.

In dynamic languages, such as Ruby, if a class needs to access the functionality within the Singleton class then it simply needs to access the instance variable @instance and all the functionality therein.

=Examples=
==Java==

Java's API includes a Singleton class which implements the static version of the Singleton pattern. Java's implementation of the Singleton pattern only allows the programmer to create one instance of the Singleton class. The Singleton class automatically creates INSTANCE when it is initialized. The getInstance() method returns the single instance of the class that has been initialized. Java also utilizes a constructor to initialize the Singleton class.
<pre>
private static final Singleton INSTANCE = new Singleton();

// Private constructor prevents instantiation from other classes
private Singleton() {
}

public static Singleton getInstance() {
return INSTANCE;
}
</pre>

==Ruby==

Ruby implements the Singleton pattern by privatizing the "new" method and creates an instance variable called @instance. This implementation guarantees that the class will not be able create more than one instantiation of itself and that the system will have the global access privileges since the @instance variable has a global scope.

<pre>
class genericFactory
include Singleton
end
</pre>

==C++==
<pre>
// Declaration
class Singleton {
public:
static Singleton* Instance();
protected:
Singleton();
private:
static Singleton* _instance;
}

// Implementation
Singleton* Singleton::_instance = 0;

Singleton* Singleton::Instance() {
if (_instance == 0) {
_instance = new Singleton;
}
return _instance;
}
</pre>
[[#References|[1]]]

=Drawbacks=

*Unit tests are much harder to write when using the Singleton pattern

*This pattern reduces the potential for parallelism within a program since the threads must be serialized.

*The overhead of checking whether there is an instance of a class that already exists every time an objects requests a reference. Although the overhead is minuscule, this could be a serious problem for systems which don't have the resources to waste.

*There may be some development confusion with implementing the singleton class (especially one defined in a class library) because developers may forget that they cannot use the "new" keyword to instantiate the object.

*The singleton design pattern doesn't address the issue of deleting the single object. Some languages implement memory management which means that the Singleton class can only be unallocated by itself since it holds a private reference to the instance of itself. In languages that don't provide memory management, then the single instance can be deleted but it will cause a dangling reference to that object.

=References=

[[#References|[1]]] Wikipedia. (2010, October) Wikipedia - Singleton_Pattern. [Online]. http://en.wikipedia.org/wiki/Singleton_pattern#Traditional_simple_way

[[#References|[2]]] Freeman, Eric, Elisabeth Freeman, Kathy Sierra, and Bert Bates. (October 2004) Head First design patterns. [Print.]

[[#References|[3]]]http://www.c-sharpcorner.com/UploadFile/susanabraham/CreationalPatterns06042005050058AM/CreationalPatterns.aspx

CSC/ECE 517 Fall 2010/ch3 3f lj

2010-10-14T02:01:15Z

Djfreema: /* C++ */

'''Singleton Pattern in Static and Dynamic languages'''

=Singleton pattern=
==Defintions==
In the Singleton design pattern we create a single instance of a Singleton class. Any instantiation of that Singleton class references the same instance of the class. The pattern also provides a global point of access for the functionality contained in the sole instance of the class. A design pattern is a way for a software developer to handle situations using a known solution that has been proven to be effective in the past. Design patterns also make communicating ideas and concepts between programmers more efficient and understandable.

===Class Diagram===
[[Image:IC73826.gif|500px|center]]
===Sequence Diagram===
[[Image:CR2.gif|500px|center]]

=Implementation=
When this pattern is implemented then it must only have one instantiation of a class and that class must satisfy the global access principles. The pattern requires a mechanism to access the singleton class without instantiating another class object and a mechanism to persist the value of class members among class objects. [[#References|[1]]]

==Creating the instance==
===Early Instantiation===
The instance can be created with a static constructor in static languages. (See the java example below) This means that the single instance is created on program start up and all new methods are private and never used except by the singleton class itself.

In static languages, this is accomplished by setting the constructors to private and controlling creation of instance of the object from within the object itself.

In dynamic languages, this is done by changing the access level of the constructor to prevent use outside the class just as in the static patterns.
===Late Instantiation===
The instance of the class can be created after class loading. This can be done by only allocating the instance on the first access of the instance variable.

==Accessing the instance==

In static languages, such as Java, the Singleton class will have a method which returns the instance of the Singleton class so that the other classes can use the functionality encapsulated in the Singleton class.

In dynamic languages, such as Ruby, if a class needs to access the functionality within the Singleton class then it simply needs to access the instance variable @instance and all the functionality therein.

=Examples=
==Java==

Java's API includes a Singleton class which implements the static version of the Singleton pattern. Java's implementation of the Singleton pattern only allows the programmer to create one instance of the Singleton class. The Singleton class automatically creates INSTANCE when it is initialized. The getInstance() method returns the single instance of the class that has been initialized. Java also utilizes a constructor to initialize the Singleton class.
<pre>
private static final Singleton INSTANCE = new Singleton();

// Private constructor prevents instantiation from other classes
private Singleton() {
}

public static Singleton getInstance() {
return INSTANCE;
}
</pre>

==Ruby==

Ruby implements the Singleton pattern by privatizing the "new" method and creates an instance variable called @instance. This implementation guarantees that the class will not be able create more than one instantiation of itself and that the system will have the global access privileges since the @instance variable has a global scope.

<pre>
class genericFactory
include Singleton
end
</pre>

==C++==
<pre>
// Declaration
class Singleton {
public:
static Singleton* Instance();
protected:
Singleton();
private:
static Singleton* _instance;
}

// Implementation
Singleton* Singleton::_instance = 0;

Singleton* Singleton::Instance() {
if (_instance == 0) {
_instance = new Singleton;
}
return _instance;
}
</pre>
[[#References|[1]]]

=Drawbacks=

*Unit tests are much harder to write when using the Singleton pattern

*This pattern reduces the potential for parallelism within a program since the threads must be serialized.

*The overhead of checking whether there is an instance of a class that already exists every time an objects requests a reference. Although the overhead is minuscule, this could be a serious problem for systems which don't have the resources to waste.

*There may be some development confusion with implementing the singleton class (especially one defined in a class library) because developers may forget that they cannot use the "new" keyword to instantiate the object.

*The singleton design pattern doesn't address the issue of deleting the single object. Some languages implement memory management which means that the Singleton class can only be unallocated by itself since it holds a private reference to the instance of itself. In languages that don't provide memory management, then the single instance can be deleted but it will cause a dangling reference to that object.

=References=

[[#References|[1]]] Wikipedia. (2010, October) Wikipedia - Singleton_Pattern. [Online]. http://en.wikipedia.org/wiki/Singleton_pattern#Traditional_simple_way

[[#References|[2]]] Freeman, Eric, Elisabeth Freeman, Kathy Sierra, and Bert Bates. (October 2004) Head First design patterns. [Print.]

CSC/ECE 517 Fall 2010/ch3 3f lj

2010-10-14T02:00:50Z

Djfreema: /* C++ */

'''Singleton Pattern in Static and Dynamic languages'''

=Singleton pattern=
==Defintions==
In the Singleton design pattern we create a single instance of a Singleton class. Any instantiation of that Singleton class references the same instance of the class. The pattern also provides a global point of access for the functionality contained in the sole instance of the class. A design pattern is a way for a software developer to handle situations using a known solution that has been proven to be effective in the past. Design patterns also make communicating ideas and concepts between programmers more efficient and understandable.

===Class Diagram===
[[Image:IC73826.gif|500px|center]]
===Sequence Diagram===
[[Image:CR2.gif|500px|center]]

=Implementation=
When this pattern is implemented then it must only have one instantiation of a class and that class must satisfy the global access principles. The pattern requires a mechanism to access the singleton class without instantiating another class object and a mechanism to persist the value of class members among class objects. [[#References|[1]]]

==Creating the instance==
===Early Instantiation===
The instance can be created with a static constructor in static languages. (See the java example below) This means that the single instance is created on program start up and all new methods are private and never used except by the singleton class itself.

In static languages, this is accomplished by setting the constructors to private and controlling creation of instance of the object from within the object itself.

In dynamic languages, this is done by changing the access level of the constructor to prevent use outside the class just as in the static patterns.
===Late Instantiation===
The instance of the class can be created after class loading. This can be done by only allocating the instance on the first access of the instance variable.

==Accessing the instance==

In static languages, such as Java, the Singleton class will have a method which returns the instance of the Singleton class so that the other classes can use the functionality encapsulated in the Singleton class.

In dynamic languages, such as Ruby, if a class needs to access the functionality within the Singleton class then it simply needs to access the instance variable @instance and all the functionality therein.

=Examples=
==Java==

Java's API includes a Singleton class which implements the static version of the Singleton pattern. Java's implementation of the Singleton pattern only allows the programmer to create one instance of the Singleton class. The Singleton class automatically creates INSTANCE when it is initialized. The getInstance() method returns the single instance of the class that has been initialized. Java also utilizes a constructor to initialize the Singleton class.
<pre>
private static final Singleton INSTANCE = new Singleton();

// Private constructor prevents instantiation from other classes
private Singleton() {
}

public static Singleton getInstance() {
return INSTANCE;
}
</pre>

==Ruby==

Ruby implements the Singleton pattern by privatizing the "new" method and creates an instance variable called @instance. This implementation guarantees that the class will not be able create more than one instantiation of itself and that the system will have the global access privileges since the @instance variable has a global scope.

<pre>
class genericFactory
include Singleton
end
</pre>

==C++==
<pre>
// Declaration
class Singleton {
public:
static Singleton* Instance();
protected:
Singleton();
private:
static Singleton* _instance;
}

// Implementation
Singleton* Singleton::_instance = 0;

Singleton* Singleton::Instance() {
if (_instance == 0) {
_instance = new Singleton;
}
return _instance;
}
[[#References|[1]]]
</pre>

=Drawbacks=

*Unit tests are much harder to write when using the Singleton pattern

*This pattern reduces the potential for parallelism within a program since the threads must be serialized.

*The overhead of checking whether there is an instance of a class that already exists every time an objects requests a reference. Although the overhead is minuscule, this could be a serious problem for systems which don't have the resources to waste.

*There may be some development confusion with implementing the singleton class (especially one defined in a class library) because developers may forget that they cannot use the "new" keyword to instantiate the object.

*The singleton design pattern doesn't address the issue of deleting the single object. Some languages implement memory management which means that the Singleton class can only be unallocated by itself since it holds a private reference to the instance of itself. In languages that don't provide memory management, then the single instance can be deleted but it will cause a dangling reference to that object.

=References=

[[#References|[1]]] Wikipedia. (2010, October) Wikipedia - Singleton_Pattern. [Online]. http://en.wikipedia.org/wiki/Singleton_pattern#Traditional_simple_way

[[#References|[2]]] Freeman, Eric, Elisabeth Freeman, Kathy Sierra, and Bert Bates. (October 2004) Head First design patterns. [Print.]

CSC/ECE 517 Fall 2010/ch3 3f lj

2010-10-14T01:50:07Z

Djfreema: /* Late Instantiation */

'''Singleton Pattern in Static and Dynamic languages'''

=Singleton pattern=

In the Singleton design pattern we create a single instance of a Singleton class. Any instantiation of that Singleton class references the same instance of the class. The pattern also provides a global point of access for the functionality contained in the sole instance of the class.

===Class Diagram===
[[Image:IC73826.gif|500px|center]]
===Sequence Diagram===
[[Image:CR2.gif|500px|center]]

=Implementation=
When this pattern is implemented then it must only have one instantiation of a class and that class must satisfy the global access principles. The pattern requires a mechanism to access the singleton class without instantiating another class object and a mechanism to persist the value of class members among class objects. [[#References|[1]]]

==Creating the instance==
===Early Instantiation===
The instance can be created with a static constructor in static languages. (See the java example below) This means that the single instance is created on program start up and all new methods are private and never used except by the singleton class itself.

In static languages, this is accomplished by setting the constructors to private and controlling creation of instance of the object from within the object itself.

In dynamic languages, this is done by changing the access level of the constructor to prevent use outside the class just as in the static patterns.
===Late Instantiation===
The instance of the class can be created after class loading. This can be done by only allocating the instance on the first access of the instance variable.

==Accessing the instance==

In static languages, such as Java, the Singleton class will have a method which returns the instance of the Singleton class so that the other classes can use the functionality encapsulated in the Singleton class.

In dynamic languages, such as Ruby, if a class needs to access the functionality within the Singleton class then it simply needs to access the instance variable @instance and all the functionality therein.

=Examples=
==Java==

Java's API includes a Singleton class which implements the static version of the Singleton pattern. Java's implementation of the Singleton pattern only allows the programmer to create one instance of the Singleton class. The Singleton class automatically creates INSTANCE when it is initialized. The getInstance() method returns the single instance of the class that has been initialized. Java also utilizes a constructor to initialize the Singleton class.
<pre>
private static final Singleton INSTANCE = new Singleton();

// Private constructor prevents instantiation from other classes
private Singleton() {
}

public static Singleton getInstance() {
return INSTANCE;
}
</pre>

==Ruby==

Ruby implements the Singleton pattern by privatizing the "new" method and creates an instance variable called @instance. This implementation guarantees that the class will not be able create more than one instantiation of itself and that the system will have the global access privileges since the @instance variable has a global scope.

<pre>
class genericFactory
include Singleton
end
</pre>

==C++==
<pre>
// Declaration
class Singleton {
public:
static Singleton* Instance();
protected:
Singleton();
private:
static Singleton* _instance;
}

// Implementation
Singleton* Singleton::_instance = 0;

Singleton* Singleton::Instance() {
if (_instance == 0) {
_instance = new Singleton;
}
return _instance;
}
</pre>

=Drawbacks=

*Unit tests are much harder to write when using the Singleton pattern

*This pattern reduces the potential for parallelism within a program since the threads must be serialized.

*The overhead of checking whether there is an instance of a class that already exists every time an objects requests a reference. Although the overhead is minuscule, this could be a serious problem for systems which don't have the resources to waste.

*There may be some development confusion with implementing the singleton class (especially one defined in a class library) because developers may forget that they cannot use the "new" keyword to instantiate the object.

*The singleton design pattern doesn't address the issue of deleting the single object. Some languages implement memory management which means that the Singleton class can only be unallocated by itself since it holds a private reference to the instance of itself. In languages that don't provide memory management, then the single instance can be deleted but it will cause a dangling reference to that object.

=References=

[[#References|[1]]] Wikipedia. (2010, October) Wikipedia - Singleton_Pattern. [Online]. http://en.wikipedia.org/wiki/Singleton_pattern#Traditional_simple_way

[[#References|[2]]] Freeman, Eric, Elisabeth Freeman, Kathy Sierra, and Bert Bates. (October 2004) Head First design patterns. [Print.]

CSC/ECE 517 Fall 2010/ch3 3f lj

2010-10-14T01:48:38Z

Djfreema: /* Creating the instance */

'''Singleton Pattern in Static and Dynamic languages'''

=Singleton pattern=

In the Singleton design pattern we create a single instance of a Singleton class. Any instantiation of that Singleton class references the same instance of the class. The pattern also provides a global point of access for the functionality contained in the sole instance of the class.

===Class Diagram===
[[Image:IC73826.gif|500px|center]]
===Sequence Diagram===
[[Image:CR2.gif|500px|center]]

=Implementation=
When this pattern is implemented then it must only have one instantiation of a class and that class must satisfy the global access principles. The pattern requires a mechanism to access the singleton class without instantiating another class object and a mechanism to persist the value of class members among class objects. [[#References|[1]]]

==Creating the instance==
===Early Instantiation===
The instance can be created with a static constructor in static languages. (See the java example below) This means that the single instance is created on program start up and all new methods are private and never used except by the singleton class itself.

In static languages, this is accomplished by setting the constructors to private and controlling creation of instance of the object from within the object itself.

In dynamic languages, this is done by changing the access level of the constructor to prevent use outside the class just as in the static patterns.
===Late Instantiation===

==Accessing the instance==

In static languages, such as Java, the Singleton class will have a method which returns the instance of the Singleton class so that the other classes can use the functionality encapsulated in the Singleton class.

In dynamic languages, such as Ruby, if a class needs to access the functionality within the Singleton class then it simply needs to access the instance variable @instance and all the functionality therein.

=Examples=
==Java==

Java's API includes a Singleton class which implements the static version of the Singleton pattern. Java's implementation of the Singleton pattern only allows the programmer to create one instance of the Singleton class. The Singleton class automatically creates INSTANCE when it is initialized. The getInstance() method returns the single instance of the class that has been initialized. Java also utilizes a constructor to initialize the Singleton class.
<pre>
private static final Singleton INSTANCE = new Singleton();

// Private constructor prevents instantiation from other classes
private Singleton() {
}

public static Singleton getInstance() {
return INSTANCE;
}
</pre>

==Ruby==

Ruby implements the Singleton pattern by privatizing the "new" method and creates an instance variable called @instance. This implementation guarantees that the class will not be able create more than one instantiation of itself and that the system will have the global access privileges since the @instance variable has a global scope.

<pre>
class genericFactory
include Singleton
end
</pre>

==C++==
<pre>
// Declaration
class Singleton {
public:
static Singleton* Instance();
protected:
Singleton();
private:
static Singleton* _instance;
}

// Implementation
Singleton* Singleton::_instance = 0;

Singleton* Singleton::Instance() {
if (_instance == 0) {
_instance = new Singleton;
}
return _instance;
}
</pre>

=Drawbacks=

*Unit tests are much harder to write when using the Singleton pattern

*This pattern reduces the potential for parallelism within a program since the threads must be serialized.

*The overhead of checking whether there is an instance of a class that already exists every time an objects requests a reference. Although the overhead is minuscule, this could be a serious problem for systems which don't have the resources to waste.

*There may be some development confusion with implementing the singleton class (especially one defined in a class library) because developers may forget that they cannot use the "new" keyword to instantiate the object.

*The singleton design pattern doesn't address the issue of deleting the single object. Some languages implement memory management which means that the Singleton class can only be unallocated by itself since it holds a private reference to the instance of itself. In languages that don't provide memory management, then the single instance can be deleted but it will cause a dangling reference to that object.

=References=

[[#References|[1]]] Wikipedia. (2010, October) Wikipedia - Singleton_Pattern. [Online]. http://en.wikipedia.org/wiki/Singleton_pattern#Traditional_simple_way

[[#References|[2]]] Freeman, Eric, Elisabeth Freeman, Kathy Sierra, and Bert Bates. (October 2004) Head First design patterns. [Print.]

CSC/ECE 517 Fall 2010/ch3 3f lj

2010-10-14T01:41:16Z

Djfreema: /* Drawbacks */

'''Singleton Pattern in Static and Dynamic languages'''

=Singleton pattern=
A singleton pattern is a design pattern that restricts the amount of instantiations of a class to one object. This pattern is implemented when exactly one object is needed to coordinate actions across the entire system. The restriction of only having one object can sometimes make the system more efficient and allow the programmer to exercise more control over certain actions in the system. A singleton must satisfy some global access principles, which say all of the classes must be able to access the functionality contained in the singleton class/es.

===Class Diagram===
[[Image:IC73826.gif|500px|center]]
===Sequence Diagram===
[[Image:CR2.gif|500px|center]]

=Implementation=
When this pattern is implemented then it must only have one instantiation of a class and that class must satisfy the global access principles. The pattern requires a mechanism to access the singleton class without instantiating another class object and a mechanism to persist the value of class members among class objects. [[#References|[1]]]

==Creating the instance==
The instance can be created with a static constructor in static languages. (See the java example below) This means that the single instance is created on program start up and all new methods are private and never used except by the singleton class itself.

In static languages, this is accomplished by setting the constructors to private and controlling creation of instance of the object from within the object itself.

In dynamic languages, this is done by changing the access level of the constructor to prevent use outside the class just as in the static patterns.

==Accessing the instance==

In static languages, such as Java, the Singleton class will have a method which returns the instance of the Singleton class so that the other classes can use the functionality encapsulated in the Singleton class.

In dynamic languages, such as Ruby, if a class needs to access the functionality within the Singleton class then it simply needs to access the instance variable @instance and all the functionality therein.

=Examples=
==Java==

Java's API includes a Singleton class which implements the static version of the Singleton pattern. Java's implementation of the Singleton pattern only allows the programmer to create one instance of the Singleton class. The Singleton class automatically creates INSTANCE when it is initialized. The getInstance() method returns the single instance of the class that has been initialized. Java also utilizes a constructor to initialize the Singleton class.
<pre>
private static final Singleton INSTANCE = new Singleton();

// Private constructor prevents instantiation from other classes
private Singleton() {
}

public static Singleton getInstance() {
return INSTANCE;
}
</pre>

==Ruby==

Ruby implements the Singleton pattern by privatizing the "new" method and creates an instance variable called @instance. This implementation guarantees that the class will not be able create more than one instantiation of itself and that the system will have the global access privileges since the @instance variable has a global scope.

<pre>
class genericFactory
include Singleton
end
</pre>

==C++==
<pre>
// Declaration
class Singleton {
public:
static Singleton* Instance();
protected:
Singleton();
private:
static Singleton* _instance;
}

// Implementation
Singleton* Singleton::_instance = 0;

Singleton* Singleton::Instance() {
if (_instance == 0) {
_instance = new Singleton;
}
return _instance;
}
</pre>

=Drawbacks=

*Unit tests are much harder to write when using the Singleton pattern

*This pattern reduces the potential for parallelism within a program since the threads must be serialized.

*The overhead of checking whether there is an instance of a class that already exists every time an objects requests a reference. Although the overhead is minuscule, this could be a serious problem for systems which don't have the resources to waste.

*There may be some development confusion with implementing the singleton class (especially one defined in a class library) because developers may forget that they cannot use the "new" keyword to instantiate the object.

*The singleton design pattern doesn't address the issue of deleting the single object. Some languages implement memory management which means that the Singleton class can only be unallocated by itself since it holds a private reference to the instance of itself. In languages that don't provide memory management, then the single instance can be deleted but it will cause a dangling reference to that object.

=References=

[[#References|[1]]] Wikipedia. (2010, October) Wikipedia - Singleton_Pattern. [Online]. http://en.wikipedia.org/wiki/Singleton_pattern#Traditional_simple_way

[[#References|[2]]] Freeman, Eric, Elisabeth Freeman, Kathy Sierra, and Bert Bates. (October 2004) Head First design patterns. [Print.]

CSC/ECE 517 Fall 2010/ch3 3f lj

2010-10-14T01:39:43Z

Djfreema: /* Ruby */

'''Singleton Pattern in Static and Dynamic languages'''

=Singleton pattern=
A singleton pattern is a design pattern that restricts the amount of instantiations of a class to one object. This pattern is implemented when exactly one object is needed to coordinate actions across the entire system. The restriction of only having one object can sometimes make the system more efficient and allow the programmer to exercise more control over certain actions in the system. A singleton must satisfy some global access principles, which say all of the classes must be able to access the functionality contained in the singleton class/es.

===Class Diagram===
[[Image:IC73826.gif|500px|center]]
===Sequence Diagram===
[[Image:CR2.gif|500px|center]]

=Implementation=
When this pattern is implemented then it must only have one instantiation of a class and that class must satisfy the global access principles. The pattern requires a mechanism to access the singleton class without instantiating another class object and a mechanism to persist the value of class members among class objects. [[#References|[1]]]

==Creating the instance==
The instance can be created with a static constructor in static languages. (See the java example below) This means that the single instance is created on program start up and all new methods are private and never used except by the singleton class itself.

In static languages, this is accomplished by setting the constructors to private and controlling creation of instance of the object from within the object itself.

In dynamic languages, this is done by changing the access level of the constructor to prevent use outside the class just as in the static patterns.

==Accessing the instance==

In static languages, such as Java, the Singleton class will have a method which returns the instance of the Singleton class so that the other classes can use the functionality encapsulated in the Singleton class.

In dynamic languages, such as Ruby, if a class needs to access the functionality within the Singleton class then it simply needs to access the instance variable @instance and all the functionality therein.

=Examples=
==Java==

Java's API includes a Singleton class which implements the static version of the Singleton pattern. Java's implementation of the Singleton pattern only allows the programmer to create one instance of the Singleton class. The Singleton class automatically creates INSTANCE when it is initialized. The getInstance() method returns the single instance of the class that has been initialized. Java also utilizes a constructor to initialize the Singleton class.
<pre>
private static final Singleton INSTANCE = new Singleton();

// Private constructor prevents instantiation from other classes
private Singleton() {
}

public static Singleton getInstance() {
return INSTANCE;
}
</pre>

==Ruby==

Ruby implements the Singleton pattern by privatizing the "new" method and creates an instance variable called @instance. This implementation guarantees that the class will not be able create more than one instantiation of itself and that the system will have the global access privileges since the @instance variable has a global scope.

<pre>
class genericFactory
include Singleton
end
</pre>

==C++==
<pre>
// Declaration
class Singleton {
public:
static Singleton* Instance();
protected:
Singleton();
private:
static Singleton* _instance;
}

// Implementation
Singleton* Singleton::_instance = 0;

Singleton* Singleton::Instance() {
if (_instance == 0) {
_instance = new Singleton;
}
return _instance;
}
</pre>

=Drawbacks=

1) Unit tests are much harder to write when using the Singleton pattern

2) This pattern reduces the potential for parallelism within a program since the threads must be serialized.

3) The overhead of checking whether there is an instance of a class that already exists every time an objects requests a reference. Although the overhead is minuscule, this could be a serious problem for systems which don't have the resources to waste.

4) There may be some development confusion with implementing the singleton class (especially one defined in a class library) because developers may forget that they cannot use the "new" keyword to instantiate the object.

5) The singleton design pattern doesn't address the issue of deleting the single object. Some languages implement memory management which means that the Singleton class can only be unallocated by itself since it holds a private reference to the instance of itself. In languages that don't provide memory management, then the single instance can be deleted but it will cause a dangling reference to that object.

=References=

[[#References|[1]]] Wikipedia. (2010, October) Wikipedia - Singleton_Pattern. [Online]. http://en.wikipedia.org/wiki/Singleton_pattern#Traditional_simple_way

[[#References|[2]]] Freeman, Eric, Elisabeth Freeman, Kathy Sierra, and Bert Bates. (October 2004) Head First design patterns. [Print.]

CSC/ECE 517 Fall 2010/ch3 3f lj

2010-10-14T01:39:29Z

Djfreema: /* Ruby */

'''Singleton Pattern in Static and Dynamic languages'''

=Singleton pattern=
A singleton pattern is a design pattern that restricts the amount of instantiations of a class to one object. This pattern is implemented when exactly one object is needed to coordinate actions across the entire system. The restriction of only having one object can sometimes make the system more efficient and allow the programmer to exercise more control over certain actions in the system. A singleton must satisfy some global access principles, which say all of the classes must be able to access the functionality contained in the singleton class/es.

===Class Diagram===
[[Image:IC73826.gif|500px|center]]
===Sequence Diagram===
[[Image:CR2.gif|500px|center]]

=Implementation=
When this pattern is implemented then it must only have one instantiation of a class and that class must satisfy the global access principles. The pattern requires a mechanism to access the singleton class without instantiating another class object and a mechanism to persist the value of class members among class objects. [[#References|[1]]]

==Creating the instance==
The instance can be created with a static constructor in static languages. (See the java example below) This means that the single instance is created on program start up and all new methods are private and never used except by the singleton class itself.

In static languages, this is accomplished by setting the constructors to private and controlling creation of instance of the object from within the object itself.

In dynamic languages, this is done by changing the access level of the constructor to prevent use outside the class just as in the static patterns.

==Accessing the instance==

In static languages, such as Java, the Singleton class will have a method which returns the instance of the Singleton class so that the other classes can use the functionality encapsulated in the Singleton class.

In dynamic languages, such as Ruby, if a class needs to access the functionality within the Singleton class then it simply needs to access the instance variable @instance and all the functionality therein.

=Examples=
==Java==

Java's API includes a Singleton class which implements the static version of the Singleton pattern. Java's implementation of the Singleton pattern only allows the programmer to create one instance of the Singleton class. The Singleton class automatically creates INSTANCE when it is initialized. The getInstance() method returns the single instance of the class that has been initialized. Java also utilizes a constructor to initialize the Singleton class.
<pre>
private static final Singleton INSTANCE = new Singleton();

// Private constructor prevents instantiation from other classes
private Singleton() {
}

public static Singleton getInstance() {
return INSTANCE;
}
</pre>

==Ruby==

Ruby implements the Singleton pattern by privatizing the "new" method and creates an instance variable called @instance. This implementation guarantees that the class will not be able create more than one instantiation of itself and that the system will have the global access privileges since the @instance variable has a global scope.

class genericFactory
include Singleton
end

==C++==
<pre>
// Declaration
class Singleton {
public:
static Singleton* Instance();
protected:
Singleton();
private:
static Singleton* _instance;
}

// Implementation
Singleton* Singleton::_instance = 0;

Singleton* Singleton::Instance() {
if (_instance == 0) {
_instance = new Singleton;
}
return _instance;
}
</pre>

=Drawbacks=

1) Unit tests are much harder to write when using the Singleton pattern

2) This pattern reduces the potential for parallelism within a program since the threads must be serialized.

3) The overhead of checking whether there is an instance of a class that already exists every time an objects requests a reference. Although the overhead is minuscule, this could be a serious problem for systems which don't have the resources to waste.

4) There may be some development confusion with implementing the singleton class (especially one defined in a class library) because developers may forget that they cannot use the "new" keyword to instantiate the object.

5) The singleton design pattern doesn't address the issue of deleting the single object. Some languages implement memory management which means that the Singleton class can only be unallocated by itself since it holds a private reference to the instance of itself. In languages that don't provide memory management, then the single instance can be deleted but it will cause a dangling reference to that object.

=References=

[[#References|[1]]] Wikipedia. (2010, October) Wikipedia - Singleton_Pattern. [Online]. http://en.wikipedia.org/wiki/Singleton_pattern#Traditional_simple_way

[[#References|[2]]] Freeman, Eric, Elisabeth Freeman, Kathy Sierra, and Bert Bates. (October 2004) Head First design patterns. [Print.]

CSC/ECE 517 Fall 2010/ch3 3f lj

2010-10-14T01:38:14Z

Djfreema: /* C++ */

'''Singleton Pattern in Static and Dynamic languages'''

=Singleton pattern=
A singleton pattern is a design pattern that restricts the amount of instantiations of a class to one object. This pattern is implemented when exactly one object is needed to coordinate actions across the entire system. The restriction of only having one object can sometimes make the system more efficient and allow the programmer to exercise more control over certain actions in the system. A singleton must satisfy some global access principles, which say all of the classes must be able to access the functionality contained in the singleton class/es.

===Class Diagram===
[[Image:IC73826.gif|500px|center]]
===Sequence Diagram===
[[Image:CR2.gif|500px|center]]

=Implementation=
When this pattern is implemented then it must only have one instantiation of a class and that class must satisfy the global access principles. The pattern requires a mechanism to access the singleton class without instantiating another class object and a mechanism to persist the value of class members among class objects. [[#References|[1]]]

==Creating the instance==
The instance can be created with a static constructor in static languages. (See the java example below) This means that the single instance is created on program start up and all new methods are private and never used except by the singleton class itself.

In static languages, this is accomplished by setting the constructors to private and controlling creation of instance of the object from within the object itself.

In dynamic languages, this is done by changing the access level of the constructor to prevent use outside the class just as in the static patterns.

==Accessing the instance==

In static languages, such as Java, the Singleton class will have a method which returns the instance of the Singleton class so that the other classes can use the functionality encapsulated in the Singleton class.

In dynamic languages, such as Ruby, if a class needs to access the functionality within the Singleton class then it simply needs to access the instance variable @instance and all the functionality therein.

=Examples=
==Java==

Java's API includes a Singleton class which implements the static version of the Singleton pattern. Java's implementation of the Singleton pattern only allows the programmer to create one instance of the Singleton class. The Singleton class automatically creates INSTANCE when it is initialized. The getInstance() method returns the single instance of the class that has been initialized. Java also utilizes a constructor to initialize the Singleton class.
<pre>
private static final Singleton INSTANCE = new Singleton();

// Private constructor prevents instantiation from other classes
private Singleton() {
}

public static Singleton getInstance() {
return INSTANCE;
}
</pre>

==Ruby==

Ruby implements the Singleton pattern by privatizing the "new" method and creates an instance variable called @instance. This implementation guarantees that the class will not be able create more than one instantiation of itself and that the system will have the global access privileges since the @instance variable has a global scope.

include Singleton

==C++==
<pre>
// Declaration
class Singleton {
public:
static Singleton* Instance();
protected:
Singleton();
private:
static Singleton* _instance;
}

// Implementation
Singleton* Singleton::_instance = 0;

Singleton* Singleton::Instance() {
if (_instance == 0) {
_instance = new Singleton;
}
return _instance;
}
</pre>

=Drawbacks=

1) Unit tests are much harder to write when using the Singleton pattern

2) This pattern reduces the potential for parallelism within a program since the threads must be serialized.

3) The overhead of checking whether there is an instance of a class that already exists every time an objects requests a reference. Although the overhead is minuscule, this could be a serious problem for systems which don't have the resources to waste.

4) There may be some development confusion with implementing the singleton class (especially one defined in a class library) because developers may forget that they cannot use the "new" keyword to instantiate the object.

5) The singleton design pattern doesn't address the issue of deleting the single object. Some languages implement memory management which means that the Singleton class can only be unallocated by itself since it holds a private reference to the instance of itself. In languages that don't provide memory management, then the single instance can be deleted but it will cause a dangling reference to that object.

=References=

[[#References|[1]]] Wikipedia. (2010, October) Wikipedia - Singleton_Pattern. [Online]. http://en.wikipedia.org/wiki/Singleton_pattern#Traditional_simple_way

[[#References|[2]]] Freeman, Eric, Elisabeth Freeman, Kathy Sierra, and Bert Bates. (October 2004) Head First design patterns. [Print.]

CSC/ECE 517 Fall 2010/ch3 3f lj

2010-10-14T01:37:58Z

Djfreema: /* Java */

'''Singleton Pattern in Static and Dynamic languages'''

=Singleton pattern=
A singleton pattern is a design pattern that restricts the amount of instantiations of a class to one object. This pattern is implemented when exactly one object is needed to coordinate actions across the entire system. The restriction of only having one object can sometimes make the system more efficient and allow the programmer to exercise more control over certain actions in the system. A singleton must satisfy some global access principles, which say all of the classes must be able to access the functionality contained in the singleton class/es.

===Class Diagram===
[[Image:IC73826.gif|500px|center]]
===Sequence Diagram===
[[Image:CR2.gif|500px|center]]

=Implementation=
When this pattern is implemented then it must only have one instantiation of a class and that class must satisfy the global access principles. The pattern requires a mechanism to access the singleton class without instantiating another class object and a mechanism to persist the value of class members among class objects. [[#References|[1]]]

==Creating the instance==
The instance can be created with a static constructor in static languages. (See the java example below) This means that the single instance is created on program start up and all new methods are private and never used except by the singleton class itself.

In static languages, this is accomplished by setting the constructors to private and controlling creation of instance of the object from within the object itself.

In dynamic languages, this is done by changing the access level of the constructor to prevent use outside the class just as in the static patterns.

==Accessing the instance==

In static languages, such as Java, the Singleton class will have a method which returns the instance of the Singleton class so that the other classes can use the functionality encapsulated in the Singleton class.

In dynamic languages, such as Ruby, if a class needs to access the functionality within the Singleton class then it simply needs to access the instance variable @instance and all the functionality therein.

=Examples=
==Java==

Java's API includes a Singleton class which implements the static version of the Singleton pattern. Java's implementation of the Singleton pattern only allows the programmer to create one instance of the Singleton class. The Singleton class automatically creates INSTANCE when it is initialized. The getInstance() method returns the single instance of the class that has been initialized. Java also utilizes a constructor to initialize the Singleton class.
<pre>
private static final Singleton INSTANCE = new Singleton();

// Private constructor prevents instantiation from other classes
private Singleton() {
}

public static Singleton getInstance() {
return INSTANCE;
}
</pre>

==Ruby==

Ruby implements the Singleton pattern by privatizing the "new" method and creates an instance variable called @instance. This implementation guarantees that the class will not be able create more than one instantiation of itself and that the system will have the global access privileges since the @instance variable has a global scope.

include Singleton

==C++==

// Declaration
class Singleton {
public:
static Singleton* Instance();
protected:
Singleton();
private:
static Singleton* _instance;
}

// Implementation
Singleton* Singleton::_instance = 0;

Singleton* Singleton::Instance() {
if (_instance == 0) {
_instance = new Singleton;
}
return _instance;
}

=Drawbacks=

1) Unit tests are much harder to write when using the Singleton pattern

2) This pattern reduces the potential for parallelism within a program since the threads must be serialized.

3) The overhead of checking whether there is an instance of a class that already exists every time an objects requests a reference. Although the overhead is minuscule, this could be a serious problem for systems which don't have the resources to waste.

4) There may be some development confusion with implementing the singleton class (especially one defined in a class library) because developers may forget that they cannot use the "new" keyword to instantiate the object.

5) The singleton design pattern doesn't address the issue of deleting the single object. Some languages implement memory management which means that the Singleton class can only be unallocated by itself since it holds a private reference to the instance of itself. In languages that don't provide memory management, then the single instance can be deleted but it will cause a dangling reference to that object.

=References=

[[#References|[1]]] Wikipedia. (2010, October) Wikipedia - Singleton_Pattern. [Online]. http://en.wikipedia.org/wiki/Singleton_pattern#Traditional_simple_way

[[#References|[2]]] Freeman, Eric, Elisabeth Freeman, Kathy Sierra, and Bert Bates. (October 2004) Head First design patterns. [Print.]