<?xml version="1.0"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
	<id>https://wiki.expertiza.ncsu.edu/api.php?action=feedcontributions&amp;feedformat=atom&amp;user=Mlsurrat</id>
	<title>Expertiza_Wiki - User contributions [en]</title>
	<link rel="self" type="application/atom+xml" href="https://wiki.expertiza.ncsu.edu/api.php?action=feedcontributions&amp;feedformat=atom&amp;user=Mlsurrat"/>
	<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=Special:Contributions/Mlsurrat"/>
	<updated>2026-07-14T06:35:39Z</updated>
	<subtitle>User contributions</subtitle>
	<generator>MediaWiki 1.41.0</generator>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2010/ch7_7g_ms&amp;diff=43050</id>
		<title>CSC/ECE 517 Fall 2010/ch7 7g ms</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2010/ch7_7g_ms&amp;diff=43050"/>
		<updated>2010-12-01T20:57:58Z</updated>

		<summary type="html">&lt;p&gt;Mlsurrat: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;'''Analysis Paralysis Anti-Pattern'''&lt;br /&gt;
&lt;br /&gt;
=Analysis Paralysis Anti-pattern=&lt;br /&gt;
&lt;br /&gt;
In software engineering, an anti-pattern (or antipattern) is a pattern that may be commonly used but is ineffective and/or counterproductive in practice[[1]].&lt;br /&gt;
&lt;br /&gt;
Analysis paralysis is one of the classic anti-patterns in object oriented software development. In analysis paralysis, we over analyze (or over think) a situation until no decision is ever made, which effectively paralyzes the current process' outcome.&lt;br /&gt;
&lt;br /&gt;
=History=&lt;br /&gt;
In Aesop's Fables' &amp;quot;The Fox and the Cat&amp;quot;, the fox has &amp;quot;hundreds of ways of escaping&amp;quot; while the cat has &amp;quot;only one&amp;quot;. When they heard the hounds approaching, the cat scampered up a tree while &amp;quot;the Fox in his confusion was caught up by the hounds&amp;quot;. The fable ends with the moral, &amp;quot;Better one safe way than a hundred on which you cannot reckon.&amp;quot;&lt;br /&gt;
&lt;br /&gt;
In The Tragedy of Hamlet, Prince of Denmark, the main character, Prince Hamlet, is often said to have a mortal flaw of thinking too much, such that his youth and vital energy are, in Shakespeare's words, &amp;quot;sicklied o'er with the pale cast of thought.&amp;quot;&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=How to Defeat Analysis Paralysis=&lt;br /&gt;
    *Keep models small. Never integrate them. Building a bigger model doesn't add knowledge - it destroys knowledge&lt;br /&gt;
    *Employ a professional architect&lt;br /&gt;
    *Start your project with one requirement and an architectural prototype&lt;br /&gt;
&lt;br /&gt;
==The PDCA Model==&lt;br /&gt;
    *Plan&lt;br /&gt;
    *Do&lt;br /&gt;
    *Check&lt;br /&gt;
    *Act&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=Causes=&lt;br /&gt;
In software development, analysis paralysis typically manifests itself through exceedingly long phases of project planning, requirements gathering, program design and data modeling, with little or no extra value created by those steps. When extended over too long a timeframe, such processes tend to emphasize the organizational (i.e., bureaucratic) aspect of the software project, while detracting from its functional (value-creating) portion.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
*Pride &lt;br /&gt;
*Narrow Mindedness&lt;br /&gt;
*The lure of infinite composability and decomposability&lt;br /&gt;
*Insistence on completing all analysis before beginning design.&lt;br /&gt;
*Regular change of leads and their philosophies (each trashing and restarting the work of the previous)&lt;br /&gt;
*Too many learning curves at once (underqualified analyst) causing incessant revisiting of prior work&lt;br /&gt;
*Lack of goals&lt;br /&gt;
*Increasingly conflicting goals (often political)&lt;br /&gt;
*Creative speculation, when discovery and definition are required.&lt;br /&gt;
*BigProjectSyndrome: this one will do it all, will use the latest tools, will use a new paradigm, will use all new developers, will start with a clean slate, will handle all use cases of two or more existing systems in the first release, etc.&lt;br /&gt;
*Risk avoidance, fear of making a mistake. &lt;br /&gt;
&lt;br /&gt;
=References=&lt;br /&gt;
[[#References|[1]]] Wikipedia. (2010, November) Wikipedia - Anti-Pattern. [Online]. http://en.wikipedia.org/wiki/Anti-pattern&lt;br /&gt;
&lt;br /&gt;
[[#References|[2]]] Analysis Paralysis. (2010, November) Analysis Paralysis. [Online]. http://c2.com/cgi/wiki?AnalysisParalysis&lt;br /&gt;
&lt;br /&gt;
[[#References|[3]]] Analysis Paralysis. (2010, November) Programming Management Anti-Patterns. [Online]. http://sourcemaking.com/antipatterns/analysis-paralysis&lt;br /&gt;
&lt;br /&gt;
[[#References|[4]]] Marelisa. (2010, November) How to Defeat Analysis Paralysis – The PDCA Model. [Online]. http://abundance-blog.marelisa-online.com/2010/06/26/defeat-analysis-paralysis/&lt;/div&gt;</summary>
		<author><name>Mlsurrat</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2010/ch7_7g_ms&amp;diff=43049</id>
		<title>CSC/ECE 517 Fall 2010/ch7 7g ms</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2010/ch7_7g_ms&amp;diff=43049"/>
		<updated>2010-12-01T20:57:36Z</updated>

		<summary type="html">&lt;p&gt;Mlsurrat: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;'''Analysis Paralysis Anti-Pattern'''&lt;br /&gt;
&lt;br /&gt;
=Analysis Paralysis Anti-pattern=&lt;br /&gt;
&lt;br /&gt;
In software engineering, an anti-pattern (or antipattern) is a pattern that may be commonly used but is ineffective and/or counterproductive in practice[[1]].&lt;br /&gt;
&lt;br /&gt;
Analysis paralysis is one of the classic anti-patterns in object oriented software development. In analysis paralysis, we over analyze (or over think) a situation until no decision is ever made, which effectively paralyzes the current process' outcome.&lt;br /&gt;
&lt;br /&gt;
=History=&lt;br /&gt;
In Aesop's Fables' &amp;quot;The Fox and the Cat&amp;quot;, the fox has &amp;quot;hundreds of ways of escaping&amp;quot; while the cat has &amp;quot;only one&amp;quot;. When they heard the hounds approaching, the cat scampered up a tree while &amp;quot;the Fox in his confusion was caught up by the hounds&amp;quot;. The fable ends with the moral, &amp;quot;Better one safe way than a hundred on which you cannot reckon.&amp;quot;&lt;br /&gt;
&lt;br /&gt;
In The Tragedy of Hamlet, Prince of Denmark, the main character, Prince Hamlet, is often said to have a mortal flaw of thinking too much, such that his youth and vital energy are, in Shakespeare's words, &amp;quot;sicklied o'er with the pale cast of thought.&amp;quot;&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=How to Defeat Analysis Paralysis=&lt;br /&gt;
    *Keep models small. Never integrate them. Building a bigger model doesn't add knowledge - it destroys knowledge&lt;br /&gt;
    *Employ a professional architect&lt;br /&gt;
    *Start your project with one requirement and an architectural prototype&lt;br /&gt;
&lt;br /&gt;
==The PDCA Model==&lt;br /&gt;
    *Plan&lt;br /&gt;
    *Do&lt;br /&gt;
    *Check&lt;br /&gt;
    *Act&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=Causes=&lt;br /&gt;
In software development, analysis paralysis typically manifests itself through exceedingly long phases of project planning, requirements gathering, program design and data modeling, with little or no extra value created by those steps. When extended over too long a timeframe, such processes tend to emphasize the organizational (i.e., bureaucratic) aspect of the software project, while detracting from its functional (value-creating) portion.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
*Pride &lt;br /&gt;
*Narrow Mindedness&lt;br /&gt;
*The lure of infinite composability and decomposability&lt;br /&gt;
*Insistence on completing all analysis before beginning design.&lt;br /&gt;
*Regular change of leads and their philosophies (each trashing and restarting the work of the previous)&lt;br /&gt;
*Too many learning curves at once (underqualified analyst) causing incessant revisiting of prior work&lt;br /&gt;
*Lack of goals&lt;br /&gt;
*Increasingly conflicting goals (often political)&lt;br /&gt;
*Creative speculation, when discovery and definition are required.&lt;br /&gt;
*BigProjectSyndrome: this one will do it all, will use the latest tools, will use a new paradigm, will use all new developers, will start with a clean slate, will handle all use cases of two or more existing systems in the first release, etc.&lt;br /&gt;
*Risk avoidance, fear of making a mistake. &lt;br /&gt;
&lt;br /&gt;
=References=&lt;br /&gt;
[[#References|[1]]] Wikipedia. (2010, November) Wikipedia - Anti-Pattern. [Online]. http://en.wikipedia.org/wiki/Anti-pattern]&lt;br /&gt;
[[#References|[2]]] Analysis Paralysis. (2010, November) Analysis Paralysis. [Online]. http://c2.com/cgi/wiki?AnalysisParalysis]&lt;br /&gt;
[[#References|[3]]] Analysis Paralysis. (2010, November) Programming Management Anti-Patterns. [Online]. http://sourcemaking.com/antipatterns/analysis-paralysis]&lt;br /&gt;
[[#References|[4]]] Marelisa. (2010, November) How to Defeat Analysis Paralysis – The PDCA Model. [Online]. http://abundance-blog.marelisa-online.com/2010/06/26/defeat-analysis-paralysis/]&lt;/div&gt;</summary>
		<author><name>Mlsurrat</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2010/ch7_7g_ms&amp;diff=43048</id>
		<title>CSC/ECE 517 Fall 2010/ch7 7g ms</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2010/ch7_7g_ms&amp;diff=43048"/>
		<updated>2010-12-01T20:57:10Z</updated>

		<summary type="html">&lt;p&gt;Mlsurrat: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;'''Analysis Paralysis Anti-Pattern'''&lt;br /&gt;
&lt;br /&gt;
=Analysis Paralysis Anti-pattern=&lt;br /&gt;
&lt;br /&gt;
In software engineering, an anti-pattern (or antipattern) is a pattern that may be commonly used but is ineffective and/or counterproductive in practice[[1]].&lt;br /&gt;
&lt;br /&gt;
Analysis paralysis is one of the classic anti-patterns in object oriented software development. In analysis paralysis, we over analyze (or over think) a situation until no decision is ever made, which effectively paralyzes the current process' outcome.&lt;br /&gt;
&lt;br /&gt;
=History=&lt;br /&gt;
In Aesop's Fables' &amp;quot;The Fox and the Cat&amp;quot;, the fox has &amp;quot;hundreds of ways of escaping&amp;quot; while the cat has &amp;quot;only one&amp;quot;. When they heard the hounds approaching, the cat scampered up a tree while &amp;quot;the Fox in his confusion was caught up by the hounds&amp;quot;. The fable ends with the moral, &amp;quot;Better one safe way than a hundred on which you cannot reckon.&amp;quot;&lt;br /&gt;
&lt;br /&gt;
In The Tragedy of Hamlet, Prince of Denmark, the main character, Prince Hamlet, is often said to have a mortal flaw of thinking too much, such that his youth and vital energy are, in Shakespeare's words, &amp;quot;sicklied o'er with the pale cast of thought.&amp;quot;&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=How to Defeat Analysis Paralysis=&lt;br /&gt;
    *Keep models small. Never integrate them. Building a bigger model doesn't add knowledge - it destroys knowledge&lt;br /&gt;
    *Employ a professional architect&lt;br /&gt;
    *Start your project with one requirement and an architectural prototype&lt;br /&gt;
&lt;br /&gt;
==The PDCA Model==&lt;br /&gt;
    *Plan&lt;br /&gt;
    *Do&lt;br /&gt;
    *Check&lt;br /&gt;
    *Act&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=Causes=&lt;br /&gt;
In software development, analysis paralysis typically manifests itself through exceedingly long phases of project planning, requirements gathering, program design and data modeling, with little or no extra value created by those steps. When extended over too long a timeframe, such processes tend to emphasize the organizational (i.e., bureaucratic) aspect of the software project, while detracting from its functional (value-creating) portion.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
*Pride &lt;br /&gt;
*Narrow Mindedness&lt;br /&gt;
*The lure of infinite composability and decomposability&lt;br /&gt;
*Insistence on completing all analysis before beginning design.&lt;br /&gt;
*Regular change of leads and their philosophies (each trashing and restarting the work of the previous)&lt;br /&gt;
*Too many learning curves at once (underqualified analyst) causing incessant revisiting of prior work&lt;br /&gt;
*Lack of goals&lt;br /&gt;
*Increasingly conflicting goals (often political)&lt;br /&gt;
*Creative speculation, when discovery and definition are required.&lt;br /&gt;
*BigProjectSyndrome: this one will do it all, will use the latest tools, will use a new paradigm, will use all new developers, will start with a clean slate, will handle all use cases of two or more existing systems in the first release, etc.&lt;br /&gt;
*Risk avoidance, fear of making a mistake. &lt;br /&gt;
&lt;br /&gt;
=References=&lt;br /&gt;
[[#References|[1]]] Wikipedia. (2010, November) Wikipedia - Anti-Pattern. [Online]. http://en.wikipedia.org/wiki/Anti-pattern&lt;br /&gt;
[[#References|[2]]] Analysis Paralysis. (2010, November) Analysis Paralysis. [Online]. http://c2.com/cgi/wiki?AnalysisParalysis&lt;br /&gt;
[[#References|[3]]] Analysis Paralysis. (2010, November) Programming Management Anti-Patterns. [Online]. http://sourcemaking.com/antipatterns/analysis-paralysis&lt;br /&gt;
[[#References|[4]]] Marelisa. (2010, November) How to Defeat Analysis Paralysis – The PDCA Model. [Online]. http://abundance-blog.marelisa-online.com/2010/06/26/defeat-analysis-paralysis/&lt;/div&gt;</summary>
		<author><name>Mlsurrat</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2010/ch7_7g_ms&amp;diff=43047</id>
		<title>CSC/ECE 517 Fall 2010/ch7 7g ms</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2010/ch7_7g_ms&amp;diff=43047"/>
		<updated>2010-12-01T20:56:08Z</updated>

		<summary type="html">&lt;p&gt;Mlsurrat: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;'''Analysis Paralysis Anti-Pattern'''&lt;br /&gt;
&lt;br /&gt;
=Analysis Paralysis Anti-pattern=&lt;br /&gt;
&lt;br /&gt;
In software engineering, an anti-pattern (or antipattern) is a pattern that may be commonly used but is ineffective and/or counterproductive in practice[[1]].&lt;br /&gt;
&lt;br /&gt;
Analysis paralysis is one of the classic anti-patterns in object oriented software development. In analysis paralysis, we over analyze (or over think) a situation until no decision is ever made, which effectively paralyzes the current process' outcome.&lt;br /&gt;
&lt;br /&gt;
=History=&lt;br /&gt;
In Aesop's Fables' &amp;quot;The Fox and the Cat&amp;quot;, the fox has &amp;quot;hundreds of ways of escaping&amp;quot; while the cat has &amp;quot;only one&amp;quot;. When they heard the hounds approaching, the cat scampered up a tree while &amp;quot;the Fox in his confusion was caught up by the hounds&amp;quot;. The fable ends with the moral, &amp;quot;Better one safe way than a hundred on which you cannot reckon.&amp;quot;&lt;br /&gt;
&lt;br /&gt;
In The Tragedy of Hamlet, Prince of Denmark, the main character, Prince Hamlet, is often said to have a mortal flaw of thinking too much, such that his youth and vital energy are, in Shakespeare's words, &amp;quot;sicklied o'er with the pale cast of thought.&amp;quot;&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=How to Defeat Analysis Paralysis=&lt;br /&gt;
    *Keep models small. Never integrate them. Building a bigger model doesn't add knowledge - it destroys knowledge&lt;br /&gt;
    *Employ a professional architect&lt;br /&gt;
    *Start your project with one requirement and an architectural prototype&lt;br /&gt;
&lt;br /&gt;
==The PDCA Model==&lt;br /&gt;
    *Plan&lt;br /&gt;
    *Do&lt;br /&gt;
    *Check&lt;br /&gt;
    *Act&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=Causes=&lt;br /&gt;
In software development, analysis paralysis typically manifests itself through exceedingly long phases of project planning, requirements gathering, program design and data modeling, with little or no extra value created by those steps. When extended over too long a timeframe, such processes tend to emphasize the organizational (i.e., bureaucratic) aspect of the software project, while detracting from its functional (value-creating) portion.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
*Pride &lt;br /&gt;
*Narrow Mindedness&lt;br /&gt;
*The lure of infinite composability and decomposability&lt;br /&gt;
*Insistence on completing all analysis before beginning design.&lt;br /&gt;
*Regular change of leads and their philosophies (each trashing and restarting the work of the previous)&lt;br /&gt;
*Too many learning curves at once (underqualified analyst) causing incessant revisiting of prior work&lt;br /&gt;
*Lack of goals&lt;br /&gt;
*Increasingly conflicting goals (often political)&lt;br /&gt;
*Creative speculation, when discovery and definition are required.&lt;br /&gt;
*BigProjectSyndrome: this one will do it all, will use the latest tools, will use a new paradigm, will use all new developers, will start with a clean slate, will handle all use cases of two or more existing systems in the first release, etc.&lt;br /&gt;
*Risk avoidance, fear of making a mistake. &lt;br /&gt;
&lt;br /&gt;
=References=&lt;br /&gt;
[[#References|[1]]] Wikipedia. (2010, November) Wikipedia - Anti-Pattern. [Online]. http://en.wikipedia.org/wiki/Anti-pattern&lt;br /&gt;
[[#References|[2]]] Analysis Paralysis. (2010, November) Analysis Paralysis. [Online]. http://c2.com/cgi/wiki?AnalysisParalysis&lt;br /&gt;
[[#References|[3]]] Analysis Paralysis. (2010, November) Programming Management Anti-Patterns. [Online]. http://sourcemaking.com/antipatterns/analysis-paralysis&lt;br /&gt;
[[#References|[5]]] Wikipedia. (2010, November) Wikipedia - Anti-Pattern. [Online]. http://en.wikipedia.org/wiki/Anti-pattern&lt;br /&gt;
[[#References|[5]]] Wikipedia. (2010, November) Wikipedia - Anti-Pattern. [Online]. http://en.wikipedia.org/wiki/Anti-pattern&lt;/div&gt;</summary>
		<author><name>Mlsurrat</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2010/ch7_7g_ms&amp;diff=43046</id>
		<title>CSC/ECE 517 Fall 2010/ch7 7g ms</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2010/ch7_7g_ms&amp;diff=43046"/>
		<updated>2010-12-01T20:53:04Z</updated>

		<summary type="html">&lt;p&gt;Mlsurrat: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;'''Analysis Paralysis Anti-Pattern'''&lt;br /&gt;
&lt;br /&gt;
=Analysis Paralysis Anti-pattern=&lt;br /&gt;
&lt;br /&gt;
In software engineering, an anti-pattern (or antipattern) is a pattern that may be commonly used but is ineffective and/or counterproductive in practice[[1]].&lt;br /&gt;
&lt;br /&gt;
Analysis paralysis is one of the classic anti-patterns in object oriented software development. In analysis paralysis, we over analyze (or over think) a situation until no decision is ever made, which effectively paralyzes the current process' outcome.&lt;br /&gt;
&lt;br /&gt;
=History=&lt;br /&gt;
In Aesop's Fables' &amp;quot;The Fox and the Cat&amp;quot;, the fox has &amp;quot;hundreds of ways of escaping&amp;quot; while the cat has &amp;quot;only one&amp;quot;. When they heard the hounds approaching, the cat scampered up a tree while &amp;quot;the Fox in his confusion was caught up by the hounds&amp;quot;. The fable ends with the moral, &amp;quot;Better one safe way than a hundred on which you cannot reckon.&amp;quot;&lt;br /&gt;
&lt;br /&gt;
In The Tragedy of Hamlet, Prince of Denmark, the main character, Prince Hamlet, is often said to have a mortal flaw of thinking too much, such that his youth and vital energy are, in Shakespeare's words, &amp;quot;sicklied o'er with the pale cast of thought.&amp;quot;&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=How to Defeat Analysis Paralysis=&lt;br /&gt;
    *Keep models small. Never integrate them. Building a bigger model doesn't add knowledge - it destroys knowledge&lt;br /&gt;
    *Employ a professional architect&lt;br /&gt;
    *Start your project with one requirement and an architectural prototype&lt;br /&gt;
&lt;br /&gt;
==The PDCA Model==&lt;br /&gt;
    *Plan&lt;br /&gt;
    *Do&lt;br /&gt;
    *Check&lt;br /&gt;
    *Act&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=Causes=&lt;br /&gt;
In software development, analysis paralysis typically manifests itself through exceedingly long phases of project planning, requirements gathering, program design and data modeling, with little or no extra value created by those steps. When extended over too long a timeframe, such processes tend to emphasize the organizational (i.e., bureaucratic) aspect of the software project, while detracting from its functional (value-creating) portion.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
*Pride &lt;br /&gt;
*Narrow Mindedness&lt;br /&gt;
*The lure of infinite composability and decomposability&lt;br /&gt;
*Insistence on completing all analysis before beginning design.&lt;br /&gt;
*Regular change of leads and their philosophies (each trashing and restarting the work of the previous)&lt;br /&gt;
*Too many learning curves at once (underqualified analyst) causing incessant revisiting of prior work&lt;br /&gt;
*Lack of goals&lt;br /&gt;
*Increasingly conflicting goals (often political)&lt;br /&gt;
*Creative speculation, when discovery and definition are required.&lt;br /&gt;
*BigProjectSyndrome: this one will do it all, will use the latest tools, will use a new paradigm, will use all new developers, will start with a clean slate, will handle all use cases of two or more existing systems in the first release, etc.&lt;br /&gt;
*Risk avoidance, fear of making a mistake. &lt;br /&gt;
&lt;br /&gt;
=References=&lt;br /&gt;
[[#References|[1]]] Wikipedia. (2010, November) Wikipedia - Anti-Pattern. [Online]. http://en.wikipedia.org/wiki/Anti-pattern&lt;/div&gt;</summary>
		<author><name>Mlsurrat</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2010/ch7_7g_ms&amp;diff=43045</id>
		<title>CSC/ECE 517 Fall 2010/ch7 7g ms</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2010/ch7_7g_ms&amp;diff=43045"/>
		<updated>2010-12-01T20:52:30Z</updated>

		<summary type="html">&lt;p&gt;Mlsurrat: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;'''Analysis Paralysis Anti-Pattern'''&lt;br /&gt;
&lt;br /&gt;
=Analysis Paralysis Anti-pattern=&lt;br /&gt;
&lt;br /&gt;
In software engineering, an anti-pattern (or antipattern) is a pattern that may be commonly used but is ineffective and/or counterproductive in practice[[1]].&lt;br /&gt;
&lt;br /&gt;
Analysis paralysis is one of the classic anti-patterns in object oriented software development. In analysis paralysis, we over analyze (or over think) a situation until no decision is ever made, which effectively paralyzes the current process' outcome.&lt;br /&gt;
&lt;br /&gt;
=History=&lt;br /&gt;
In Aesop's Fables' &amp;quot;The Fox and the Cat&amp;quot;, the fox has &amp;quot;hundreds of ways of escaping&amp;quot; while the cat has &amp;quot;only one&amp;quot;. When they heard the hounds approaching, the cat scampered up a tree while &amp;quot;the Fox in his confusion was caught up by the hounds&amp;quot;. The fable ends with the moral, &amp;quot;Better one safe way than a hundred on which you cannot reckon.&amp;quot;&lt;br /&gt;
&lt;br /&gt;
In The Tragedy of Hamlet, Prince of Denmark, the main character, Prince Hamlet, is often said to have a mortal flaw of thinking too much, such that his youth and vital energy are, in Shakespeare's words, &amp;quot;sicklied o'er with the pale cast of thought.&amp;quot;&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=How to Defeat Analysis Paralysis=&lt;br /&gt;
    *Keep models small. Never integrate them. Building a bigger model doesn't add knowledge - it destroys knowledge&lt;br /&gt;
    *Employ a professional architect&lt;br /&gt;
    *Start your project with one requirement and an architectural prototype&lt;br /&gt;
&lt;br /&gt;
==The PDCA Model==&lt;br /&gt;
    *Plan&lt;br /&gt;
    *Do&lt;br /&gt;
    *Check&lt;br /&gt;
    *Act&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=Causes=&lt;br /&gt;
*Pride &lt;br /&gt;
*Narrow Mindedness&lt;br /&gt;
*The lure of infinite composability and decomposability&lt;br /&gt;
*Insistence on completing all analysis before beginning design.&lt;br /&gt;
*Regular change of leads and their philosophies (each trashing and restarting the work of the previous)&lt;br /&gt;
*Too many learning curves at once (underqualified analyst) causing incessant revisiting of prior work&lt;br /&gt;
*Lack of goals&lt;br /&gt;
*Increasingly conflicting goals (often political)&lt;br /&gt;
*Creative speculation, when discovery and definition are required.&lt;br /&gt;
*BigProjectSyndrome: this one will do it all, will use the latest tools, will use a new paradigm, will use all new developers, will start with a clean slate, will handle all use cases of two or more existing systems in the first release, etc.&lt;br /&gt;
*Risk avoidance, fear of making a mistake. &lt;br /&gt;
&lt;br /&gt;
=References=&lt;br /&gt;
[[#References|[1]]] Wikipedia. (2010, November) Wikipedia - Anti-Pattern. [Online]. http://en.wikipedia.org/wiki/Anti-pattern&lt;/div&gt;</summary>
		<author><name>Mlsurrat</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2010/ch7_7g_ms&amp;diff=43044</id>
		<title>CSC/ECE 517 Fall 2010/ch7 7g ms</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2010/ch7_7g_ms&amp;diff=43044"/>
		<updated>2010-12-01T20:51:49Z</updated>

		<summary type="html">&lt;p&gt;Mlsurrat: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;'''Analysis Paralysis Anti-Pattern'''&lt;br /&gt;
&lt;br /&gt;
=Analysis Paralysis Anti-pattern=&lt;br /&gt;
&lt;br /&gt;
In software engineering, an anti-pattern (or antipattern) is a pattern that may be commonly used but is ineffective and/or counterproductive in practice[[1]].&lt;br /&gt;
&lt;br /&gt;
Analysis paralysis is one of the classic anti-patterns in object oriented software development. In analysis paralysis, we over analyze (or over think) a situation until no decision is ever made, which effectively paralyzes the current process' outcome.&lt;br /&gt;
&lt;br /&gt;
=History=&lt;br /&gt;
&lt;br /&gt;
=How to Defeat Analysis Paralysis=&lt;br /&gt;
    *Keep models small. Never integrate them. Building a bigger model doesn't add knowledge - it destroys knowledge&lt;br /&gt;
    *Employ a professional architect&lt;br /&gt;
    *Start your project with one requirement and an architectural prototype&lt;br /&gt;
&lt;br /&gt;
==The PDCA Model==&lt;br /&gt;
    *Plan&lt;br /&gt;
    *Do&lt;br /&gt;
    *Check&lt;br /&gt;
    *Act&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=Causes=&lt;br /&gt;
*Pride &lt;br /&gt;
*Narrow Mindedness&lt;br /&gt;
*The lure of infinite composability and decomposability&lt;br /&gt;
*Insistence on completing all analysis before beginning design.&lt;br /&gt;
*Regular change of leads and their philosophies (each trashing and restarting the work of the previous)&lt;br /&gt;
*Too many learning curves at once (underqualified analyst) causing incessant revisiting of prior work&lt;br /&gt;
*Lack of goals&lt;br /&gt;
*Increasingly conflicting goals (often political)&lt;br /&gt;
*Creative speculation, when discovery and definition are required.&lt;br /&gt;
*BigProjectSyndrome: this one will do it all, will use the latest tools, will use a new paradigm, will use all new developers, will start with a clean slate, will handle all use cases of two or more existing systems in the first release, etc.&lt;br /&gt;
*Risk avoidance, fear of making a mistake. &lt;br /&gt;
&lt;br /&gt;
=References=&lt;br /&gt;
[[#References|[1]]] Wikipedia. (2010, November) Wikipedia - Anti-Pattern. [Online]. http://en.wikipedia.org/wiki/Anti-pattern&lt;/div&gt;</summary>
		<author><name>Mlsurrat</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2010/ch7_7g_ms&amp;diff=43043</id>
		<title>CSC/ECE 517 Fall 2010/ch7 7g ms</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2010/ch7_7g_ms&amp;diff=43043"/>
		<updated>2010-12-01T20:49:48Z</updated>

		<summary type="html">&lt;p&gt;Mlsurrat: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;'''Analysis Paralysis Anti-Pattern'''&lt;br /&gt;
&lt;br /&gt;
=Analysis Paralysis Anti-pattern=&lt;br /&gt;
&lt;br /&gt;
In software engineering, an anti-pattern (or antipattern) is a pattern that may be commonly used but is ineffective and/or counterproductive in practice.&lt;br /&gt;
&lt;br /&gt;
Analysis Paralysis is one of the classic anti-patterns in object oriented software development. In analysis paralysis, we over analyze (or over think) a situation until no decision is ever made, which effectively paralyzes the current process' outcome.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
This diagram is a Universal Modeling Languages (UML) diagram of how a Singleton class would look if implemented in Java.&lt;br /&gt;
&lt;br /&gt;
=History=&lt;br /&gt;
&lt;br /&gt;
=How to Defeat Analysis Paralysis=&lt;br /&gt;
    *Keep models small. Never integrate them. Building a bigger model doesn't add knowledge - it destroys knowledge&lt;br /&gt;
    *Employ a professional architect&lt;br /&gt;
    *Start your project with one requirement and an architectural prototype&lt;br /&gt;
&lt;br /&gt;
==The PDCA Model==&lt;br /&gt;
    *Plan&lt;br /&gt;
    *Do&lt;br /&gt;
    *Check&lt;br /&gt;
    *Act&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=Causes=&lt;br /&gt;
*Pride &lt;br /&gt;
*Narrow Mindedness&lt;br /&gt;
*The lure of infinite composability and decomposability&lt;br /&gt;
*Insistence on completing all analysis before beginning design.&lt;br /&gt;
*Regular change of leads and their philosophies (each trashing and restarting the work of the previous)&lt;br /&gt;
*Too many learning curves at once (underqualified analyst) causing incessant revisiting of prior work&lt;br /&gt;
*Lack of goals&lt;br /&gt;
*Increasingly conflicting goals (often political)&lt;br /&gt;
*Creative speculation, when discovery and definition are required.&lt;br /&gt;
*BigProjectSyndrome: this one will do it all, will use the latest tools, will use a new paradigm, will use all new developers, will start with a clean slate, will handle all use cases of two or more existing systems in the first release, etc.&lt;br /&gt;
*Risk avoidance, fear of making a mistake. &lt;br /&gt;
&lt;br /&gt;
=References=&lt;br /&gt;
[[#References|[1]]] Wikipedia. (2010, November) Wikipedia - Anti-Pattern. [Online]. http://en.wikipedia.org/wiki/Anti-pattern&lt;/div&gt;</summary>
		<author><name>Mlsurrat</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2010/ch7_7g_ms&amp;diff=43042</id>
		<title>CSC/ECE 517 Fall 2010/ch7 7g ms</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2010/ch7_7g_ms&amp;diff=43042"/>
		<updated>2010-12-01T20:48:33Z</updated>

		<summary type="html">&lt;p&gt;Mlsurrat: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;'''Analysis Paralysis Anti-Pattern'''&lt;br /&gt;
&lt;br /&gt;
=Analysis Paralysis Anti-pattern=&lt;br /&gt;
&lt;br /&gt;
In software engineering, an anti-pattern (or antipattern) is a pattern that may be commonly used but is ineffective and/or counterproductive in practice.&lt;br /&gt;
&lt;br /&gt;
Analysis Paralysis is one of the classic anti-patterns in object oriented software development. In analysis paralysis, we over analyze (or over think) a situation until no decision is ever made, which effectively paralyzes the current process' outcome.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
This diagram is a Universal Modeling Languages (UML) diagram of how a Singleton class would look if implemented in Java.&lt;br /&gt;
&lt;br /&gt;
=History=&lt;br /&gt;
&lt;br /&gt;
=How to Defeat Analysis Paralysis=&lt;br /&gt;
    *Keep models small. Never integrate them. Building a bigger model doesn't add knowledge - it destroys knowledge&lt;br /&gt;
    *You don't have to go the whole XP hog, but make testing drive analysis. How's that? Here's a requirement; build a test harness for it. Oh, you can't? Well, why not? Do enough analysis to know how to build the harness - and then stop&lt;br /&gt;
    *Don't employ &amp;quot;analysts&amp;quot;. Employ developers. If a developer doesn't know how to analyze a requirement, they'll soon learn; if an analyst doesn't know how to develop a solution, their &amp;quot;analysis&amp;quot; is worthless&lt;br /&gt;
    *If you are management, refuse to review technical documents. Review working functionality. If you're not seeing new functionality every cycle, kick butt until you do&lt;br /&gt;
    *Employ a professional architect. Just one architect is what you want - never more than that. The architect doesn't have to be team leader - in fact it's probably better if he's not. He's not responsible for analyzing the project's requirements either. He's responsible for providing generic tools to coordinate and support the other developers. Let no one else call the shots on infrastructure, and for f*ck's sake don't go ballsing the thing up by trying to mess with it yourself. Nor let anyone suggest that architecture be decided by voting or meeting - a sure recipe for AnalysisParalysis&lt;br /&gt;
    *Start your project with one requirement and an architectural prototype. Don't give 'em more than a month to code it. Yeah, it'll be lame - but it's there, and it's code, and it works. Now let 'em refine and replace and refactor - that's real work. A project without a prototype is like a candle without a wick, which is how Analysis Paralysis really happens&lt;br /&gt;
&lt;br /&gt;
==The PDCA Model==&lt;br /&gt;
    *Plan&lt;br /&gt;
    *Do&lt;br /&gt;
    *Check&lt;br /&gt;
    *Act&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=Causes=&lt;br /&gt;
*Pride &lt;br /&gt;
*Narrow Mindedness&lt;br /&gt;
*The lure of infinite composability and decomposability&lt;br /&gt;
*Insistence on completing all analysis before beginning design.&lt;br /&gt;
*Regular change of leads and their philosophies (each trashing and restarting the work of the previous)&lt;br /&gt;
*Too many learning curves at once (underqualified analyst) causing incessant revisiting of prior work&lt;br /&gt;
*Lack of goals&lt;br /&gt;
*Increasingly conflicting goals (often political)&lt;br /&gt;
*Creative speculation, when discovery and definition are required.&lt;br /&gt;
*BigProjectSyndrome: this one will do it all, will use the latest tools, will use a new paradigm, will use all new developers, will start with a clean slate, will handle all use cases of two or more existing systems in the first release, etc.&lt;br /&gt;
*Risk avoidance, fear of making a mistake. &lt;br /&gt;
&lt;br /&gt;
=References=&lt;br /&gt;
[[#References|[1]]] Wikipedia. (2010, November) Wikipedia - Anti-Pattern. [Online]. http://en.wikipedia.org/wiki/Anti-pattern&lt;/div&gt;</summary>
		<author><name>Mlsurrat</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2010/ch7_7g_ms&amp;diff=43041</id>
		<title>CSC/ECE 517 Fall 2010/ch7 7g ms</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2010/ch7_7g_ms&amp;diff=43041"/>
		<updated>2010-12-01T20:48:01Z</updated>

		<summary type="html">&lt;p&gt;Mlsurrat: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;'''Analysis Paralysis Anti-Pattern'''&lt;br /&gt;
&lt;br /&gt;
=Analysis Paralysis Anti-pattern=&lt;br /&gt;
&lt;br /&gt;
In software engineering, an anti-pattern (or antipattern) is a pattern that may be commonly used but is ineffective and/or counterproductive in practice.&lt;br /&gt;
&lt;br /&gt;
Analysis Paralysis is one of the classic anti-patterns in object oriented software development. In analysis paralysis, we over analyze (or over think) a situation until no decision is ever made, which effectively paralyzes the current process' outcome.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
This diagram is a Universal Modeling Languages (UML) diagram of how a Singleton class would look if implemented in Java.&lt;br /&gt;
&lt;br /&gt;
=History=&lt;br /&gt;
&lt;br /&gt;
=How to Defeat Analysis Paralysis=&lt;br /&gt;
    *Keep models small. Never integrate them. Building a bigger model doesn't add knowledge - it destroys knowledge&lt;br /&gt;
    *You don't have to go the whole XP hog, but make testing drive analysis. How's that? Here's a requirement; build a test harness for it. Oh, you can't? Well, why not? Do enough analysis to know how to build the harness - and then stop!&lt;br /&gt;
    *Don't employ &amp;quot;analysts&amp;quot;. Employ developers. If a developer doesn't know how to analyze a requirement, they'll soon learn; if an analyst doesn't know how to develop a solution, their &amp;quot;analysis&amp;quot; is worthless&lt;br /&gt;
    *If you are management, refuse to review technical documents. Review working functionality. If you're not seeing new functionality every cycle, kick butt until you do&lt;br /&gt;
    *Employ a professional architect. Just one architect is what you want - never more than that. The architect doesn't have to be team leader - in fact it's probably better if he's not. He's not responsible for analyzing the project's requirements either. He's responsible for providing generic tools to coordinate and support the other developers. Let no one else call the shots on infrastructure, and for f*ck's sake don't go ballsing the thing up by trying to mess with it yourself. Nor let anyone suggest that architecture be decided by voting or meeting - a sure recipe for AnalysisParalysis&lt;br /&gt;
    *Start your project with one requirement and an architectural prototype. Don't give 'em more than a month to code it. Yeah, it'll be lame - but it's there, and it's code, and it works. Now let 'em refine and replace and refactor - that's real work. A project without a prototype is like a candle without a wick, which is how Analysis Paralysis really happens. &lt;br /&gt;
&lt;br /&gt;
==The PDCA Model==&lt;br /&gt;
    * Plan&lt;br /&gt;
    * Do&lt;br /&gt;
    * Check&lt;br /&gt;
    * Act&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=Causes=&lt;br /&gt;
*Pride &lt;br /&gt;
*Narrow Mindedness&lt;br /&gt;
*The lure of infinite composability and decomposability&lt;br /&gt;
*Insistence on completing all analysis before beginning design.&lt;br /&gt;
*Regular change of leads and their philosophies (each trashing and restarting the work of the previous)&lt;br /&gt;
*Too many learning curves at once (underqualified analyst) causing incessant revisiting of prior work&lt;br /&gt;
*Lack of goals&lt;br /&gt;
*Increasingly conflicting goals (often political)&lt;br /&gt;
*Creative speculation, when discovery and definition are required.&lt;br /&gt;
*BigProjectSyndrome: this one will do it all, will use the latest tools, will use a new paradigm, will use all new developers, will start with a clean slate, will handle all use cases of two or more existing systems in the first release, etc.&lt;br /&gt;
*Risk avoidance, fear of making a mistake. &lt;br /&gt;
&lt;br /&gt;
=References=&lt;br /&gt;
[[#References|[1]]] Wikipedia. (2010, November) Wikipedia - Anti-Pattern. [Online]. http://en.wikipedia.org/wiki/Anti-pattern&lt;/div&gt;</summary>
		<author><name>Mlsurrat</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2010/ch7_7g_ms&amp;diff=43040</id>
		<title>CSC/ECE 517 Fall 2010/ch7 7g ms</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2010/ch7_7g_ms&amp;diff=43040"/>
		<updated>2010-12-01T20:47:09Z</updated>

		<summary type="html">&lt;p&gt;Mlsurrat: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;'''Analysis Paralysis Anti-Pattern'''&lt;br /&gt;
&lt;br /&gt;
=Analysis Paralysis Anti-pattern=&lt;br /&gt;
&lt;br /&gt;
In software engineering, an anti-pattern (or antipattern) is a pattern that may be commonly used but is ineffective and/or counterproductive in practice.&lt;br /&gt;
&lt;br /&gt;
Analysis Paralysis is one of the classic anti-patterns in object oriented software development. In analysis paralysis, we over analyze (or over think) a situation until no decision is ever made, which effectively paralyzes the current process' outcome.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
This diagram is a Universal Modeling Languages (UML) diagram of how a Singleton class would look if implemented in Java.&lt;br /&gt;
&lt;br /&gt;
=History=&lt;br /&gt;
&lt;br /&gt;
=How to Defeat Analysis Paralysis=&lt;br /&gt;
    *Keep models small. Never integrate them. Building a bigger model doesn't add knowledge - it destroys knowledge&lt;br /&gt;
    *You don't have to go the whole XP hog, but make testing drive analysis. How's that? Here's a requirement; build a test harness for it. Oh, you can't? Well, why not? Do enough analysis to know how to build the harness - and then stop!&lt;br /&gt;
    *Don't employ &amp;quot;analysts&amp;quot;. Employ developers. If a developer doesn't know how to analyze a requirement, they'll soon learn; if an analyst doesn't know how to develop a solution, their &amp;quot;analysis&amp;quot; is worthless&lt;br /&gt;
    *If you are management, refuse to review technical documents. Review working functionality. If you're not seeing new functionality every cycle, kick butt until you do&lt;br /&gt;
    *Employ a professional architect. Just one architect is what you want - never more than that. The architect doesn't have to be team leader - in fact it's probably better if he's not. He's not responsible for analyzing the project's requirements either. He's responsible for providing generic tools to coordinate and support the other developers. Let no one else call the shots on infrastructure, and for f*ck's sake don't go ballsing the thing up by trying to mess with it yourself. Nor let anyone suggest that architecture be decided by voting or meeting - a sure recipe for AnalysisParalysis&lt;br /&gt;
    *Start your project with one requirement and an architectural prototype. Don't give 'em more than a month to code it. Yeah, it'll be lame - but it's there, and it's code, and it works. Now let 'em refine and replace and refactor - that's real work. A project without a prototype is like a candle without a wick, which is how Analysis Paralysis really happens. &lt;br /&gt;
&lt;br /&gt;
=Causes=&lt;br /&gt;
*Pride &lt;br /&gt;
*Narrow Mindedness&lt;br /&gt;
*The lure of infinite composability and decomposability&lt;br /&gt;
*Insistence on completing all analysis before beginning design.&lt;br /&gt;
*Regular change of leads and their philosophies (each trashing and restarting the work of the previous)&lt;br /&gt;
*Too many learning curves at once (underqualified analyst) causing incessant revisiting of prior work&lt;br /&gt;
*Lack of goals&lt;br /&gt;
*Increasingly conflicting goals (often political)&lt;br /&gt;
*Creative speculation, when discovery and definition are required.&lt;br /&gt;
*BigProjectSyndrome: this one will do it all, will use the latest tools, will use a new paradigm, will use all new developers, will start with a clean slate, will handle all use cases of two or more existing systems in the first release, etc.&lt;br /&gt;
*Risk avoidance, fear of making a mistake. &lt;br /&gt;
&lt;br /&gt;
=References=&lt;br /&gt;
[[#References|[1]]] Wikipedia. (2010, November) Wikipedia - Anti-Pattern. [Online]. http://en.wikipedia.org/wiki/Anti-pattern&lt;/div&gt;</summary>
		<author><name>Mlsurrat</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2010/ch7_7g_ms&amp;diff=43039</id>
		<title>CSC/ECE 517 Fall 2010/ch7 7g ms</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2010/ch7_7g_ms&amp;diff=43039"/>
		<updated>2010-12-01T20:46:36Z</updated>

		<summary type="html">&lt;p&gt;Mlsurrat: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;'''Analysis Paralysis Anti-Pattern'''&lt;br /&gt;
&lt;br /&gt;
=Analysis Paralysis Anti-pattern=&lt;br /&gt;
&lt;br /&gt;
In software engineering, an anti-pattern (or antipattern) is a pattern that may be commonly used but is ineffective and/or counterproductive in practice.&lt;br /&gt;
&lt;br /&gt;
Analysis Paralysis is one of the classic anti-patterns in object oriented software development. In analysis paralysis, we over analyze (or over think) a situation until no decision is ever made, which effectively paralyzes the current process' outcome.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
This diagram is a Universal Modeling Languages (UML) diagram of how a Singleton class would look if implemented in Java.&lt;br /&gt;
&lt;br /&gt;
=History=&lt;br /&gt;
&lt;br /&gt;
=How to Defeat Analysis Paralysis=&lt;br /&gt;
    *Keep models small. Never integrate them. Building a bigger model doesn't add knowledge - it destroys knowledge.&lt;br /&gt;
    *You don't have to go the whole XP hog, but make testing drive analysis. How's that? Here's a requirement; build a test harness for it. Oh, you can't? Well, why not? Do enough analysis to know how to build the harness - and then stop!&lt;br /&gt;
    *Don't employ &amp;quot;analysts&amp;quot;. Employ developers. If a developer doesn't know how to analyze a requirement, they'll soon learn; if an analyst doesn't know how to develop a solution, their &amp;quot;analysis&amp;quot; is worthless.&lt;br /&gt;
    *If you are management, refuse to review technical documents. Review working functionality. If you're not seeing new functionality every cycle, kick butt until you do.&lt;br /&gt;
    *Employ a professional architect. Just one architect is what you want - never more than that. The architect doesn't have to be team leader - in fact it's probably better if he's not. He's not responsible for analyzing the project's requirements either. He's responsible for providing generic tools to coordinate and support the other developers. Let no one else call the shots on infrastructure, and for f*ck's sake don't go ballsing the thing up by trying to mess with it yourself. Nor let anyone suggest that architecture be decided by voting or meeting - a sure recipe for AnalysisParalysis.&lt;br /&gt;
    *Start your project with one requirement and an architectural prototype. Don't give 'em more than a month to code it. Yeah, it'll be lame - but it's there, and it's code, and it works. Now let 'em refine and replace and refactor - that's real work. A project without a prototype is like a candle without a wick, which is how Analysis Paralysis really happens. &lt;br /&gt;
&lt;br /&gt;
=Causes=&lt;br /&gt;
*Pride &lt;br /&gt;
*Narrow Mindedness&lt;br /&gt;
*The lure of infinite composability and decomposability&lt;br /&gt;
*Insistence on completing all analysis before beginning design.&lt;br /&gt;
*Regular change of leads and their philosophies (each trashing and restarting the work of the previous)&lt;br /&gt;
*Too many learning curves at once (underqualified analyst) causing incessant revisiting of prior work&lt;br /&gt;
*Lack of goals&lt;br /&gt;
*Increasingly conflicting goals (often political)&lt;br /&gt;
*Creative speculation, when discovery and definition are required.&lt;br /&gt;
*BigProjectSyndrome: this one will do it all, will use the latest tools, will use a new paradigm, will use all new developers, will start with a clean slate, will handle all use cases of two or more existing systems in the first release, etc.&lt;br /&gt;
*Risk avoidance, fear of making a mistake. &lt;br /&gt;
&lt;br /&gt;
=References=&lt;br /&gt;
[[#References|[1]]] Wikipedia. (2010, November) Wikipedia - Anti-Pattern. [Online]. http://en.wikipedia.org/wiki/Anti-pattern&lt;/div&gt;</summary>
		<author><name>Mlsurrat</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2010/ch7_7g_ms&amp;diff=43038</id>
		<title>CSC/ECE 517 Fall 2010/ch7 7g ms</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2010/ch7_7g_ms&amp;diff=43038"/>
		<updated>2010-12-01T20:44:41Z</updated>

		<summary type="html">&lt;p&gt;Mlsurrat: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;'''Analysis Paralysis Anti-Pattern'''&lt;br /&gt;
&lt;br /&gt;
=Analysis Paralysis Anti-pattern=&lt;br /&gt;
&lt;br /&gt;
In software engineering, an anti-pattern (or antipattern) is a pattern that may be commonly used but is ineffective and/or counterproductive in practice.&lt;br /&gt;
&lt;br /&gt;
Analysis Paralysis is one of the classic anti-patterns in object oriented software development. In analysis paralysis, we over analyze (or over think) a situation until no decision is ever made, which effectively paralyzes the current process' outcome.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
This diagram is a Universal Modeling Languages (UML) diagram of how a Singleton class would look if implemented in Java.&lt;br /&gt;
&lt;br /&gt;
=History=&lt;br /&gt;
&lt;br /&gt;
=How to Defeat Analysis Paralysis=&lt;br /&gt;
    *Keep models small. Never integrate them. Building a bigger model doesn't add knowledge - it destroys knowledge.&lt;br /&gt;
    *You don't have to go the whole XP hog, but make testing drive analysis. How's that? Here's a requirement; build a test harness for it. Oh, you can't? Well, why not? Do enough analysis to know how to build the harness - and then stop!&lt;br /&gt;
    *Don't employ &amp;quot;analysts&amp;quot;. Employ developers. If a developer doesn't know how to analyze a requirement, they'll soon learn; if an analyst doesn't know how to develop a solution, their &amp;quot;analysis&amp;quot; is worthless.&lt;br /&gt;
    *If you are management, refuse to review technical documents. Review working functionality. If you're not seeing new functionality every cycle, kick butt until you do.&lt;br /&gt;
    *Employ a professional architect. Just one architect is what you want - never more than that. The architect doesn't have to be team leader - in fact it's probably better if he's not. He's not responsible for analyzing the project's requirements either. He's responsible for providing generic tools to coordinate and support the other developers. Let no one else call the shots on infrastructure, and for f*ck's sake don't go ballsing the thing up by trying to mess with it yourself. Nor let anyone suggest that architecture be decided by voting or meeting - a sure recipe for AnalysisParalysis.&lt;br /&gt;
    *Start your project with one requirement and an architectural prototype. Don't give 'em more than a month to code it. Yeah, it'll be lame - but it's there, and it's code, and it works. Now let 'em refine and replace and refactor - that's real work. A project without a prototype is like a candle without a wick, which is how Analysis Paralysis really happens. &lt;br /&gt;
&lt;br /&gt;
=Causes=&lt;br /&gt;
*Pride &lt;br /&gt;
*Narrow Mindedness&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=References=&lt;br /&gt;
[[#References|[1]]] Wikipedia. (2010, November) Wikipedia - Anti-Pattern. [Online]. http://en.wikipedia.org/wiki/Anti-pattern&lt;/div&gt;</summary>
		<author><name>Mlsurrat</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2010/ch7_7g_ms&amp;diff=43037</id>
		<title>CSC/ECE 517 Fall 2010/ch7 7g ms</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2010/ch7_7g_ms&amp;diff=43037"/>
		<updated>2010-12-01T20:44:13Z</updated>

		<summary type="html">&lt;p&gt;Mlsurrat: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;'''Analysis Paralysis Anti-Pattern'''&lt;br /&gt;
&lt;br /&gt;
=Analysis Paralysis Anti-pattern=&lt;br /&gt;
&lt;br /&gt;
In software engineering, an anti-pattern (or antipattern) is a pattern that may be commonly used but is ineffective and/or counterproductive in practice.&lt;br /&gt;
&lt;br /&gt;
Analysis Paralysis is one of the classic anti-patterns in object oriented software development. In analysis paralysis, we over analyze (or over think) a situation until no decision is ever made, which effectively paralyzes the current process' outcome.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
This diagram is a Universal Modeling Languages (UML) diagram of how a Singleton class would look if implemented in Java.&lt;br /&gt;
&lt;br /&gt;
=History=&lt;br /&gt;
&lt;br /&gt;
=How to Defeat Analysis Paralysis=&lt;br /&gt;
    * Keep models small. Never integrate them. Building a bigger model doesn't add knowledge - it destroys knowledge.&lt;br /&gt;
    * You don't have to go the whole XP hog, but make testing drive analysis. How's that? Here's a requirement; build a test harness for it. Oh, you can't? Well, why not? Do enough analysis to know how to build the harness - and then stop!&lt;br /&gt;
    * Don't employ &amp;quot;analysts&amp;quot;. Employ developers. If a developer doesn't know how to analyze a requirement, they'll soon learn; if an analyst doesn't know how to develop a solution, their &amp;quot;analysis&amp;quot; is worthless.&lt;br /&gt;
    * If you are management, refuse to review technical documents. Review working functionality. If you're not seeing new functionality every cycle, kick butt until you do.&lt;br /&gt;
    * Employ a professional architect. Just one architect is what you want - never more than that. The architect doesn't have to be team leader - in fact it's probably better if he's not. He's not responsible for analyzing the project's requirements either. He's responsible for providing generic tools to coordinate and support the other developers. Let no one else call the shots on infrastructure, and for f*ck's sake don't go ballsing the thing up by trying to mess with it yourself. Nor let anyone suggest that architecture be decided by voting or meeting - a sure recipe for AnalysisParalysis.&lt;br /&gt;
    * Start your project with one requirement and an architectural prototype. Don't give 'em more than a month to code it. Yeah, it'll be lame - but it's there, and it's code, and it works. Now let 'em refine and replace and refactor - that's real work. A project without a prototype is like a candle without a wick, which is how Analysis Paralysis really happens. &lt;br /&gt;
&lt;br /&gt;
=Causes=&lt;br /&gt;
*Pride &lt;br /&gt;
*Narrow Mindedness&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=References=&lt;br /&gt;
[[#References|[1]]] Wikipedia. (2010, November) Wikipedia - Anti-Pattern. [Online]. http://en.wikipedia.org/wiki/Anti-pattern&lt;/div&gt;</summary>
		<author><name>Mlsurrat</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2010/ch7_7g_ms&amp;diff=43033</id>
		<title>CSC/ECE 517 Fall 2010/ch7 7g ms</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2010/ch7_7g_ms&amp;diff=43033"/>
		<updated>2010-12-01T20:37:45Z</updated>

		<summary type="html">&lt;p&gt;Mlsurrat: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;'''Analysis Paralysis Anti-Pattern'''&lt;br /&gt;
&lt;br /&gt;
=Analysis Paralysis Anti-pattern=&lt;br /&gt;
&lt;br /&gt;
In software engineering, an anti-pattern (or antipattern) is a pattern that may be commonly used but is ineffective and/or counterproductive in practice.&lt;br /&gt;
&lt;br /&gt;
Analysis Paralysis is one of the classic anti-patterns in object oriented software development. In analysis paralysis, we over analyze (or over think) a situation until no decision is ever made, which effectively paralyzes the current process' outcome.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
This diagram is a Universal Modeling Languages (UML) diagram of how a Singleton class would look if implemented in Java.&lt;br /&gt;
&lt;br /&gt;
=History=&lt;br /&gt;
&lt;br /&gt;
=How to Defeat Analysis Paralysis=&lt;br /&gt;
    * Keep models small. Never integrate them. Building a bigger model doesn't add knowledge - it destroys knowledge.&lt;br /&gt;
    * You don't have to go the whole XP hog, but make testing drive analysis. How's that? Here's a requirement; build a test harness for it. Oh, you can't? Well, why not? Do enough analysis to know how to build the harness - and then stop!&lt;br /&gt;
    * Don't employ &amp;quot;analysts&amp;quot;. Employ developers. If a developer doesn't know how to analyze a requirement, they'll soon learn; if an analyst doesn't know how to develop a solution, their &amp;quot;analysis&amp;quot; is worthless.&lt;br /&gt;
    * If you are management, refuse to review technical documents. Review working functionality. If you're not seeing new functionality every cycle, kick butt until you do.&lt;br /&gt;
    * Employ a professional architect. Just one architect is what you want - never more than that. The architect doesn't have to be team leader - in fact it's probably better if he's not. He's not responsible for analyzing the project's requirements either. He's responsible for providing generic tools to coordinate and support the other developers. Let no one else call the shots on infrastructure, and for f*ck's sake don't go ballsing the thing up by trying to mess with it yourself. Nor let anyone suggest that architecture be decided by voting or meeting - a sure recipe for AnalysisParalysis.&lt;br /&gt;
    * Start your project with one requirement and an architectural prototype. Don't give 'em more than a month to code it. Yeah, it'll be lame - but it's there, and it's code, and it works. Now let 'em refine and replace and refactor - that's real work. A project without a prototype is like a candle without a wick, which is how AnalysisParalysis really happens. &lt;br /&gt;
&lt;br /&gt;
=Causes=&lt;br /&gt;
*Pride &lt;br /&gt;
*Narrow Mindedness&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=References=&lt;/div&gt;</summary>
		<author><name>Mlsurrat</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2010/ch7_7g_ms&amp;diff=43032</id>
		<title>CSC/ECE 517 Fall 2010/ch7 7g ms</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2010/ch7_7g_ms&amp;diff=43032"/>
		<updated>2010-12-01T20:28:53Z</updated>

		<summary type="html">&lt;p&gt;Mlsurrat: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;'''Analysis Paralysis Anti-Pattern'''&lt;br /&gt;
&lt;br /&gt;
=Analysis Paralysis Anti-pattern=&lt;br /&gt;
&lt;br /&gt;
In software engineering, an anti-pattern (or antipattern) is a pattern that may be commonly used but is ineffective and/or counterproductive in practice.&lt;br /&gt;
&lt;br /&gt;
In analysis paralysis, we over analyze (or over think) a situation until no decision is ever made, which effectively paralyzes the current process' outcome.&lt;br /&gt;
&lt;br /&gt;
===Class Diagram===&lt;br /&gt;
[[Image:IC73826.gif|500px|center]]&lt;br /&gt;
&lt;br /&gt;
This diagram is a Universal Modeling Languages (UML) diagram of how a Singleton class would look if implemented in Java.&lt;br /&gt;
===Sequence Diagram===&lt;br /&gt;
[[Image:CR2.gif|500px|center]]&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
=Implementation=&lt;br /&gt;
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]]]&lt;br /&gt;
&lt;br /&gt;
==Creating the instance==&lt;br /&gt;
===Early Instantiation===&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
===Late Instantiation===&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
==Accessing the instance==&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
=Examples=&lt;br /&gt;
==Java==&lt;br /&gt;
&lt;br /&gt;
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.  &lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
    private static final Singleton INSTANCE = new Singleton();&lt;br /&gt;
   &lt;br /&gt;
    // Private constructor prevents instantiation from other classes&lt;br /&gt;
    private Singleton() {&lt;br /&gt;
    }&lt;br /&gt;
&lt;br /&gt;
    public static Singleton getInstance() {&lt;br /&gt;
        return INSTANCE;&lt;br /&gt;
    }&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
[[#References|[1]]]&lt;br /&gt;
&lt;br /&gt;
==Ruby==&lt;br /&gt;
&lt;br /&gt;
Ruby implements the Singleton pattern by privatizing the &amp;quot;new&amp;quot; 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]]]&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
class genericFactory&lt;br /&gt;
  include Singleton&lt;br /&gt;
end&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
[[#References|[1]]]&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
class Logger&lt;br /&gt;
  def initialize&lt;br /&gt;
    @log = File.open(&amp;quot;log.txt&amp;quot;, &amp;quot;a&amp;quot;)&lt;br /&gt;
  end&lt;br /&gt;
  &lt;br /&gt;
  @@instance = Logger.new&lt;br /&gt;
&lt;br /&gt;
  def self.instance&lt;br /&gt;
    return @@instance&lt;br /&gt;
  end&lt;br /&gt;
  &lt;br /&gt;
  def log(msg)&lt;br /&gt;
    @log.puts(msg)&lt;br /&gt;
  end&lt;br /&gt;
  &lt;br /&gt;
  private_class_method :new&lt;br /&gt;
end&lt;br /&gt;
&lt;br /&gt;
Logger.instance.log('message 1')&lt;br /&gt;
&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
[[#References|[6]]]&lt;br /&gt;
&lt;br /&gt;
==C++==&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
// Declaration&lt;br /&gt;
class Singleton {&lt;br /&gt;
public: &lt;br /&gt;
    static Singleton* Instance();&lt;br /&gt;
protected: &lt;br /&gt;
    Singleton();&lt;br /&gt;
private:&lt;br /&gt;
    static Singleton* _instance;&lt;br /&gt;
}&lt;br /&gt;
&lt;br /&gt;
// Implementation &lt;br /&gt;
Singleton* Singleton::_instance = 0;&lt;br /&gt;
&lt;br /&gt;
Singleton* Singleton::Instance() {&lt;br /&gt;
    if (_instance == 0) {&lt;br /&gt;
        _instance = new Singleton;&lt;br /&gt;
    }&lt;br /&gt;
    return _instance;&lt;br /&gt;
}&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
[[#References|[3]]]&lt;br /&gt;
&lt;br /&gt;
=Benefits=&lt;br /&gt;
&lt;br /&gt;
*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]]]&lt;br /&gt;
&lt;br /&gt;
*The Singleton class has the ability to control the instantiation process since it implements the instantiation functionality.[[#References|[3]]]&lt;br /&gt;
&lt;br /&gt;
=Drawbacks=&lt;br /&gt;
&lt;br /&gt;
*Unit tests are much harder to write when using the Singleton pattern.[[#References|[3]]]&lt;br /&gt;
&lt;br /&gt;
*This pattern reduces the potential for parallelism within a program since the threads must be serialized.[[#References|[3]]]&lt;br /&gt;
&lt;br /&gt;
*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]]]&lt;br /&gt;
&lt;br /&gt;
*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 &amp;quot;new&amp;quot; keyword to instantiate the object.[[#References|[3]]]&lt;br /&gt;
&lt;br /&gt;
*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]]]&lt;br /&gt;
&lt;br /&gt;
=References=&lt;br /&gt;
&lt;br /&gt;
[[#References|[1]]] Wikipedia. (2010, October) Wikipedia - Singleton_Pattern. [Online]. http://en.wikipedia.org/wiki/Singleton_pattern#Traditional_simple_way&lt;br /&gt;
&lt;br /&gt;
[[#References|[2]]] Freeman, Eric, Elisabeth Freeman, Kathy Sierra, and Bert Bates. (October 2004) Head First design patterns. [Print.]&lt;br /&gt;
&lt;br /&gt;
[[#References|[3]]] C# Corner (2010, October) Creational Patterns - Singleton. [Online]. http://www.c-sharpcorner.com/UploadFile/susanabraham/CreationalPatterns06042005050058AM/CreationalPatterns.aspx&lt;br /&gt;
&lt;br /&gt;
[[#References|[4]]] Source Making (2010, October) Singleton Design Pattern. [Online]. http://sourcemaking.com/design_patterns/singleton&lt;br /&gt;
&lt;br /&gt;
[[#References|[5]]] JavaBeginner.com (2010, October) Java Singleton Design Pattern. [Online]. http://www.javabeginner.com/learn-java/java-singleton-design-pattern&lt;br /&gt;
&lt;br /&gt;
[[#References|[6]]] Dalibor Nasevic (2010, October) Ruby Singleton Pattern Again. [Online]. http://dalibornasevic.com/posts/9-ruby-singleton-pattern-again&lt;/div&gt;</summary>
		<author><name>Mlsurrat</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2010/ch1_S10_ms&amp;diff=43031</id>
		<title>CSC/ECE 517 Fall 2010/ch1 S10 ms</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2010/ch1_S10_ms&amp;diff=43031"/>
		<updated>2010-12-01T19:57:28Z</updated>

		<summary type="html">&lt;p&gt;Mlsurrat: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;*[[CSC/ECE 517 Fall 2010/ch1 1a vc]]&lt;br /&gt;
&lt;br /&gt;
*[[CSC/ECE 517 Fall 2010/ch1 1a br]]&lt;br /&gt;
&lt;br /&gt;
*[[CSC/ECE 517 Fall 2010/ch1 1b mg]]&lt;br /&gt;
&lt;br /&gt;
*[[CSC/ECE 517 Fall 2010/ch1 1c JF]]&lt;br /&gt;
&lt;br /&gt;
*[[CSC/ECE 517 Fall 2010/ch1 1e az]]&lt;br /&gt;
&lt;br /&gt;
*[[CSC/ECE 517 Fall 2010/ch1 1e bb]]&lt;br /&gt;
&lt;br /&gt;
*[[CSC/ECE 517 Fall 2010/ch1 1f vn]]&lt;br /&gt;
&lt;br /&gt;
*[[CSC/ECE 517 Fall 2010/ch1 25 ag]]&lt;br /&gt;
&lt;br /&gt;
*[[CSC/ECE 517 Fall 2010/ch2 2b dg]]&lt;br /&gt;
&lt;br /&gt;
*[[CSC/ECE 517 Fall 2010/ch1 2e RI]]&lt;br /&gt;
&lt;br /&gt;
*[[CSC/ECE 517 Fall 2010/ch1 S6 aa]]&lt;br /&gt;
&lt;br /&gt;
*[[CSC/ECE 517 Fall 2010/ch1 S6 km]]&lt;br /&gt;
&lt;br /&gt;
*[[CSC/ECE 517 Fall 2010/ch1 S10 GP]]&lt;br /&gt;
&lt;br /&gt;
*[[CSC/ECE 517 Fall 2010/ch1 S10 MS]]&lt;br /&gt;
&lt;br /&gt;
*[[CSC/ECE 517 Fall 2010/ch1 S10 MM]]&lt;br /&gt;
&lt;br /&gt;
*[[CSC/ECE 517 Fall 2010/ch1 S10 PH]]&lt;br /&gt;
&lt;br /&gt;
*[[CSC/ECE 517 Fall 2010/ch2 2a CB]]&lt;br /&gt;
&lt;br /&gt;
*[[CSC/ECE 517 Fall 2010/ch2 2a mw]]&lt;br /&gt;
&lt;br /&gt;
*[[CSC/ECE 517 Fall 2010/ch2 2c ck]]&lt;br /&gt;
&lt;br /&gt;
*[[CSC/ECE 517 Fall 2010/ch2 S23 GP]]&lt;br /&gt;
&lt;br /&gt;
*[[CSC/ECE 517 Fall 2010/ch2 S24 NS]]&lt;br /&gt;
&lt;br /&gt;
*[[CSC/ECE 517 Fall 2010/ch2 S23 SS]]&lt;br /&gt;
&lt;br /&gt;
*[[CSC/ECE 517 Fall 2010/ch2 S23 NR]]&lt;br /&gt;
&lt;br /&gt;
*[[CSC/ECE 517 Fall 2010/ch2 S20 TT]]&lt;br /&gt;
&lt;br /&gt;
*[[CSC/ECE 517 Fall 2010/ch2 2d AS]]&lt;br /&gt;
&lt;br /&gt;
*[[CSC/ECE 517 Fall 2010/ch2 S24 rm]]&lt;br /&gt;
&lt;br /&gt;
*[[CSC/ECE 517 Fall 2010/ch3 3a SN]]&lt;br /&gt;
&lt;br /&gt;
*[[CSC/ECE 517 Fall 2010/ch3 3b ka]]&lt;br /&gt;
&lt;br /&gt;
*[[CSC/ECE 517 Fall 2010/ch3 3e br]]&lt;br /&gt;
&lt;br /&gt;
*[[CSC/ECE 517 Fall 2010/ch3 3f lj]]&lt;br /&gt;
&lt;br /&gt;
*[[CSC/ECE 517 Fall 2010/ch3 3h az]]&lt;br /&gt;
&lt;br /&gt;
*[[CSC/ECE 517 Fall 2010/ch3 3h PW]]&lt;br /&gt;
&lt;br /&gt;
*[[CSC/ECE 517 Fall 2010/ch3 3i IC]]&lt;br /&gt;
&lt;br /&gt;
*[[CSC/ECE 517 Fall 2010/ch3 3i MM]]&lt;br /&gt;
&lt;br /&gt;
*[[CSC/ECE 517 Fall 2010/ch3 3j KS]]&lt;br /&gt;
&lt;br /&gt;
*[[CSC/ECE 517 Fall 2010/ch3 S30 SK]]&lt;br /&gt;
&lt;br /&gt;
*[[CSC/ECE 517 Fall 2010/ch3 4b mt]]&lt;br /&gt;
&lt;br /&gt;
*[[CSC/ECE 517 Fall 2010/ch4 4e ms]]&lt;br /&gt;
&lt;br /&gt;
*[[CSC/ECE 517 Fall 2010/ch4 4f sv]]&lt;br /&gt;
&lt;br /&gt;
*[[CSC/ECE 517 Fall 2010/ch4 4g HW]]&lt;br /&gt;
&lt;br /&gt;
*[[CSC/ECE 517 Fall 2010/ch4 4g km]]&lt;br /&gt;
&lt;br /&gt;
*[[CSC/ECE 517 Fall 2010/ch4 4h am]]&lt;br /&gt;
&lt;br /&gt;
*[[CSC/ECE 517 Fall 2010/ch5 5b mt]]&lt;br /&gt;
&lt;br /&gt;
*[[CSC/ECE 517 Fall 2010/ch5 5b jz]]&lt;br /&gt;
&lt;br /&gt;
*[[CSC/ECE 517 Fall 2010/ch5 5c ck]]&lt;br /&gt;
&lt;br /&gt;
*[[CSC/ECE 517 Fall 2010/ch5 5c IC]]&lt;br /&gt;
&lt;br /&gt;
*[[CSC/ECE 517 Fall 2010/ch5 5f SN]]&lt;br /&gt;
&lt;br /&gt;
*[[CSC/ECE 517 Fall 2010/ch5 5a KR]]&lt;br /&gt;
&lt;br /&gt;
*[[CSC/ECE 517 Fall 2010/ch5 5b RR]]&lt;br /&gt;
&lt;br /&gt;
*[[CSC/ECE 517 Fall 2010/ch5 5e ms]]&lt;br /&gt;
&lt;br /&gt;
*[[CSC/ECE 517 Fall 2010/chd 6d isb]]&lt;br /&gt;
&lt;br /&gt;
*[[CSC/ECE 517 Fall 2010/ch6 6b SK]]&lt;br /&gt;
&lt;br /&gt;
*[[CSC/ECE 517 Fall 2010/ch6 6c AW]]&lt;br /&gt;
&lt;br /&gt;
*[[CSC/ECE 517 Fall 2010/ch6 6d bb]]&lt;br /&gt;
&lt;br /&gt;
*[[CSC/ECE 517 Fall 2010/ch6 6h AS]]&lt;br /&gt;
&lt;br /&gt;
*[[CSC/ECE 517 Fall 2010/ch6 6f AZ]]&lt;br /&gt;
&lt;br /&gt;
*[[CSC/ECE 517 Fall 2010/ch6 6b AK]]&lt;br /&gt;
&lt;br /&gt;
*[[CSC/ECE 517 Fall 2010/ch6 6g ss]]&lt;br /&gt;
&lt;br /&gt;
*[[CSC/ECE 517 Fall 2010/ch6 6d NM]]&lt;br /&gt;
&lt;br /&gt;
*[[ CSC/ECE 517 Fall 2010/ch6 6a PC]]&lt;br /&gt;
&lt;br /&gt;
*[[ CSC/ECE 517 Fall 2010/ch2 4d RB]]&lt;br /&gt;
&lt;br /&gt;
*[[ CSC/ECE 517 Fall 2010/ch7 7e GP]]&lt;br /&gt;
&lt;br /&gt;
*[[ CSC/ECE 517 Fall 2010/ch7 7f PW]]&lt;br /&gt;
&lt;br /&gt;
*[[ CSC/ECE 517 Fall 2010/ch7 7g ms]]&lt;/div&gt;</summary>
		<author><name>Mlsurrat</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2010/ch3_3f_lj&amp;diff=37953</id>
		<title>CSC/ECE 517 Fall 2010/ch3 3f lj</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2010/ch3_3f_lj&amp;diff=37953"/>
		<updated>2010-10-14T02:28:59Z</updated>

		<summary type="html">&lt;p&gt;Mlsurrat: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;'''Singleton Pattern in Static and Dynamic languages'''&lt;br /&gt;
&lt;br /&gt;
=Singleton pattern=&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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.  &lt;br /&gt;
  &lt;br /&gt;
&lt;br /&gt;
===Class Diagram===&lt;br /&gt;
[[Image:IC73826.gif|500px|center]]&lt;br /&gt;
&lt;br /&gt;
This diagram is a Universal Modeling Languages (UML) diagram of how a Singleton class would look if implemented in Java.&lt;br /&gt;
===Sequence Diagram===&lt;br /&gt;
[[Image:CR2.gif|500px|center]]&lt;br /&gt;
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.&lt;br /&gt;
=Implementation=&lt;br /&gt;
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]]]&lt;br /&gt;
&lt;br /&gt;
==Creating the instance==&lt;br /&gt;
===Early Instantiation===&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
===Late Instantiation===&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
==Accessing the instance==&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
=Examples=&lt;br /&gt;
==Java==&lt;br /&gt;
&lt;br /&gt;
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.  &lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
    private static final Singleton INSTANCE = new Singleton();&lt;br /&gt;
   &lt;br /&gt;
    // Private constructor prevents instantiation from other classes&lt;br /&gt;
    private Singleton() {&lt;br /&gt;
    }&lt;br /&gt;
&lt;br /&gt;
    public static Singleton getInstance() {&lt;br /&gt;
        return INSTANCE;&lt;br /&gt;
    }&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
[[#References|[1]]]&lt;br /&gt;
&lt;br /&gt;
==Ruby==&lt;br /&gt;
&lt;br /&gt;
Ruby implements the Singleton pattern by privatizing the &amp;quot;new&amp;quot; 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]]]&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
class genericFactory&lt;br /&gt;
  include Singleton&lt;br /&gt;
end&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
[[#References|[1]]]&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
class Logger&lt;br /&gt;
  def initialize&lt;br /&gt;
    @log = File.open(&amp;quot;log.txt&amp;quot;, &amp;quot;a&amp;quot;)&lt;br /&gt;
  end&lt;br /&gt;
  &lt;br /&gt;
  @@instance = Logger.new&lt;br /&gt;
&lt;br /&gt;
  def self.instance&lt;br /&gt;
    return @@instance&lt;br /&gt;
  end&lt;br /&gt;
  &lt;br /&gt;
  def log(msg)&lt;br /&gt;
    @log.puts(msg)&lt;br /&gt;
  end&lt;br /&gt;
  &lt;br /&gt;
  private_class_method :new&lt;br /&gt;
end&lt;br /&gt;
&lt;br /&gt;
Logger.instance.log('message 1')&lt;br /&gt;
&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
[[#References|[6]]]&lt;br /&gt;
&lt;br /&gt;
==C++==&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
// Declaration&lt;br /&gt;
class Singleton {&lt;br /&gt;
public: &lt;br /&gt;
    static Singleton* Instance();&lt;br /&gt;
protected: &lt;br /&gt;
    Singleton();&lt;br /&gt;
private:&lt;br /&gt;
    static Singleton* _instance;&lt;br /&gt;
}&lt;br /&gt;
&lt;br /&gt;
// Implementation &lt;br /&gt;
Singleton* Singleton::_instance = 0;&lt;br /&gt;
&lt;br /&gt;
Singleton* Singleton::Instance() {&lt;br /&gt;
    if (_instance == 0) {&lt;br /&gt;
        _instance = new Singleton;&lt;br /&gt;
    }&lt;br /&gt;
    return _instance;&lt;br /&gt;
}&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
[[#References|[3]]]&lt;br /&gt;
&lt;br /&gt;
=Benefits=&lt;br /&gt;
&lt;br /&gt;
*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]]]&lt;br /&gt;
&lt;br /&gt;
*The Singleton class has the ability to control the instantiation process since it implements the instantiation functionality.[[#References|[3]]]&lt;br /&gt;
&lt;br /&gt;
=Drawbacks=&lt;br /&gt;
&lt;br /&gt;
*Unit tests are much harder to write when using the Singleton pattern.[[#References|[3]]]&lt;br /&gt;
&lt;br /&gt;
*This pattern reduces the potential for parallelism within a program since the threads must be serialized.[[#References|[3]]]&lt;br /&gt;
&lt;br /&gt;
*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]]]&lt;br /&gt;
&lt;br /&gt;
*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 &amp;quot;new&amp;quot; keyword to instantiate the object.[[#References|[3]]]&lt;br /&gt;
&lt;br /&gt;
*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]]]&lt;br /&gt;
&lt;br /&gt;
=References=&lt;br /&gt;
&lt;br /&gt;
[[#References|[1]]] Wikipedia. (2010, October) Wikipedia - Singleton_Pattern. [Online]. http://en.wikipedia.org/wiki/Singleton_pattern#Traditional_simple_way&lt;br /&gt;
&lt;br /&gt;
[[#References|[2]]] Freeman, Eric, Elisabeth Freeman, Kathy Sierra, and Bert Bates. (October 2004) Head First design patterns. [Print.]&lt;br /&gt;
&lt;br /&gt;
[[#References|[3]]] C# Corner (2010, October) Creational Patterns - Singleton. [Online]. http://www.c-sharpcorner.com/UploadFile/susanabraham/CreationalPatterns06042005050058AM/CreationalPatterns.aspx&lt;br /&gt;
&lt;br /&gt;
[[#References|[4]]] Source Making (2010, October) Singleton Design Pattern. [Online]. http://sourcemaking.com/design_patterns/singleton&lt;br /&gt;
&lt;br /&gt;
[[#References|[5]]] JavaBeginner.com (2010, October) Java Singleton Design Pattern. [Online]. http://www.javabeginner.com/learn-java/java-singleton-design-pattern&lt;br /&gt;
&lt;br /&gt;
[[#References|[6]]] Dalibor Nasevic (2010, October) Ruby Singleton Pattern Again. [Online]. http://dalibornasevic.com/posts/9-ruby-singleton-pattern-again&lt;/div&gt;</summary>
		<author><name>Mlsurrat</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2010/ch3_3f_lj&amp;diff=37945</id>
		<title>CSC/ECE 517 Fall 2010/ch3 3f lj</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2010/ch3_3f_lj&amp;diff=37945"/>
		<updated>2010-10-14T02:20:36Z</updated>

		<summary type="html">&lt;p&gt;Mlsurrat: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;'''Singleton Pattern in Static and Dynamic languages'''&lt;br /&gt;
&lt;br /&gt;
=Singleton pattern=&lt;br /&gt;
&lt;br /&gt;
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.  &lt;br /&gt;
&lt;br /&gt;
===Class Diagram===&lt;br /&gt;
[[Image:IC73826.gif|500px|center]]&lt;br /&gt;
&lt;br /&gt;
This diagram is a Universal Modeling Languages (UML) diagram of how a Singleton class would look if implemented in Java.&lt;br /&gt;
===Sequence Diagram===&lt;br /&gt;
[[Image:CR2.gif|500px|center]]&lt;br /&gt;
&lt;br /&gt;
=Implementation=&lt;br /&gt;
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]]]&lt;br /&gt;
&lt;br /&gt;
==Creating the instance==&lt;br /&gt;
===Early Instantiation===&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
===Late Instantiation===&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
==Accessing the instance==&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
=Examples=&lt;br /&gt;
==Java==&lt;br /&gt;
&lt;br /&gt;
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.  &lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
    private static final Singleton INSTANCE = new Singleton();&lt;br /&gt;
   &lt;br /&gt;
    // Private constructor prevents instantiation from other classes&lt;br /&gt;
    private Singleton() {&lt;br /&gt;
    }&lt;br /&gt;
&lt;br /&gt;
    public static Singleton getInstance() {&lt;br /&gt;
        return INSTANCE;&lt;br /&gt;
    }&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
[[#References|[1]]]&lt;br /&gt;
&lt;br /&gt;
==Ruby==&lt;br /&gt;
&lt;br /&gt;
Ruby implements the Singleton pattern by privatizing the &amp;quot;new&amp;quot; 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.  &lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
class genericFactory&lt;br /&gt;
  include Singleton&lt;br /&gt;
end&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
[[#References|[1]]]&lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
class Logger&lt;br /&gt;
  def initialize&lt;br /&gt;
    @log = File.open(&amp;quot;log.txt&amp;quot;, &amp;quot;a&amp;quot;)&lt;br /&gt;
  end&lt;br /&gt;
  &lt;br /&gt;
  @@instance = Logger.new&lt;br /&gt;
&lt;br /&gt;
  def self.instance&lt;br /&gt;
    return @@instance&lt;br /&gt;
  end&lt;br /&gt;
  &lt;br /&gt;
  def log(msg)&lt;br /&gt;
    @log.puts(msg)&lt;br /&gt;
  end&lt;br /&gt;
  &lt;br /&gt;
  private_class_method :new&lt;br /&gt;
end&lt;br /&gt;
&lt;br /&gt;
Logger.instance.log('message 1')&lt;br /&gt;
&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
[[#References|[6]]]&lt;br /&gt;
&lt;br /&gt;
==C++==&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
// Declaration&lt;br /&gt;
class Singleton {&lt;br /&gt;
public: &lt;br /&gt;
    static Singleton* Instance();&lt;br /&gt;
protected: &lt;br /&gt;
    Singleton();&lt;br /&gt;
private:&lt;br /&gt;
    static Singleton* _instance;&lt;br /&gt;
}&lt;br /&gt;
&lt;br /&gt;
// Implementation &lt;br /&gt;
Singleton* Singleton::_instance = 0;&lt;br /&gt;
&lt;br /&gt;
Singleton* Singleton::Instance() {&lt;br /&gt;
    if (_instance == 0) {&lt;br /&gt;
        _instance = new Singleton;&lt;br /&gt;
    }&lt;br /&gt;
    return _instance;&lt;br /&gt;
}&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
[[#References|[3]]]&lt;br /&gt;
&lt;br /&gt;
=Benefits=&lt;br /&gt;
&lt;br /&gt;
*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]]]&lt;br /&gt;
&lt;br /&gt;
*The Singleton class has the ability to control the instantiation process since it implements the instantiation functionality.[[#References|[3]]]&lt;br /&gt;
&lt;br /&gt;
=Drawbacks=&lt;br /&gt;
&lt;br /&gt;
*Unit tests are much harder to write when using the Singleton pattern.[[#References|[3]]]&lt;br /&gt;
&lt;br /&gt;
*This pattern reduces the potential for parallelism within a program since the threads must be serialized.[[#References|[3]]]&lt;br /&gt;
&lt;br /&gt;
*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]]]&lt;br /&gt;
&lt;br /&gt;
*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 &amp;quot;new&amp;quot; keyword to instantiate the object.[[#References|[3]]]&lt;br /&gt;
&lt;br /&gt;
*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]]]&lt;br /&gt;
&lt;br /&gt;
=References=&lt;br /&gt;
&lt;br /&gt;
[[#References|[1]]] Wikipedia. (2010, October) Wikipedia - Singleton_Pattern. [Online]. http://en.wikipedia.org/wiki/Singleton_pattern#Traditional_simple_way&lt;br /&gt;
&lt;br /&gt;
[[#References|[2]]] Freeman, Eric, Elisabeth Freeman, Kathy Sierra, and Bert Bates. (October 2004) Head First design patterns. [Print.]&lt;br /&gt;
&lt;br /&gt;
[[#References|[3]]] C# Corner (2010, October) Creational Patterns - Singleton. [Online]. http://www.c-sharpcorner.com/UploadFile/susanabraham/CreationalPatterns06042005050058AM/CreationalPatterns.aspx&lt;br /&gt;
&lt;br /&gt;
[[#References|[4]]] Source Making (2010, October) Singleton Design Pattern. [Online]. http://sourcemaking.com/design_patterns/singleton&lt;br /&gt;
&lt;br /&gt;
[[#References|[5]]] JavaBeginner.com (2010, October) Java Singleton Design Pattern. [Online]. http://www.javabeginner.com/learn-java/java-singleton-design-pattern&lt;br /&gt;
&lt;br /&gt;
[[#References|[6]]] Dalibor Nasevic (2010, October) Ruby Singleton Pattern Again. [Online]. http://dalibornasevic.com/posts/9-ruby-singleton-pattern-again&lt;/div&gt;</summary>
		<author><name>Mlsurrat</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2010/ch3_3f_lj&amp;diff=37936</id>
		<title>CSC/ECE 517 Fall 2010/ch3 3f lj</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2010/ch3_3f_lj&amp;diff=37936"/>
		<updated>2010-10-14T02:10:26Z</updated>

		<summary type="html">&lt;p&gt;Mlsurrat: /* Defintions */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;'''Singleton Pattern in Static and Dynamic languages'''&lt;br /&gt;
&lt;br /&gt;
=Singleton pattern=&lt;br /&gt;
  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.  &lt;br /&gt;
&lt;br /&gt;
===Class Diagram===&lt;br /&gt;
[[Image:IC73826.gif|500px|center]]&lt;br /&gt;
===Sequence Diagram===&lt;br /&gt;
[[Image:CR2.gif|500px|center]]&lt;br /&gt;
&lt;br /&gt;
=Implementation=&lt;br /&gt;
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]]]&lt;br /&gt;
&lt;br /&gt;
==Creating the instance==&lt;br /&gt;
===Early Instantiation===&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
===Late Instantiation===&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
==Accessing the instance==&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
=Examples=&lt;br /&gt;
==Java==&lt;br /&gt;
&lt;br /&gt;
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.  &lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
    private static final Singleton INSTANCE = new Singleton();&lt;br /&gt;
   &lt;br /&gt;
    // Private constructor prevents instantiation from other classes&lt;br /&gt;
    private Singleton() {&lt;br /&gt;
    }&lt;br /&gt;
&lt;br /&gt;
    public static Singleton getInstance() {&lt;br /&gt;
        return INSTANCE;&lt;br /&gt;
    }&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
[[#References|[1]]]&lt;br /&gt;
&lt;br /&gt;
==Ruby==&lt;br /&gt;
&lt;br /&gt;
Ruby implements the Singleton pattern by privatizing the &amp;quot;new&amp;quot; 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.  &lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
class genericFactory&lt;br /&gt;
  include Singleton&lt;br /&gt;
end&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
[[#References|[1]]]&lt;br /&gt;
&lt;br /&gt;
==C++==&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
// Declaration&lt;br /&gt;
class Singleton {&lt;br /&gt;
public: &lt;br /&gt;
    static Singleton* Instance();&lt;br /&gt;
protected: &lt;br /&gt;
    Singleton();&lt;br /&gt;
private:&lt;br /&gt;
    static Singleton* _instance;&lt;br /&gt;
}&lt;br /&gt;
&lt;br /&gt;
// Implementation &lt;br /&gt;
Singleton* Singleton::_instance = 0;&lt;br /&gt;
&lt;br /&gt;
Singleton* Singleton::Instance() {&lt;br /&gt;
    if (_instance == 0) {&lt;br /&gt;
        _instance = new Singleton;&lt;br /&gt;
    }&lt;br /&gt;
    return _instance;&lt;br /&gt;
}&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
[[#References|[1]]]&lt;br /&gt;
&lt;br /&gt;
=Benefits=&lt;br /&gt;
&lt;br /&gt;
*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.&lt;br /&gt;
&lt;br /&gt;
*The Singleton class has the ability to control the instantiation process since it implements the instantiation functionality.&lt;br /&gt;
&lt;br /&gt;
=Drawbacks=&lt;br /&gt;
&lt;br /&gt;
*Unit tests are much harder to write when using the Singleton pattern&lt;br /&gt;
&lt;br /&gt;
*This pattern reduces the potential for parallelism within a program since the threads must be serialized.&lt;br /&gt;
&lt;br /&gt;
*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.  &lt;br /&gt;
&lt;br /&gt;
*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 &amp;quot;new&amp;quot; keyword to instantiate the object.&lt;br /&gt;
&lt;br /&gt;
*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.&lt;br /&gt;
&lt;br /&gt;
=References=&lt;br /&gt;
&lt;br /&gt;
[[#References|[1]]] Wikipedia. (2010, October) Wikipedia - Singleton_Pattern. [Online]. http://en.wikipedia.org/wiki/Singleton_pattern#Traditional_simple_way&lt;br /&gt;
&lt;br /&gt;
[[#References|[2]]] Freeman, Eric, Elisabeth Freeman, Kathy Sierra, and Bert Bates. (October 2004) Head First design patterns. [Print.]&lt;br /&gt;
&lt;br /&gt;
[[#References|[3]]] C# Corner (2010, October) Creational Patterns - Singleton. [Online]. http://www.c-sharpcorner.com/UploadFile/susanabraham/CreationalPatterns06042005050058AM/CreationalPatterns.aspx&lt;br /&gt;
&lt;br /&gt;
[[#References|[4]]] Source Making (2010, October) Singleton Design Pattern. [Online]. http://sourcemaking.com/design_patterns/singleton&lt;br /&gt;
&lt;br /&gt;
[[#References|[5]]] JavaBeginner.com (2010, October) Java Singleton Design Pattern. [Online]. http://www.javabeginner.com/learn-java/java-singleton-design-pattern&lt;/div&gt;</summary>
		<author><name>Mlsurrat</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2010/ch3_3f_lj&amp;diff=37935</id>
		<title>CSC/ECE 517 Fall 2010/ch3 3f lj</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2010/ch3_3f_lj&amp;diff=37935"/>
		<updated>2010-10-14T02:09:55Z</updated>

		<summary type="html">&lt;p&gt;Mlsurrat: /* Defintions */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;'''Singleton Pattern in Static and Dynamic languages'''&lt;br /&gt;
&lt;br /&gt;
=Singleton pattern=&lt;br /&gt;
==Defintions==&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
  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.  &lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
===Class Diagram===&lt;br /&gt;
[[Image:IC73826.gif|500px|center]]&lt;br /&gt;
===Sequence Diagram===&lt;br /&gt;
[[Image:CR2.gif|500px|center]]&lt;br /&gt;
&lt;br /&gt;
=Implementation=&lt;br /&gt;
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]]]&lt;br /&gt;
&lt;br /&gt;
==Creating the instance==&lt;br /&gt;
===Early Instantiation===&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
===Late Instantiation===&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
==Accessing the instance==&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
=Examples=&lt;br /&gt;
==Java==&lt;br /&gt;
&lt;br /&gt;
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.  &lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
    private static final Singleton INSTANCE = new Singleton();&lt;br /&gt;
   &lt;br /&gt;
    // Private constructor prevents instantiation from other classes&lt;br /&gt;
    private Singleton() {&lt;br /&gt;
    }&lt;br /&gt;
&lt;br /&gt;
    public static Singleton getInstance() {&lt;br /&gt;
        return INSTANCE;&lt;br /&gt;
    }&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
[[#References|[1]]]&lt;br /&gt;
&lt;br /&gt;
==Ruby==&lt;br /&gt;
&lt;br /&gt;
Ruby implements the Singleton pattern by privatizing the &amp;quot;new&amp;quot; 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.  &lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
class genericFactory&lt;br /&gt;
  include Singleton&lt;br /&gt;
end&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
[[#References|[1]]]&lt;br /&gt;
&lt;br /&gt;
==C++==&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
// Declaration&lt;br /&gt;
class Singleton {&lt;br /&gt;
public: &lt;br /&gt;
    static Singleton* Instance();&lt;br /&gt;
protected: &lt;br /&gt;
    Singleton();&lt;br /&gt;
private:&lt;br /&gt;
    static Singleton* _instance;&lt;br /&gt;
}&lt;br /&gt;
&lt;br /&gt;
// Implementation &lt;br /&gt;
Singleton* Singleton::_instance = 0;&lt;br /&gt;
&lt;br /&gt;
Singleton* Singleton::Instance() {&lt;br /&gt;
    if (_instance == 0) {&lt;br /&gt;
        _instance = new Singleton;&lt;br /&gt;
    }&lt;br /&gt;
    return _instance;&lt;br /&gt;
}&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
[[#References|[1]]]&lt;br /&gt;
&lt;br /&gt;
=Benefits=&lt;br /&gt;
&lt;br /&gt;
*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.&lt;br /&gt;
&lt;br /&gt;
*The Singleton class has the ability to control the instantiation process since it implements the instantiation functionality.&lt;br /&gt;
&lt;br /&gt;
=Drawbacks=&lt;br /&gt;
&lt;br /&gt;
*Unit tests are much harder to write when using the Singleton pattern&lt;br /&gt;
&lt;br /&gt;
*This pattern reduces the potential for parallelism within a program since the threads must be serialized.&lt;br /&gt;
&lt;br /&gt;
*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.  &lt;br /&gt;
&lt;br /&gt;
*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 &amp;quot;new&amp;quot; keyword to instantiate the object.&lt;br /&gt;
&lt;br /&gt;
*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.&lt;br /&gt;
&lt;br /&gt;
=References=&lt;br /&gt;
&lt;br /&gt;
[[#References|[1]]] Wikipedia. (2010, October) Wikipedia - Singleton_Pattern. [Online]. http://en.wikipedia.org/wiki/Singleton_pattern#Traditional_simple_way&lt;br /&gt;
&lt;br /&gt;
[[#References|[2]]] Freeman, Eric, Elisabeth Freeman, Kathy Sierra, and Bert Bates. (October 2004) Head First design patterns. [Print.]&lt;br /&gt;
&lt;br /&gt;
[[#References|[3]]] C# Corner (2010, October) Creational Patterns - Singleton. [Online]. http://www.c-sharpcorner.com/UploadFile/susanabraham/CreationalPatterns06042005050058AM/CreationalPatterns.aspx&lt;br /&gt;
&lt;br /&gt;
[[#References|[4]]] Source Making (2010, October) Singleton Design Pattern. [Online]. http://sourcemaking.com/design_patterns/singleton&lt;br /&gt;
&lt;br /&gt;
[[#References|[5]]] JavaBeginner.com (2010, October) Java Singleton Design Pattern. [Online]. http://www.javabeginner.com/learn-java/java-singleton-design-pattern&lt;/div&gt;</summary>
		<author><name>Mlsurrat</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2010/ch3_3f_lj&amp;diff=37932</id>
		<title>CSC/ECE 517 Fall 2010/ch3 3f lj</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2010/ch3_3f_lj&amp;diff=37932"/>
		<updated>2010-10-14T02:09:33Z</updated>

		<summary type="html">&lt;p&gt;Mlsurrat: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;'''Singleton Pattern in Static and Dynamic languages'''&lt;br /&gt;
&lt;br /&gt;
=Singleton pattern=&lt;br /&gt;
==Defintions==&lt;br /&gt;
  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.  &lt;br /&gt;
&lt;br /&gt;
===Class Diagram===&lt;br /&gt;
[[Image:IC73826.gif|500px|center]]&lt;br /&gt;
===Sequence Diagram===&lt;br /&gt;
[[Image:CR2.gif|500px|center]]&lt;br /&gt;
&lt;br /&gt;
=Implementation=&lt;br /&gt;
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]]]&lt;br /&gt;
&lt;br /&gt;
==Creating the instance==&lt;br /&gt;
===Early Instantiation===&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
===Late Instantiation===&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
==Accessing the instance==&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
=Examples=&lt;br /&gt;
==Java==&lt;br /&gt;
&lt;br /&gt;
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.  &lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
    private static final Singleton INSTANCE = new Singleton();&lt;br /&gt;
   &lt;br /&gt;
    // Private constructor prevents instantiation from other classes&lt;br /&gt;
    private Singleton() {&lt;br /&gt;
    }&lt;br /&gt;
&lt;br /&gt;
    public static Singleton getInstance() {&lt;br /&gt;
        return INSTANCE;&lt;br /&gt;
    }&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==Ruby==&lt;br /&gt;
&lt;br /&gt;
Ruby implements the Singleton pattern by privatizing the &amp;quot;new&amp;quot; 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.  &lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
class genericFactory&lt;br /&gt;
  include Singleton&lt;br /&gt;
end&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==C++==&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
// Declaration&lt;br /&gt;
class Singleton {&lt;br /&gt;
public: &lt;br /&gt;
    static Singleton* Instance();&lt;br /&gt;
protected: &lt;br /&gt;
    Singleton();&lt;br /&gt;
private:&lt;br /&gt;
    static Singleton* _instance;&lt;br /&gt;
}&lt;br /&gt;
&lt;br /&gt;
// Implementation &lt;br /&gt;
Singleton* Singleton::_instance = 0;&lt;br /&gt;
&lt;br /&gt;
Singleton* Singleton::Instance() {&lt;br /&gt;
    if (_instance == 0) {&lt;br /&gt;
        _instance = new Singleton;&lt;br /&gt;
    }&lt;br /&gt;
    return _instance;&lt;br /&gt;
}&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
[[#References|[1]]]&lt;br /&gt;
&lt;br /&gt;
=Benefits=&lt;br /&gt;
&lt;br /&gt;
*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.&lt;br /&gt;
&lt;br /&gt;
*The Singleton class has the ability to control the instantiation process since it implements the instantiation functionality.&lt;br /&gt;
&lt;br /&gt;
=Drawbacks=&lt;br /&gt;
&lt;br /&gt;
*Unit tests are much harder to write when using the Singleton pattern&lt;br /&gt;
&lt;br /&gt;
*This pattern reduces the potential for parallelism within a program since the threads must be serialized.&lt;br /&gt;
&lt;br /&gt;
*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.  &lt;br /&gt;
&lt;br /&gt;
*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 &amp;quot;new&amp;quot; keyword to instantiate the object.&lt;br /&gt;
&lt;br /&gt;
*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.&lt;br /&gt;
&lt;br /&gt;
=References=&lt;br /&gt;
&lt;br /&gt;
[[#References|[1]]] Wikipedia. (2010, October) Wikipedia - Singleton_Pattern. [Online]. http://en.wikipedia.org/wiki/Singleton_pattern#Traditional_simple_way&lt;br /&gt;
&lt;br /&gt;
[[#References|[2]]] Freeman, Eric, Elisabeth Freeman, Kathy Sierra, and Bert Bates. (October 2004) Head First design patterns. [Print.]&lt;br /&gt;
&lt;br /&gt;
[[#References|[3]]] C# Corner (2010, October) Creational Patterns - Singleton. [Online]. http://www.c-sharpcorner.com/UploadFile/susanabraham/CreationalPatterns06042005050058AM/CreationalPatterns.aspx&lt;br /&gt;
&lt;br /&gt;
[[#References|[4]]] Source Making (2010, October) Singleton Design Pattern. [Online]. http://sourcemaking.com/design_patterns/singleton&lt;br /&gt;
&lt;br /&gt;
[[#References|[5]]] JavaBeginner.com (2010, October) Java Singleton Design Pattern. [Online]. http://www.javabeginner.com/learn-java/java-singleton-design-pattern&lt;/div&gt;</summary>
		<author><name>Mlsurrat</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2010/ch3_3f_lj&amp;diff=37923</id>
		<title>CSC/ECE 517 Fall 2010/ch3 3f lj</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2010/ch3_3f_lj&amp;diff=37923"/>
		<updated>2010-10-14T02:00:13Z</updated>

		<summary type="html">&lt;p&gt;Mlsurrat: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;'''Singleton Pattern in Static and Dynamic languages'''&lt;br /&gt;
&lt;br /&gt;
=Singleton pattern=&lt;br /&gt;
==Defintions==&lt;br /&gt;
  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.  &lt;br /&gt;
&lt;br /&gt;
===Class Diagram===&lt;br /&gt;
[[Image:IC73826.gif|500px|center]]&lt;br /&gt;
===Sequence Diagram===&lt;br /&gt;
[[Image:CR2.gif|500px|center]]&lt;br /&gt;
&lt;br /&gt;
=Implementation=&lt;br /&gt;
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]]]&lt;br /&gt;
&lt;br /&gt;
==Creating the instance==&lt;br /&gt;
===Early Instantiation===&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
===Late Instantiation===&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
==Accessing the instance==&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
=Examples=&lt;br /&gt;
==Java==&lt;br /&gt;
&lt;br /&gt;
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.  &lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
    private static final Singleton INSTANCE = new Singleton();&lt;br /&gt;
   &lt;br /&gt;
    // Private constructor prevents instantiation from other classes&lt;br /&gt;
    private Singleton() {&lt;br /&gt;
    }&lt;br /&gt;
&lt;br /&gt;
    public static Singleton getInstance() {&lt;br /&gt;
        return INSTANCE;&lt;br /&gt;
    }&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==Ruby==&lt;br /&gt;
&lt;br /&gt;
Ruby implements the Singleton pattern by privatizing the &amp;quot;new&amp;quot; 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.  &lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
class genericFactory&lt;br /&gt;
  include Singleton&lt;br /&gt;
end&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==C++==&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
// Declaration&lt;br /&gt;
class Singleton {&lt;br /&gt;
public: &lt;br /&gt;
    static Singleton* Instance();&lt;br /&gt;
protected: &lt;br /&gt;
    Singleton();&lt;br /&gt;
private:&lt;br /&gt;
    static Singleton* _instance;&lt;br /&gt;
}&lt;br /&gt;
&lt;br /&gt;
// Implementation &lt;br /&gt;
Singleton* Singleton::_instance = 0;&lt;br /&gt;
&lt;br /&gt;
Singleton* Singleton::Instance() {&lt;br /&gt;
    if (_instance == 0) {&lt;br /&gt;
        _instance = new Singleton;&lt;br /&gt;
    }&lt;br /&gt;
    return _instance;&lt;br /&gt;
}&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
=Drawbacks=&lt;br /&gt;
&lt;br /&gt;
*Unit tests are much harder to write when using the Singleton pattern&lt;br /&gt;
&lt;br /&gt;
*This pattern reduces the potential for parallelism within a program since the threads must be serialized.&lt;br /&gt;
&lt;br /&gt;
*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.  &lt;br /&gt;
&lt;br /&gt;
*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 &amp;quot;new&amp;quot; keyword to instantiate the object.&lt;br /&gt;
&lt;br /&gt;
*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.&lt;br /&gt;
&lt;br /&gt;
=References=&lt;br /&gt;
&lt;br /&gt;
[[#References|[1]]] Wikipedia. (2010, October) Wikipedia - Singleton_Pattern. [Online]. http://en.wikipedia.org/wiki/Singleton_pattern#Traditional_simple_way&lt;br /&gt;
&lt;br /&gt;
[[#References|[2]]] Freeman, Eric, Elisabeth Freeman, Kathy Sierra, and Bert Bates. (October 2004) Head First design patterns. [Print.]&lt;/div&gt;</summary>
		<author><name>Mlsurrat</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2010/ch3_3f_lj&amp;diff=37922</id>
		<title>CSC/ECE 517 Fall 2010/ch3 3f lj</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2010/ch3_3f_lj&amp;diff=37922"/>
		<updated>2010-10-14T01:59:09Z</updated>

		<summary type="html">&lt;p&gt;Mlsurrat: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;'''Singleton Pattern in Static and Dynamic languages'''&lt;br /&gt;
&lt;br /&gt;
==Singleton pattern==&lt;br /&gt;
&lt;br /&gt;
  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.  &lt;br /&gt;
&lt;br /&gt;
===Class Diagram===&lt;br /&gt;
[[Image:IC73826.gif|500px|center]]&lt;br /&gt;
===Sequence Diagram===&lt;br /&gt;
[[Image:CR2.gif|500px|center]]&lt;br /&gt;
&lt;br /&gt;
=Implementation=&lt;br /&gt;
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]]]&lt;br /&gt;
&lt;br /&gt;
==Creating the instance==&lt;br /&gt;
===Early Instantiation===&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
===Late Instantiation===&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
==Accessing the instance==&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
=Examples=&lt;br /&gt;
==Java==&lt;br /&gt;
&lt;br /&gt;
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.  &lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
    private static final Singleton INSTANCE = new Singleton();&lt;br /&gt;
   &lt;br /&gt;
    // Private constructor prevents instantiation from other classes&lt;br /&gt;
    private Singleton() {&lt;br /&gt;
    }&lt;br /&gt;
&lt;br /&gt;
    public static Singleton getInstance() {&lt;br /&gt;
        return INSTANCE;&lt;br /&gt;
    }&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==Ruby==&lt;br /&gt;
&lt;br /&gt;
Ruby implements the Singleton pattern by privatizing the &amp;quot;new&amp;quot; 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.  &lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
class genericFactory&lt;br /&gt;
  include Singleton&lt;br /&gt;
end&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==C++==&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
// Declaration&lt;br /&gt;
class Singleton {&lt;br /&gt;
public: &lt;br /&gt;
    static Singleton* Instance();&lt;br /&gt;
protected: &lt;br /&gt;
    Singleton();&lt;br /&gt;
private:&lt;br /&gt;
    static Singleton* _instance;&lt;br /&gt;
}&lt;br /&gt;
&lt;br /&gt;
// Implementation &lt;br /&gt;
Singleton* Singleton::_instance = 0;&lt;br /&gt;
&lt;br /&gt;
Singleton* Singleton::Instance() {&lt;br /&gt;
    if (_instance == 0) {&lt;br /&gt;
        _instance = new Singleton;&lt;br /&gt;
    }&lt;br /&gt;
    return _instance;&lt;br /&gt;
}&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
=Drawbacks=&lt;br /&gt;
&lt;br /&gt;
*Unit tests are much harder to write when using the Singleton pattern&lt;br /&gt;
&lt;br /&gt;
*This pattern reduces the potential for parallelism within a program since the threads must be serialized.&lt;br /&gt;
&lt;br /&gt;
*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.  &lt;br /&gt;
&lt;br /&gt;
*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 &amp;quot;new&amp;quot; keyword to instantiate the object.&lt;br /&gt;
&lt;br /&gt;
*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.&lt;br /&gt;
&lt;br /&gt;
=References=&lt;br /&gt;
&lt;br /&gt;
[[#References|[1]]] Wikipedia. (2010, October) Wikipedia - Singleton_Pattern. [Online]. http://en.wikipedia.org/wiki/Singleton_pattern#Traditional_simple_way&lt;br /&gt;
&lt;br /&gt;
[[#References|[2]]] Freeman, Eric, Elisabeth Freeman, Kathy Sierra, and Bert Bates. (October 2004) Head First design patterns. [Print.]&lt;/div&gt;</summary>
		<author><name>Mlsurrat</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2010/ch3_3f_lj&amp;diff=37919</id>
		<title>CSC/ECE 517 Fall 2010/ch3 3f lj</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2010/ch3_3f_lj&amp;diff=37919"/>
		<updated>2010-10-14T01:45:53Z</updated>

		<summary type="html">&lt;p&gt;Mlsurrat: /* Singleton pattern */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;'''Singleton Pattern in Static and Dynamic languages'''&lt;br /&gt;
&lt;br /&gt;
=Singleton pattern=&lt;br /&gt;
&lt;br /&gt;
  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.&lt;br /&gt;
&lt;br /&gt;
===Class Diagram===&lt;br /&gt;
[[Image:IC73826.gif|500px|center]]&lt;br /&gt;
===Sequence Diagram===&lt;br /&gt;
[[Image:CR2.gif|500px|center]]&lt;br /&gt;
&lt;br /&gt;
=Implementation=&lt;br /&gt;
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]]]&lt;br /&gt;
&lt;br /&gt;
==Creating the instance==&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
==Accessing the instance==&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
=Examples=&lt;br /&gt;
==Java==&lt;br /&gt;
&lt;br /&gt;
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.  &lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
    private static final Singleton INSTANCE = new Singleton();&lt;br /&gt;
   &lt;br /&gt;
    // Private constructor prevents instantiation from other classes&lt;br /&gt;
    private Singleton() {&lt;br /&gt;
    }&lt;br /&gt;
&lt;br /&gt;
    public static Singleton getInstance() {&lt;br /&gt;
        return INSTANCE;&lt;br /&gt;
    }&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==Ruby==&lt;br /&gt;
&lt;br /&gt;
Ruby implements the Singleton pattern by privatizing the &amp;quot;new&amp;quot; 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.  &lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
class genericFactory&lt;br /&gt;
  include Singleton&lt;br /&gt;
end&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==C++==&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
// Declaration&lt;br /&gt;
class Singleton {&lt;br /&gt;
public: &lt;br /&gt;
    static Singleton* Instance();&lt;br /&gt;
protected: &lt;br /&gt;
    Singleton();&lt;br /&gt;
private:&lt;br /&gt;
    static Singleton* _instance;&lt;br /&gt;
}&lt;br /&gt;
&lt;br /&gt;
// Implementation &lt;br /&gt;
Singleton* Singleton::_instance = 0;&lt;br /&gt;
&lt;br /&gt;
Singleton* Singleton::Instance() {&lt;br /&gt;
    if (_instance == 0) {&lt;br /&gt;
        _instance = new Singleton;&lt;br /&gt;
    }&lt;br /&gt;
    return _instance;&lt;br /&gt;
}&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
=Drawbacks=&lt;br /&gt;
&lt;br /&gt;
*Unit tests are much harder to write when using the Singleton pattern&lt;br /&gt;
&lt;br /&gt;
*This pattern reduces the potential for parallelism within a program since the threads must be serialized.&lt;br /&gt;
&lt;br /&gt;
*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.  &lt;br /&gt;
&lt;br /&gt;
*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 &amp;quot;new&amp;quot; keyword to instantiate the object.&lt;br /&gt;
&lt;br /&gt;
*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.&lt;br /&gt;
&lt;br /&gt;
=References=&lt;br /&gt;
&lt;br /&gt;
[[#References|[1]]] Wikipedia. (2010, October) Wikipedia - Singleton_Pattern. [Online]. http://en.wikipedia.org/wiki/Singleton_pattern#Traditional_simple_way&lt;br /&gt;
&lt;br /&gt;
[[#References|[2]]] Freeman, Eric, Elisabeth Freeman, Kathy Sierra, and Bert Bates. (October 2004) Head First design patterns. [Print.]&lt;/div&gt;</summary>
		<author><name>Mlsurrat</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2010/ch3_3f_lj&amp;diff=37918</id>
		<title>CSC/ECE 517 Fall 2010/ch3 3f lj</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2010/ch3_3f_lj&amp;diff=37918"/>
		<updated>2010-10-14T01:45:32Z</updated>

		<summary type="html">&lt;p&gt;Mlsurrat: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;'''Singleton Pattern in Static and Dynamic languages'''&lt;br /&gt;
&lt;br /&gt;
=Singleton pattern=&lt;br /&gt;
  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.&lt;br /&gt;
&lt;br /&gt;
===Class Diagram===&lt;br /&gt;
[[Image:IC73826.gif|500px|center]]&lt;br /&gt;
===Sequence Diagram===&lt;br /&gt;
[[Image:CR2.gif|500px|center]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=Implementation=&lt;br /&gt;
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]]]&lt;br /&gt;
&lt;br /&gt;
==Creating the instance==&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
==Accessing the instance==&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
=Examples=&lt;br /&gt;
==Java==&lt;br /&gt;
&lt;br /&gt;
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.  &lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
    private static final Singleton INSTANCE = new Singleton();&lt;br /&gt;
   &lt;br /&gt;
    // Private constructor prevents instantiation from other classes&lt;br /&gt;
    private Singleton() {&lt;br /&gt;
    }&lt;br /&gt;
&lt;br /&gt;
    public static Singleton getInstance() {&lt;br /&gt;
        return INSTANCE;&lt;br /&gt;
    }&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==Ruby==&lt;br /&gt;
&lt;br /&gt;
Ruby implements the Singleton pattern by privatizing the &amp;quot;new&amp;quot; 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.  &lt;br /&gt;
&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
class genericFactory&lt;br /&gt;
  include Singleton&lt;br /&gt;
end&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
==C++==&lt;br /&gt;
&amp;lt;pre&amp;gt;&lt;br /&gt;
// Declaration&lt;br /&gt;
class Singleton {&lt;br /&gt;
public: &lt;br /&gt;
    static Singleton* Instance();&lt;br /&gt;
protected: &lt;br /&gt;
    Singleton();&lt;br /&gt;
private:&lt;br /&gt;
    static Singleton* _instance;&lt;br /&gt;
}&lt;br /&gt;
&lt;br /&gt;
// Implementation &lt;br /&gt;
Singleton* Singleton::_instance = 0;&lt;br /&gt;
&lt;br /&gt;
Singleton* Singleton::Instance() {&lt;br /&gt;
    if (_instance == 0) {&lt;br /&gt;
        _instance = new Singleton;&lt;br /&gt;
    }&lt;br /&gt;
    return _instance;&lt;br /&gt;
}&lt;br /&gt;
&amp;lt;/pre&amp;gt;&lt;br /&gt;
&lt;br /&gt;
=Drawbacks=&lt;br /&gt;
&lt;br /&gt;
*Unit tests are much harder to write when using the Singleton pattern&lt;br /&gt;
&lt;br /&gt;
*This pattern reduces the potential for parallelism within a program since the threads must be serialized.&lt;br /&gt;
&lt;br /&gt;
*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.  &lt;br /&gt;
&lt;br /&gt;
*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 &amp;quot;new&amp;quot; keyword to instantiate the object.&lt;br /&gt;
&lt;br /&gt;
*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.&lt;br /&gt;
&lt;br /&gt;
=References=&lt;br /&gt;
&lt;br /&gt;
[[#References|[1]]] Wikipedia. (2010, October) Wikipedia - Singleton_Pattern. [Online]. http://en.wikipedia.org/wiki/Singleton_pattern#Traditional_simple_way&lt;br /&gt;
&lt;br /&gt;
[[#References|[2]]] Freeman, Eric, Elisabeth Freeman, Kathy Sierra, and Bert Bates. (October 2004) Head First design patterns. [Print.]&lt;/div&gt;</summary>
		<author><name>Mlsurrat</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2010/ch3_3f_lj&amp;diff=37902</id>
		<title>CSC/ECE 517 Fall 2010/ch3 3f lj</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2010/ch3_3f_lj&amp;diff=37902"/>
		<updated>2010-10-14T01:17:46Z</updated>

		<summary type="html">&lt;p&gt;Mlsurrat: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;'''Singleton Pattern in Static and Dynamic languages'''&lt;br /&gt;
&lt;br /&gt;
=Singleton pattern=&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
===Class Diagram===&lt;br /&gt;
[[Image:IC73826.gif|500px|center]]&lt;br /&gt;
===Sequence Diagram===&lt;br /&gt;
[[Image:CR2.gif|500px|center]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=Implementation=&lt;br /&gt;
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.  &lt;br /&gt;
&lt;br /&gt;
==Creating the instance==&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
==Accessing the instance==&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
=Examples=&lt;br /&gt;
==Java==&lt;br /&gt;
&lt;br /&gt;
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.  &lt;br /&gt;
&lt;br /&gt;
    private static final Singleton INSTANCE = new Singleton();&lt;br /&gt;
   &lt;br /&gt;
    // Private constructor prevents instantiation from other classes&lt;br /&gt;
    private Singleton() {&lt;br /&gt;
    }&lt;br /&gt;
&lt;br /&gt;
    public static Singleton getInstance() {&lt;br /&gt;
        return INSTANCE;&lt;br /&gt;
    }&lt;br /&gt;
&lt;br /&gt;
==Ruby==&lt;br /&gt;
&lt;br /&gt;
Ruby implements the Singleton pattern by privatizing the &amp;quot;new&amp;quot; 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.  &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
  include Singleton&lt;br /&gt;
&lt;br /&gt;
==C++==&lt;br /&gt;
&lt;br /&gt;
// Declaration&lt;br /&gt;
class Singleton {&lt;br /&gt;
public: &lt;br /&gt;
    static Singleton* Instance();&lt;br /&gt;
protected: &lt;br /&gt;
    Singleton();&lt;br /&gt;
private:&lt;br /&gt;
    static Singleton* _instance;&lt;br /&gt;
}&lt;br /&gt;
&lt;br /&gt;
// Implementation &lt;br /&gt;
Singleton* Singleton::_instance = 0;&lt;br /&gt;
&lt;br /&gt;
Singleton* Singleton::Instance() {&lt;br /&gt;
    if (_instance == 0) {&lt;br /&gt;
        _instance = new Singleton;&lt;br /&gt;
    }&lt;br /&gt;
    return _instance;&lt;br /&gt;
}&lt;br /&gt;
&lt;br /&gt;
=Drawbacks=&lt;br /&gt;
&lt;br /&gt;
1) Unit tests are much harder to write when using the Singleton pattern&lt;br /&gt;
&lt;br /&gt;
2) This pattern reduces the potential for parallelism within a program since the threads must be serialized.&lt;br /&gt;
&lt;br /&gt;
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.  &lt;br /&gt;
&lt;br /&gt;
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 &amp;quot;new&amp;quot; keyword to instantiate the object.&lt;br /&gt;
&lt;br /&gt;
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.  &lt;br /&gt;
&lt;br /&gt;
=References=&lt;br /&gt;
[Wikipedia Article[http://en.wikipedia.org/wiki/Singleton_pattern#Traditional_simple_way].&lt;br /&gt;
[[http://oreilly.com/catalog/9780596007126]Design Textbook]&lt;/div&gt;</summary>
		<author><name>Mlsurrat</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2010/ch3_3f_lj&amp;diff=37892</id>
		<title>CSC/ECE 517 Fall 2010/ch3 3f lj</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2010/ch3_3f_lj&amp;diff=37892"/>
		<updated>2010-10-13T22:02:30Z</updated>

		<summary type="html">&lt;p&gt;Mlsurrat: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;'''Singleton Pattern in Static and Dynamic languages'''&lt;br /&gt;
&lt;br /&gt;
=Singleton pattern=&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
===Class Diagram===&lt;br /&gt;
[[Image:IC73826.gif|500px|center]]&lt;br /&gt;
===Sequence Diagram===&lt;br /&gt;
[[Image:CR2.gif|500px|center]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=Implementation=&lt;br /&gt;
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.  &lt;br /&gt;
&lt;br /&gt;
==Creating the instance==&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
==Accessing the instance==&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
=Examples=&lt;br /&gt;
==Java==&lt;br /&gt;
&lt;br /&gt;
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.  &lt;br /&gt;
&lt;br /&gt;
    private static final Singleton INSTANCE = new Singleton();&lt;br /&gt;
   &lt;br /&gt;
    // Private constructor prevents instantiation from other classes&lt;br /&gt;
    private Singleton() {&lt;br /&gt;
    }&lt;br /&gt;
&lt;br /&gt;
    public static Singleton getInstance() {&lt;br /&gt;
        return INSTANCE;&lt;br /&gt;
    }&lt;br /&gt;
&lt;br /&gt;
==Ruby==&lt;br /&gt;
&lt;br /&gt;
Ruby implements the Singleton pattern by privatizing the &amp;quot;new&amp;quot; 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.  &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
  include Singleton&lt;br /&gt;
&lt;br /&gt;
==C++==&lt;br /&gt;
&lt;br /&gt;
// Declaration&lt;br /&gt;
class Singleton {&lt;br /&gt;
public: &lt;br /&gt;
    static Singleton* Instance();&lt;br /&gt;
protected: &lt;br /&gt;
    Singleton();&lt;br /&gt;
private:&lt;br /&gt;
    static Singleton* _instance;&lt;br /&gt;
}&lt;br /&gt;
&lt;br /&gt;
// Implementation &lt;br /&gt;
Singleton* Singleton::_instance = 0;&lt;br /&gt;
&lt;br /&gt;
Singleton* Singleton::Instance() {&lt;br /&gt;
    if (_instance == 0) {&lt;br /&gt;
        _instance = new Singleton;&lt;br /&gt;
    }&lt;br /&gt;
    return _instance;&lt;br /&gt;
}&lt;br /&gt;
&lt;br /&gt;
=Drawbacks=&lt;br /&gt;
&lt;br /&gt;
1) Unit tests are much harder to write when using the Singleton pattern&lt;br /&gt;
&lt;br /&gt;
2) This pattern reduces the potential for parallelism within a program since the threads must be serialized.&lt;br /&gt;
&lt;br /&gt;
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.  &lt;br /&gt;
&lt;br /&gt;
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 &amp;quot;new&amp;quot; keyword to instantiate the object.&lt;br /&gt;
&lt;br /&gt;
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.  &lt;br /&gt;
&lt;br /&gt;
=References=&lt;br /&gt;
[[http://en.wikipedia.org/wiki/Singleton_pattern#Traditional_simple_way]Wikipedia Article].&lt;br /&gt;
[[http://oreilly.com/catalog/9780596007126]Design Textbook]&lt;/div&gt;</summary>
		<author><name>Mlsurrat</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2010/ch3_3f_lj&amp;diff=37891</id>
		<title>CSC/ECE 517 Fall 2010/ch3 3f lj</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2010/ch3_3f_lj&amp;diff=37891"/>
		<updated>2010-10-13T21:57:18Z</updated>

		<summary type="html">&lt;p&gt;Mlsurrat: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;'''Singleton Pattern in Static and Dynamic languages'''&lt;br /&gt;
&lt;br /&gt;
=Singleton pattern=&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
===Class Diagram===&lt;br /&gt;
[[Image:IC73826.gif|500px|center]]&lt;br /&gt;
===Sequence Diagram===&lt;br /&gt;
[[Image:CR2.gif|500px|center]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=Implementation=&lt;br /&gt;
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.  &lt;br /&gt;
&lt;br /&gt;
==Creating the instance==&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
==Accessing the instance==&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
=Examples=&lt;br /&gt;
==Java==&lt;br /&gt;
&lt;br /&gt;
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.  &lt;br /&gt;
&lt;br /&gt;
    private static final Singleton INSTANCE = new Singleton();&lt;br /&gt;
   &lt;br /&gt;
    // Private constructor prevents instantiation from other classes&lt;br /&gt;
    private Singleton() {&lt;br /&gt;
    }&lt;br /&gt;
&lt;br /&gt;
    public static Singleton getInstance() {&lt;br /&gt;
        return INSTANCE;&lt;br /&gt;
    }&lt;br /&gt;
&lt;br /&gt;
==Ruby==&lt;br /&gt;
&lt;br /&gt;
Ruby implements the Singleton pattern by privatizing the &amp;quot;new&amp;quot; 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.  &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
  include Singleton&lt;br /&gt;
&lt;br /&gt;
==C++==&lt;br /&gt;
&lt;br /&gt;
// Declaration&lt;br /&gt;
class Singleton {&lt;br /&gt;
public: &lt;br /&gt;
    static Singleton* Instance();&lt;br /&gt;
protected: &lt;br /&gt;
    Singleton();&lt;br /&gt;
private:&lt;br /&gt;
    static Singleton* _instance;&lt;br /&gt;
}&lt;br /&gt;
&lt;br /&gt;
// Implementation &lt;br /&gt;
Singleton* Singleton::_instance = 0;&lt;br /&gt;
&lt;br /&gt;
Singleton* Singleton::Instance() {&lt;br /&gt;
    if (_instance == 0) {&lt;br /&gt;
        _instance = new Singleton;&lt;br /&gt;
    }&lt;br /&gt;
    return _instance;&lt;br /&gt;
}&lt;br /&gt;
&lt;br /&gt;
=Drawbacks=&lt;br /&gt;
&lt;br /&gt;
1) Unit tests are much harder to write when using the Singleton pattern&lt;br /&gt;
&lt;br /&gt;
2) This pattern reduces the potential for parallelism within a program since the threads must be serialized.&lt;br /&gt;
&lt;br /&gt;
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.  &lt;br /&gt;
&lt;br /&gt;
=References=&lt;br /&gt;
[[http://en.wikipedia.org/wiki/Singleton_pattern#Traditional_simple_way]Wikipedia Article].&lt;br /&gt;
[[http://oreilly.com/catalog/9780596007126]Design Textbook]&lt;/div&gt;</summary>
		<author><name>Mlsurrat</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2010/ch3_3f_lj&amp;diff=37890</id>
		<title>CSC/ECE 517 Fall 2010/ch3 3f lj</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2010/ch3_3f_lj&amp;diff=37890"/>
		<updated>2010-10-13T21:27:10Z</updated>

		<summary type="html">&lt;p&gt;Mlsurrat: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;'''Singleton Pattern in Static and Dynamic languages'''&lt;br /&gt;
&lt;br /&gt;
=Singleton pattern=&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
===Class Diagram===&lt;br /&gt;
[[Image:IC73826.gif|500px|center]]&lt;br /&gt;
===Sequence Diagram===&lt;br /&gt;
[[Image:CR2.gif|500px|center]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=Implementation=&lt;br /&gt;
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.  &lt;br /&gt;
&lt;br /&gt;
==Creating the instance==&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
==Accessing the instance==&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
=Examples=&lt;br /&gt;
==Java==&lt;br /&gt;
&lt;br /&gt;
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.  &lt;br /&gt;
&lt;br /&gt;
    private static final Singleton INSTANCE = new Singleton();&lt;br /&gt;
   &lt;br /&gt;
    // Private constructor prevents instantiation from other classes&lt;br /&gt;
    private Singleton() {&lt;br /&gt;
    }&lt;br /&gt;
&lt;br /&gt;
    public static Singleton getInstance() {&lt;br /&gt;
        return INSTANCE;&lt;br /&gt;
    }&lt;br /&gt;
&lt;br /&gt;
==Ruby==&lt;br /&gt;
&lt;br /&gt;
Ruby implements the Singleton pattern by privatizing the &amp;quot;new&amp;quot; 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.  &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
  include Singleton&lt;br /&gt;
&lt;br /&gt;
==C++==&lt;br /&gt;
&lt;br /&gt;
// Declaration&lt;br /&gt;
class Singleton {&lt;br /&gt;
public: &lt;br /&gt;
    static Singleton* Instance();&lt;br /&gt;
protected: &lt;br /&gt;
    Singleton();&lt;br /&gt;
private:&lt;br /&gt;
    static Singleton* _instance;&lt;br /&gt;
}&lt;br /&gt;
&lt;br /&gt;
// Implementation &lt;br /&gt;
Singleton* Singleton::_instance = 0;&lt;br /&gt;
&lt;br /&gt;
Singleton* Singleton::Instance() {&lt;br /&gt;
    if (_instance == 0) {&lt;br /&gt;
        _instance = new Singleton;&lt;br /&gt;
    }&lt;br /&gt;
    return _instance;&lt;br /&gt;
}&lt;br /&gt;
&lt;br /&gt;
=Drawbacks=&lt;br /&gt;
&lt;br /&gt;
1) Unit tests are much harder to write when using the Singleton pattern&lt;br /&gt;
&lt;br /&gt;
2) This pattern reduces the potential for parallelism within a program since the threads must be serialized.&lt;br /&gt;
&lt;br /&gt;
=References=&lt;br /&gt;
[[http://en.wikipedia.org/wiki/Singleton_pattern#Traditional_simple_way]Wikipedia Article].&lt;br /&gt;
[[http://oreilly.com/catalog/9780596007126]Design Textbook]&lt;/div&gt;</summary>
		<author><name>Mlsurrat</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=File:IC73826.gif&amp;diff=37889</id>
		<title>File:IC73826.gif</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=File:IC73826.gif&amp;diff=37889"/>
		<updated>2010-10-13T21:26:49Z</updated>

		<summary type="html">&lt;p&gt;Mlsurrat: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&lt;/div&gt;</summary>
		<author><name>Mlsurrat</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2010/ch3_3f_lj&amp;diff=37888</id>
		<title>CSC/ECE 517 Fall 2010/ch3 3f lj</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2010/ch3_3f_lj&amp;diff=37888"/>
		<updated>2010-10-13T21:26:03Z</updated>

		<summary type="html">&lt;p&gt;Mlsurrat: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;'''Singleton Pattern in Static and Dynamic languages'''&lt;br /&gt;
&lt;br /&gt;
=Singleton pattern=&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
===Class Diagram===&lt;br /&gt;
[[Image:500px-Singleton_UML_class_diagram.svg.png|500px|center]]&lt;br /&gt;
===Sequence Diagram===&lt;br /&gt;
[[Image:CR2.gif|500px|center]]&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=Implementation=&lt;br /&gt;
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.  &lt;br /&gt;
&lt;br /&gt;
==Creating the instance==&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
==Accessing the instance==&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
=Examples=&lt;br /&gt;
==Java==&lt;br /&gt;
&lt;br /&gt;
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.  &lt;br /&gt;
&lt;br /&gt;
    private static final Singleton INSTANCE = new Singleton();&lt;br /&gt;
   &lt;br /&gt;
    // Private constructor prevents instantiation from other classes&lt;br /&gt;
    private Singleton() {&lt;br /&gt;
    }&lt;br /&gt;
&lt;br /&gt;
    public static Singleton getInstance() {&lt;br /&gt;
        return INSTANCE;&lt;br /&gt;
    }&lt;br /&gt;
&lt;br /&gt;
==Ruby==&lt;br /&gt;
&lt;br /&gt;
Ruby implements the Singleton pattern by privatizing the &amp;quot;new&amp;quot; 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.  &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
  include Singleton&lt;br /&gt;
&lt;br /&gt;
==C++==&lt;br /&gt;
&lt;br /&gt;
// Declaration&lt;br /&gt;
class Singleton {&lt;br /&gt;
public: &lt;br /&gt;
    static Singleton* Instance();&lt;br /&gt;
protected: &lt;br /&gt;
    Singleton();&lt;br /&gt;
private:&lt;br /&gt;
    static Singleton* _instance;&lt;br /&gt;
}&lt;br /&gt;
&lt;br /&gt;
// Implementation &lt;br /&gt;
Singleton* Singleton::_instance = 0;&lt;br /&gt;
&lt;br /&gt;
Singleton* Singleton::Instance() {&lt;br /&gt;
    if (_instance == 0) {&lt;br /&gt;
        _instance = new Singleton;&lt;br /&gt;
    }&lt;br /&gt;
    return _instance;&lt;br /&gt;
}&lt;br /&gt;
&lt;br /&gt;
=Drawbacks=&lt;br /&gt;
&lt;br /&gt;
1) Unit tests are much harder to write when using the Singleton pattern&lt;br /&gt;
&lt;br /&gt;
2) This pattern reduces the potential for parallelism within a program since the threads must be serialized.&lt;br /&gt;
&lt;br /&gt;
=References=&lt;br /&gt;
[[http://en.wikipedia.org/wiki/Singleton_pattern#Traditional_simple_way]Wikipedia Article].&lt;br /&gt;
[[http://oreilly.com/catalog/9780596007126]Design Textbook]&lt;/div&gt;</summary>
		<author><name>Mlsurrat</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=File:CR2.gif&amp;diff=37887</id>
		<title>File:CR2.gif</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=File:CR2.gif&amp;diff=37887"/>
		<updated>2010-10-13T21:25:48Z</updated>

		<summary type="html">&lt;p&gt;Mlsurrat: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&lt;/div&gt;</summary>
		<author><name>Mlsurrat</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2010/ch3_3f_lj&amp;diff=37886</id>
		<title>CSC/ECE 517 Fall 2010/ch3 3f lj</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2010/ch3_3f_lj&amp;diff=37886"/>
		<updated>2010-10-13T21:15:52Z</updated>

		<summary type="html">&lt;p&gt;Mlsurrat: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;'''Singleton Pattern in Static and Dynamic languages'''&lt;br /&gt;
&lt;br /&gt;
=Singleton pattern=&lt;br /&gt;
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.&lt;br /&gt;
[[Image:500px-Singleton_UML_class_diagram.svg.png|500px|center]]&lt;br /&gt;
&lt;br /&gt;
=Implementation=&lt;br /&gt;
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.  &lt;br /&gt;
&lt;br /&gt;
==Creating the instance==&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
==Accessing the instance==&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
=Examples=&lt;br /&gt;
==Java==&lt;br /&gt;
&lt;br /&gt;
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.  &lt;br /&gt;
&lt;br /&gt;
    private static final Singleton INSTANCE = new Singleton();&lt;br /&gt;
   &lt;br /&gt;
    // Private constructor prevents instantiation from other classes&lt;br /&gt;
    private Singleton() {&lt;br /&gt;
    }&lt;br /&gt;
&lt;br /&gt;
    public static Singleton getInstance() {&lt;br /&gt;
        return INSTANCE;&lt;br /&gt;
    }&lt;br /&gt;
&lt;br /&gt;
==Ruby==&lt;br /&gt;
&lt;br /&gt;
Ruby implements the Singleton pattern by privatizing the &amp;quot;new&amp;quot; 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.  &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
  include Singleton&lt;br /&gt;
&lt;br /&gt;
==C++==&lt;br /&gt;
&lt;br /&gt;
// Declaration&lt;br /&gt;
class Singleton {&lt;br /&gt;
public: &lt;br /&gt;
    static Singleton* Instance();&lt;br /&gt;
function protected: &lt;br /&gt;
    Singleton();&lt;br /&gt;
function private:&lt;br /&gt;
    static Singleton* _instance;&lt;br /&gt;
}&lt;br /&gt;
&lt;br /&gt;
// Implementation &lt;br /&gt;
Singleton* Singleton::_instance = 0;&lt;br /&gt;
&lt;br /&gt;
function Singleton* Singleton::Instance() {&lt;br /&gt;
    if (_instance == 0) {&lt;br /&gt;
        _instance = new Singleton;&lt;br /&gt;
    }&lt;br /&gt;
    return _instance;&lt;br /&gt;
}&lt;br /&gt;
&lt;br /&gt;
=Drawbacks=&lt;br /&gt;
&lt;br /&gt;
1) Unit tests are much harder to write when using the Singleton pattern&lt;br /&gt;
&lt;br /&gt;
2) This pattern reduces the potential for parallelism within a program since the threads must be serialized.&lt;br /&gt;
&lt;br /&gt;
=References=&lt;br /&gt;
[[http://en.wikipedia.org/wiki/Singleton_pattern#Traditional_simple_way]Wikipedia Article].&lt;br /&gt;
[[http://oreilly.com/catalog/9780596007126]Design Textbook]&lt;/div&gt;</summary>
		<author><name>Mlsurrat</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2010/ch3_3f_lj&amp;diff=37885</id>
		<title>CSC/ECE 517 Fall 2010/ch3 3f lj</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2010/ch3_3f_lj&amp;diff=37885"/>
		<updated>2010-10-13T21:15:14Z</updated>

		<summary type="html">&lt;p&gt;Mlsurrat: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;'''Singleton Pattern in Static and Dynamic languages'''&lt;br /&gt;
&lt;br /&gt;
=Singleton pattern=&lt;br /&gt;
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.&lt;br /&gt;
[[Image:500px-Singleton_UML_class_diagram.svg.png|500px|center]]&lt;br /&gt;
&lt;br /&gt;
=Implementation=&lt;br /&gt;
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.  &lt;br /&gt;
&lt;br /&gt;
==Creating the instance==&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
==Accessing the instance==&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
=Examples=&lt;br /&gt;
==Java==&lt;br /&gt;
&lt;br /&gt;
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.  &lt;br /&gt;
&lt;br /&gt;
    private static final Singleton INSTANCE = new Singleton();&lt;br /&gt;
   &lt;br /&gt;
    // Private constructor prevents instantiation from other classes&lt;br /&gt;
    private Singleton() {&lt;br /&gt;
    }&lt;br /&gt;
&lt;br /&gt;
    public static Singleton getInstance() {&lt;br /&gt;
        return INSTANCE;&lt;br /&gt;
    }&lt;br /&gt;
&lt;br /&gt;
==Ruby==&lt;br /&gt;
&lt;br /&gt;
Ruby implements the Singleton pattern by privatizing the &amp;quot;new&amp;quot; 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.  &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
  include Singleton&lt;br /&gt;
&lt;br /&gt;
==C++==&lt;br /&gt;
&lt;br /&gt;
// Declaration&lt;br /&gt;
class Singleton {&lt;br /&gt;
public: &lt;br /&gt;
    static Singleton* Instance();&lt;br /&gt;
protected: &lt;br /&gt;
    Singleton();&lt;br /&gt;
private:&lt;br /&gt;
    static Singleton* _instance;&lt;br /&gt;
}&lt;br /&gt;
&lt;br /&gt;
// Implementation &lt;br /&gt;
Singleton* Singleton::_instance = 0;&lt;br /&gt;
&lt;br /&gt;
Singleton* Singleton::Instance() {&lt;br /&gt;
    if (_instance == 0) {&lt;br /&gt;
        _instance = new Singleton;&lt;br /&gt;
    }&lt;br /&gt;
    return _instance;&lt;br /&gt;
}&lt;br /&gt;
&lt;br /&gt;
=Drawbacks=&lt;br /&gt;
&lt;br /&gt;
1) Unit tests are much harder to write when using the Singleton pattern&lt;br /&gt;
&lt;br /&gt;
2) This pattern reduces the potential for parallelism within a program since the threads must be serialized.&lt;br /&gt;
&lt;br /&gt;
=References=&lt;br /&gt;
[[http://en.wikipedia.org/wiki/Singleton_pattern#Traditional_simple_way]Wikipedia Article].&lt;br /&gt;
[[http://oreilly.com/catalog/9780596007126]Design Textbook]&lt;/div&gt;</summary>
		<author><name>Mlsurrat</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2010/ch3_3f_lj&amp;diff=37883</id>
		<title>CSC/ECE 517 Fall 2010/ch3 3f lj</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2010/ch3_3f_lj&amp;diff=37883"/>
		<updated>2010-10-13T17:31:45Z</updated>

		<summary type="html">&lt;p&gt;Mlsurrat: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;'''Singleton Pattern in Static and Dynamic languages'''&lt;br /&gt;
&lt;br /&gt;
=Singleton pattern=&lt;br /&gt;
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.&lt;br /&gt;
[[Image:500px-Singleton_UML_class_diagram.svg.png|500px|center]]&lt;br /&gt;
&lt;br /&gt;
=Implementation=&lt;br /&gt;
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.  &lt;br /&gt;
&lt;br /&gt;
==Creating the instance==&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
==Accessing the instance==&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
=Examples=&lt;br /&gt;
==Java==&lt;br /&gt;
&lt;br /&gt;
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.  &lt;br /&gt;
&lt;br /&gt;
    private static final Singleton INSTANCE = new Singleton();&lt;br /&gt;
   &lt;br /&gt;
    // Private constructor prevents instantiation from other classes&lt;br /&gt;
    private Singleton() {&lt;br /&gt;
    }&lt;br /&gt;
&lt;br /&gt;
    public static Singleton getInstance() {&lt;br /&gt;
        return INSTANCE;&lt;br /&gt;
    }&lt;br /&gt;
&lt;br /&gt;
==Ruby==&lt;br /&gt;
&lt;br /&gt;
Ruby implements the Singleton pattern by privatizing the &amp;quot;new&amp;quot; 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.  &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
  include Singleton&lt;br /&gt;
&lt;br /&gt;
=Drawbacks=&lt;br /&gt;
&lt;br /&gt;
1) Unit tests are much harder to write when using the Singleton pattern&lt;br /&gt;
&lt;br /&gt;
2) This pattern reduces the potential for parallelism within a program since the threads must be serialized.&lt;br /&gt;
&lt;br /&gt;
=References=&lt;br /&gt;
[[http://en.wikipedia.org/wiki/Singleton_pattern#Traditional_simple_way]Wikipedia Article].&lt;br /&gt;
[[http://oreilly.com/catalog/9780596007126]Design Textbook]&lt;/div&gt;</summary>
		<author><name>Mlsurrat</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2010/ch3_3f_lj&amp;diff=37882</id>
		<title>CSC/ECE 517 Fall 2010/ch3 3f lj</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2010/ch3_3f_lj&amp;diff=37882"/>
		<updated>2010-10-13T17:20:57Z</updated>

		<summary type="html">&lt;p&gt;Mlsurrat: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;'''Singleton Pattern in Static and Dynamic languages'''&lt;br /&gt;
&lt;br /&gt;
=Singleton pattern=&lt;br /&gt;
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.&lt;br /&gt;
[[Image:500px-Singleton_UML_class_diagram.svg.png|500px|center]]&lt;br /&gt;
&lt;br /&gt;
=Implementation=&lt;br /&gt;
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.  &lt;br /&gt;
&lt;br /&gt;
==Creating the instance==&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
==Accessing the instance==&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
=Examples=&lt;br /&gt;
==Java==&lt;br /&gt;
&lt;br /&gt;
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.  &lt;br /&gt;
&lt;br /&gt;
    private static final Singleton INSTANCE = new Singleton();&lt;br /&gt;
   &lt;br /&gt;
    // Private constructor prevents instantiation from other classes&lt;br /&gt;
    private Singleton() {&lt;br /&gt;
    }&lt;br /&gt;
&lt;br /&gt;
    public static Singleton getInstance() {&lt;br /&gt;
        return INSTANCE;&lt;br /&gt;
    }&lt;br /&gt;
&lt;br /&gt;
==Ruby==&lt;br /&gt;
&lt;br /&gt;
Ruby implements the Singleton pattern by privatizing the &amp;quot;new&amp;quot; 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.  &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
  include Singleton&lt;br /&gt;
&lt;br /&gt;
=Drawbacks=&lt;br /&gt;
&lt;br /&gt;
1) Unit tests are much harder to write when using the Singleton pattern&lt;br /&gt;
&lt;br /&gt;
2) This pattern reduces the potential for parallelism within a program since the threads must be serialized.&lt;br /&gt;
&lt;br /&gt;
=References=&lt;br /&gt;
[[http://en.wikipedia.org/wiki/Singleton_pattern#Traditional_simple_way]Wikipedia Article]&lt;br /&gt;
[[http://oreilly.com/catalog/9780596007126]Design Textbook]&lt;/div&gt;</summary>
		<author><name>Mlsurrat</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2010/ch1_S10_ms&amp;diff=37881</id>
		<title>CSC/ECE 517 Fall 2010/ch1 S10 ms</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2010/ch1_S10_ms&amp;diff=37881"/>
		<updated>2010-10-13T17:07:44Z</updated>

		<summary type="html">&lt;p&gt;Mlsurrat: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;*[[CSC/ECE 517 Fall 2010/ch1 1a vc]]&lt;br /&gt;
&lt;br /&gt;
*[[CSC/ECE 517 Fall 2010/ch1 1a br]]&lt;br /&gt;
&lt;br /&gt;
*[[CSC/ECE 517 Fall 2010/ch1 1b mg]]&lt;br /&gt;
&lt;br /&gt;
*[[CSC/ECE 517 Fall 2010/ch1 1c JF]]&lt;br /&gt;
&lt;br /&gt;
*[[CSC/ECE 517 Fall 2010/ch1 1e az]]&lt;br /&gt;
&lt;br /&gt;
*[[CSC/ECE 517 Fall 2010/ch1 1e bb]]&lt;br /&gt;
&lt;br /&gt;
*[[CSC/ECE 517 Fall 2010/ch1 1f vn]]&lt;br /&gt;
&lt;br /&gt;
*[[CSC/ECE 517 Fall 2010/ch1 25 ag]]&lt;br /&gt;
&lt;br /&gt;
*[[CSC/ECE 517 Fall 2010/ch2 2b dg]]&lt;br /&gt;
&lt;br /&gt;
*[[CSC/ECE 517 Fall 2010/ch1 2e RI]]&lt;br /&gt;
&lt;br /&gt;
*[[CSC/ECE 517 Fall 2010/ch1 S6 aa]]&lt;br /&gt;
&lt;br /&gt;
*[[CSC/ECE 517 Fall 2010/ch1 S6 km]]&lt;br /&gt;
&lt;br /&gt;
*[[CSC/ECE 517 Fall 2010/ch1 S10 GP]]&lt;br /&gt;
&lt;br /&gt;
*[[CSC/ECE 517 Fall 2010/ch1 S10 MS]]&lt;br /&gt;
&lt;br /&gt;
*[[CSC/ECE 517 Fall 2010/ch1 S10 MM]]&lt;br /&gt;
&lt;br /&gt;
*[[CSC/ECE 517 Fall 2010/ch1 S10 PH]]&lt;br /&gt;
&lt;br /&gt;
*[[CSC/ECE 517 Fall 2010/ch2 2a CB]]&lt;br /&gt;
&lt;br /&gt;
*[[CSC/ECE 517 Fall 2010/ch2 2a mw]]&lt;br /&gt;
&lt;br /&gt;
*[[CSC/ECE 517 Fall 2010/ch2 2c ck]]&lt;br /&gt;
&lt;br /&gt;
*[[CSC/ECE 517 Fall 2010/ch2 S23 GP]]&lt;br /&gt;
&lt;br /&gt;
*[[CSC/ECE 517 Fall 2010/ch2 S24 NS]]&lt;br /&gt;
&lt;br /&gt;
*[[CSC/ECE 517 Fall 2010/ch2 S23 SS]]&lt;br /&gt;
&lt;br /&gt;
*[[CSC/ECE 517 Fall 2010/ch2 S23 NR]]&lt;br /&gt;
&lt;br /&gt;
*[[CSC/ECE 517 Fall 2010/ch2 S20 TT]]&lt;br /&gt;
&lt;br /&gt;
*[[CSC/ECE 517 Fall 2010/ch2 2d AS]]&lt;br /&gt;
&lt;br /&gt;
*[[CSC/ECE 517 Fall 2010/ch3 3j KS]]&lt;br /&gt;
&lt;br /&gt;
*[[CSC/ECE 517 Fall 2010/ch2 S24 rm]]&lt;br /&gt;
&lt;br /&gt;
*[[CSC/ECE 517 Fall 2010/ch3 3h PW]]&lt;br /&gt;
&lt;br /&gt;
*[[CSC/ECE 517 Fall 2010/ch3 3e br]]&lt;br /&gt;
&lt;br /&gt;
*[[CSC/ECE 517 Fall 2010/ch3 3h az]]&lt;br /&gt;
&lt;br /&gt;
*[[CSC/ECE 517 Fall 2010/ch3 3i MM]]&lt;br /&gt;
&lt;br /&gt;
*[[CSC/ECE 517 Fall 2010/ch3 3a SN]]&lt;br /&gt;
&lt;br /&gt;
*[[CSC/ECE 517 Fall 2010/ch3 S30 SK]]&lt;br /&gt;
&lt;br /&gt;
*[[CSC/ECE 517 Fall 2010/ch3 3f lj]]&lt;br /&gt;
&lt;br /&gt;
*[[CSC/ECE 517 Fall 2010/ch3 3b ka]]&lt;br /&gt;
&lt;br /&gt;
*[[CSC/ECE 517 Fall 2010/ch4 4h am]]&lt;/div&gt;</summary>
		<author><name>Mlsurrat</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2010/ch3_3f_lj&amp;diff=36998</id>
		<title>CSC/ECE 517 Fall 2010/ch3 3f lj</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2010/ch3_3f_lj&amp;diff=36998"/>
		<updated>2010-10-06T05:34:29Z</updated>

		<summary type="html">&lt;p&gt;Mlsurrat: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;'''Singleton Pattern in Static and Dynamic languages'''&lt;br /&gt;
&lt;br /&gt;
=Singleton pattern=&lt;br /&gt;
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.&lt;br /&gt;
[[Image:500px-Singleton_UML_class_diagram.svg.png|500px|center]]&lt;br /&gt;
&lt;br /&gt;
=Implementation=&lt;br /&gt;
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.  &lt;br /&gt;
&lt;br /&gt;
==Creating the instance==&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
==Accessing the instance==&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
=Examples=&lt;br /&gt;
==Java==&lt;br /&gt;
&lt;br /&gt;
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.  &lt;br /&gt;
&lt;br /&gt;
    private static final Singleton INSTANCE = new Singleton();&lt;br /&gt;
   &lt;br /&gt;
    // Private constructor prevents instantiation from other classes&lt;br /&gt;
    private Singleton() {&lt;br /&gt;
    }&lt;br /&gt;
&lt;br /&gt;
    public static Singleton getInstance() {&lt;br /&gt;
        return INSTANCE;&lt;br /&gt;
    }&lt;br /&gt;
&lt;br /&gt;
==Ruby==&lt;br /&gt;
&lt;br /&gt;
Ruby implements the Singleton pattern by privatizing the &amp;quot;new&amp;quot; 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.  &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
  include Singleton&lt;br /&gt;
&lt;br /&gt;
=Drawbacks=&lt;br /&gt;
&lt;br /&gt;
1) Unit tests are much harder to write when using the Singleton pattern&lt;br /&gt;
&lt;br /&gt;
2) This pattern reduces the potential for parallelism within a program since the threads must be serialized.&lt;br /&gt;
&lt;br /&gt;
=References=&lt;br /&gt;
[[http://en.wikipedia.org/wiki/Singleton_pattern#Traditional_simple_way]Wikipedia Article]&lt;br /&gt;
http://oreilly.com/catalog/9780596007126&lt;/div&gt;</summary>
		<author><name>Mlsurrat</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2010/ch3_3f_lj&amp;diff=36995</id>
		<title>CSC/ECE 517 Fall 2010/ch3 3f lj</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2010/ch3_3f_lj&amp;diff=36995"/>
		<updated>2010-10-06T05:28:49Z</updated>

		<summary type="html">&lt;p&gt;Mlsurrat: /* References */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;'''Singleton Pattern in Static and Dynamic languages'''&lt;br /&gt;
&lt;br /&gt;
=Singleton pattern=&lt;br /&gt;
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.&lt;br /&gt;
[[Image:500px-Singleton_UML_class_diagram.svg.png|500px|center]]&lt;br /&gt;
&lt;br /&gt;
=Implementation=&lt;br /&gt;
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.  &lt;br /&gt;
&lt;br /&gt;
==Creating the instance==&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
==Accessing the instance==&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
=Examples=&lt;br /&gt;
==Java==&lt;br /&gt;
&lt;br /&gt;
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.  &lt;br /&gt;
&lt;br /&gt;
    private static final Singleton INSTANCE = new Singleton();&lt;br /&gt;
   &lt;br /&gt;
    // Private constructor prevents instantiation from other classes&lt;br /&gt;
    private Singleton() {&lt;br /&gt;
    }&lt;br /&gt;
&lt;br /&gt;
    public static Singleton getInstance() {&lt;br /&gt;
        return INSTANCE;&lt;br /&gt;
    }&lt;br /&gt;
&lt;br /&gt;
==Ruby==&lt;br /&gt;
&lt;br /&gt;
Ruby implements the Singleton pattern by privatizing the &amp;quot;new&amp;quot; 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.  &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
  include Singleton&lt;br /&gt;
&lt;br /&gt;
=References=&lt;br /&gt;
[[http://en.wikipedia.org/wiki/Singleton_pattern#Traditional_simple_way]Wikipedia Article]&lt;/div&gt;</summary>
		<author><name>Mlsurrat</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2010/ch3_3f_lj&amp;diff=36994</id>
		<title>CSC/ECE 517 Fall 2010/ch3 3f lj</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2010/ch3_3f_lj&amp;diff=36994"/>
		<updated>2010-10-06T05:28:18Z</updated>

		<summary type="html">&lt;p&gt;Mlsurrat: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;'''Singleton Pattern in Static and Dynamic languages'''&lt;br /&gt;
&lt;br /&gt;
=Singleton pattern=&lt;br /&gt;
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.&lt;br /&gt;
[[Image:500px-Singleton_UML_class_diagram.svg.png|500px|center]]&lt;br /&gt;
&lt;br /&gt;
=Implementation=&lt;br /&gt;
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.  &lt;br /&gt;
&lt;br /&gt;
==Creating the instance==&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
==Accessing the instance==&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
=Examples=&lt;br /&gt;
==Java==&lt;br /&gt;
&lt;br /&gt;
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.  &lt;br /&gt;
&lt;br /&gt;
    private static final Singleton INSTANCE = new Singleton();&lt;br /&gt;
   &lt;br /&gt;
    // Private constructor prevents instantiation from other classes&lt;br /&gt;
    private Singleton() {&lt;br /&gt;
    }&lt;br /&gt;
&lt;br /&gt;
    public static Singleton getInstance() {&lt;br /&gt;
        return INSTANCE;&lt;br /&gt;
    }&lt;br /&gt;
&lt;br /&gt;
==Ruby==&lt;br /&gt;
&lt;br /&gt;
Ruby implements the Singleton pattern by privatizing the &amp;quot;new&amp;quot; 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.  &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
  include Singleton&lt;br /&gt;
&lt;br /&gt;
=References=&lt;br /&gt;
[[http://en.wikipedia.org/wiki/Singleton_pattern#Traditional_simple_way]]&lt;/div&gt;</summary>
		<author><name>Mlsurrat</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2010/ch3_3f_lj&amp;diff=36993</id>
		<title>CSC/ECE 517 Fall 2010/ch3 3f lj</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2010/ch3_3f_lj&amp;diff=36993"/>
		<updated>2010-10-06T05:26:32Z</updated>

		<summary type="html">&lt;p&gt;Mlsurrat: /* Singleton pattern */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;'''Singleton Pattern in Static and Dynamic languages'''&lt;br /&gt;
&lt;br /&gt;
=Singleton pattern=&lt;br /&gt;
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.&lt;br /&gt;
[[Image:500px-Singleton_UML_class_diagram.svg.png|500px|center]]&lt;br /&gt;
&lt;br /&gt;
=Implementation=&lt;br /&gt;
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.  &lt;br /&gt;
&lt;br /&gt;
==Creating the instance==&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
==Accessing the instance==&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
=Examples=&lt;br /&gt;
==Java==&lt;br /&gt;
&lt;br /&gt;
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.  &lt;br /&gt;
&lt;br /&gt;
    private static final Singleton INSTANCE = new Singleton();&lt;br /&gt;
   &lt;br /&gt;
    // Private constructor prevents instantiation from other classes&lt;br /&gt;
    private Singleton() {&lt;br /&gt;
    }&lt;br /&gt;
&lt;br /&gt;
    public static Singleton getInstance() {&lt;br /&gt;
        return INSTANCE;&lt;br /&gt;
    }&lt;br /&gt;
&lt;br /&gt;
==Ruby==&lt;br /&gt;
&lt;br /&gt;
Ruby implements the Singleton pattern by privatizing the &amp;quot;new&amp;quot; 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.  &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
  include Singleton&lt;/div&gt;</summary>
		<author><name>Mlsurrat</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2010/ch3_3f_lj&amp;diff=36992</id>
		<title>CSC/ECE 517 Fall 2010/ch3 3f lj</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2010/ch3_3f_lj&amp;diff=36992"/>
		<updated>2010-10-06T05:25:49Z</updated>

		<summary type="html">&lt;p&gt;Mlsurrat: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;'''Singleton Pattern in Static and Dynamic languages'''&lt;br /&gt;
&lt;br /&gt;
=Singleton pattern=&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
[[Image:500px-Singleton_UML_class_diagram.svg.png|500px|center]]&lt;br /&gt;
&lt;br /&gt;
=Implementation=&lt;br /&gt;
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.  &lt;br /&gt;
&lt;br /&gt;
==Creating the instance==&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
==Accessing the instance==&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
=Examples=&lt;br /&gt;
==Java==&lt;br /&gt;
&lt;br /&gt;
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.  &lt;br /&gt;
&lt;br /&gt;
    private static final Singleton INSTANCE = new Singleton();&lt;br /&gt;
   &lt;br /&gt;
    // Private constructor prevents instantiation from other classes&lt;br /&gt;
    private Singleton() {&lt;br /&gt;
    }&lt;br /&gt;
&lt;br /&gt;
    public static Singleton getInstance() {&lt;br /&gt;
        return INSTANCE;&lt;br /&gt;
    }&lt;br /&gt;
&lt;br /&gt;
==Ruby==&lt;br /&gt;
&lt;br /&gt;
Ruby implements the Singleton pattern by privatizing the &amp;quot;new&amp;quot; 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.  &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
  include Singleton&lt;/div&gt;</summary>
		<author><name>Mlsurrat</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=File:500px-Singleton_UML_class_diagram.svg.png&amp;diff=36991</id>
		<title>File:500px-Singleton UML class diagram.svg.png</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=File:500px-Singleton_UML_class_diagram.svg.png&amp;diff=36991"/>
		<updated>2010-10-06T05:24:56Z</updated>

		<summary type="html">&lt;p&gt;Mlsurrat: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&lt;/div&gt;</summary>
		<author><name>Mlsurrat</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2010/ch3_3f_lj&amp;diff=36989</id>
		<title>CSC/ECE 517 Fall 2010/ch3 3f lj</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2010/ch3_3f_lj&amp;diff=36989"/>
		<updated>2010-10-06T05:23:00Z</updated>

		<summary type="html">&lt;p&gt;Mlsurrat: /* Singleton pattern */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;'''Singleton Pattern in Static and Dynamic languages'''&lt;br /&gt;
&lt;br /&gt;
=Singleton pattern=&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
[[Image:Singleton UML class diagram.svg|250px|center]]&lt;br /&gt;
&lt;br /&gt;
=Implementation=&lt;br /&gt;
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.  &lt;br /&gt;
&lt;br /&gt;
==Creating the instance==&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
==Accessing the instance==&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
=Examples=&lt;br /&gt;
==Java==&lt;br /&gt;
&lt;br /&gt;
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.  &lt;br /&gt;
&lt;br /&gt;
    private static final Singleton INSTANCE = new Singleton();&lt;br /&gt;
   &lt;br /&gt;
    // Private constructor prevents instantiation from other classes&lt;br /&gt;
    private Singleton() {&lt;br /&gt;
    }&lt;br /&gt;
&lt;br /&gt;
    public static Singleton getInstance() {&lt;br /&gt;
        return INSTANCE;&lt;br /&gt;
    }&lt;br /&gt;
&lt;br /&gt;
==Ruby==&lt;br /&gt;
&lt;br /&gt;
Ruby implements the Singleton pattern by privatizing the &amp;quot;new&amp;quot; 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.  &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
  include Singleton&lt;/div&gt;</summary>
		<author><name>Mlsurrat</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2010/ch3_3f_lj&amp;diff=36988</id>
		<title>CSC/ECE 517 Fall 2010/ch3 3f lj</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2010/ch3_3f_lj&amp;diff=36988"/>
		<updated>2010-10-06T05:22:21Z</updated>

		<summary type="html">&lt;p&gt;Mlsurrat: /* Java */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;'''Singleton Pattern in Static and Dynamic languages'''&lt;br /&gt;
&lt;br /&gt;
=Singleton pattern=&lt;br /&gt;
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.  &lt;br /&gt;
&lt;br /&gt;
=Implementation=&lt;br /&gt;
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.  &lt;br /&gt;
&lt;br /&gt;
==Creating the instance==&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
==Accessing the instance==&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
=Examples=&lt;br /&gt;
==Java==&lt;br /&gt;
&lt;br /&gt;
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.  &lt;br /&gt;
&lt;br /&gt;
    private static final Singleton INSTANCE = new Singleton();&lt;br /&gt;
   &lt;br /&gt;
    // Private constructor prevents instantiation from other classes&lt;br /&gt;
    private Singleton() {&lt;br /&gt;
    }&lt;br /&gt;
&lt;br /&gt;
    public static Singleton getInstance() {&lt;br /&gt;
        return INSTANCE;&lt;br /&gt;
    }&lt;br /&gt;
&lt;br /&gt;
==Ruby==&lt;br /&gt;
&lt;br /&gt;
Ruby implements the Singleton pattern by privatizing the &amp;quot;new&amp;quot; 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.  &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
  include Singleton&lt;/div&gt;</summary>
		<author><name>Mlsurrat</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2010/ch3_3f_lj&amp;diff=36986</id>
		<title>CSC/ECE 517 Fall 2010/ch3 3f lj</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2010/ch3_3f_lj&amp;diff=36986"/>
		<updated>2010-10-06T05:21:15Z</updated>

		<summary type="html">&lt;p&gt;Mlsurrat: /* Accessing the instance */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;'''Singleton Pattern in Static and Dynamic languages'''&lt;br /&gt;
&lt;br /&gt;
=Singleton pattern=&lt;br /&gt;
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.  &lt;br /&gt;
&lt;br /&gt;
=Implementation=&lt;br /&gt;
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.  &lt;br /&gt;
&lt;br /&gt;
==Creating the instance==&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
==Accessing the instance==&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
=Examples=&lt;br /&gt;
==Java==&lt;br /&gt;
&lt;br /&gt;
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.  &lt;br /&gt;
&lt;br /&gt;
    private static final Singleton INSTANCE = new Singleton();&lt;br /&gt;
   &lt;br /&gt;
    // Private constructor prevents instantiation from other classes&lt;br /&gt;
    private Singleton() {&lt;br /&gt;
    }&lt;br /&gt;
&lt;br /&gt;
    public static Singleton getInstance() {&lt;br /&gt;
        return INSTANCE;&lt;br /&gt;
    }&lt;br /&gt;
&lt;br /&gt;
==Ruby==&lt;br /&gt;
&lt;br /&gt;
Ruby implements the Singleton pattern by privatizing the &amp;quot;new&amp;quot; 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.  &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
  include Singleton&lt;/div&gt;</summary>
		<author><name>Mlsurrat</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2010/ch3_3f_lj&amp;diff=36982</id>
		<title>CSC/ECE 517 Fall 2010/ch3 3f lj</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2010/ch3_3f_lj&amp;diff=36982"/>
		<updated>2010-10-06T05:14:40Z</updated>

		<summary type="html">&lt;p&gt;Mlsurrat: /* Accessing the instance */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;'''Singleton Pattern in Static and Dynamic languages'''&lt;br /&gt;
&lt;br /&gt;
=Singleton pattern=&lt;br /&gt;
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.  &lt;br /&gt;
&lt;br /&gt;
=Implementation=&lt;br /&gt;
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.  &lt;br /&gt;
&lt;br /&gt;
==Creating the instance==&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
==Accessing the instance==&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
=Examples=&lt;br /&gt;
==Java==&lt;br /&gt;
&lt;br /&gt;
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.  &lt;br /&gt;
&lt;br /&gt;
    private static final Singleton INSTANCE = new Singleton();&lt;br /&gt;
   &lt;br /&gt;
    // Private constructor prevents instantiation from other classes&lt;br /&gt;
    private Singleton() {&lt;br /&gt;
    }&lt;br /&gt;
&lt;br /&gt;
    public static Singleton getInstance() {&lt;br /&gt;
        return INSTANCE;&lt;br /&gt;
    }&lt;br /&gt;
&lt;br /&gt;
==Ruby==&lt;br /&gt;
&lt;br /&gt;
Ruby implements the Singleton pattern by privatizing the &amp;quot;new&amp;quot; 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.  &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
  include Singleton&lt;/div&gt;</summary>
		<author><name>Mlsurrat</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2010/ch3_3f_lj&amp;diff=36980</id>
		<title>CSC/ECE 517 Fall 2010/ch3 3f lj</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2010/ch3_3f_lj&amp;diff=36980"/>
		<updated>2010-10-06T05:09:09Z</updated>

		<summary type="html">&lt;p&gt;Mlsurrat: /* Ruby */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;'''Singleton Pattern in Static and Dynamic languages'''&lt;br /&gt;
&lt;br /&gt;
=Singleton pattern=&lt;br /&gt;
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.  &lt;br /&gt;
&lt;br /&gt;
=Implementation=&lt;br /&gt;
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.  &lt;br /&gt;
&lt;br /&gt;
==Creating the instance==&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
==Accessing the instance==&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=Examples=&lt;br /&gt;
==Java==&lt;br /&gt;
&lt;br /&gt;
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.  &lt;br /&gt;
&lt;br /&gt;
    private static final Singleton INSTANCE = new Singleton();&lt;br /&gt;
   &lt;br /&gt;
    // Private constructor prevents instantiation from other classes&lt;br /&gt;
    private Singleton() {&lt;br /&gt;
    }&lt;br /&gt;
&lt;br /&gt;
    public static Singleton getInstance() {&lt;br /&gt;
        return INSTANCE;&lt;br /&gt;
    }&lt;br /&gt;
&lt;br /&gt;
==Ruby==&lt;br /&gt;
&lt;br /&gt;
Ruby implements the Singleton pattern by privatizing the &amp;quot;new&amp;quot; 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.  &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
  include Singleton&lt;/div&gt;</summary>
		<author><name>Mlsurrat</name></author>
	</entry>
	<entry>
		<id>https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2010/ch3_3f_lj&amp;diff=36979</id>
		<title>CSC/ECE 517 Fall 2010/ch3 3f lj</title>
		<link rel="alternate" type="text/html" href="https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2010/ch3_3f_lj&amp;diff=36979"/>
		<updated>2010-10-06T05:08:32Z</updated>

		<summary type="html">&lt;p&gt;Mlsurrat: /* Ruby */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;'''Singleton Pattern in Static and Dynamic languages'''&lt;br /&gt;
&lt;br /&gt;
=Singleton pattern=&lt;br /&gt;
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.  &lt;br /&gt;
&lt;br /&gt;
=Implementation=&lt;br /&gt;
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.  &lt;br /&gt;
&lt;br /&gt;
==Creating the instance==&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
==Accessing the instance==&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
=Examples=&lt;br /&gt;
==Java==&lt;br /&gt;
&lt;br /&gt;
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.  &lt;br /&gt;
&lt;br /&gt;
    private static final Singleton INSTANCE = new Singleton();&lt;br /&gt;
   &lt;br /&gt;
    // Private constructor prevents instantiation from other classes&lt;br /&gt;
    private Singleton() {&lt;br /&gt;
    }&lt;br /&gt;
&lt;br /&gt;
    public static Singleton getInstance() {&lt;br /&gt;
        return INSTANCE;&lt;br /&gt;
    }&lt;br /&gt;
&lt;br /&gt;
==Ruby==&lt;br /&gt;
&lt;br /&gt;
Ruby implements the Singleton pattern by privatizing the &amp;quot;new&amp;quot; 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.  &lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
class NewClass&lt;br /&gt;
  include Singleton&lt;br /&gt;
end&lt;/div&gt;</summary>
		<author><name>Mlsurrat</name></author>
	</entry>
</feed>