design pattern Comparison Table

Object Oriented Software Engineering View all facts Glossary Help

Next pattern: multiplicity pattern Up: pattern Previous pattern: architectural pattern

design pattern comparison table

Subject is part of is a kind of is a subtopic of have example have antipatterns is an instance of have problem have context use has definition have related patterns have solution have forces have references

abstraction-occurrence 6.2 - The Abstraction-Occurrence Pattern
using a single class
creating a separate abstraction subclass for each occurrence
making the abstraction class a superclass of the occurrence class
design pattern What is the best way to represent sets of occurrences in a class diagram? class diagrams that form part of a system domain model A pattern in which two classes are related by an association, and one of the classes represents an abstraction of the other Abstraction-Occurrence Square pattern if the abstraction is an aggregate (and the occurrences are also aggregates)
Create an ŤAbstractionť class that contains the data that is common to all the members of a set of occurrences.
Then create an ŤOccurrenceť class representing the occurrences of this abstraction.
Connect these classes with a one-to-many association
You want to represent the members of each set of occurrences without duplicating the common information
You want a solution that maximizes the flexibility of the system
a generalization of the Title-Item pattern of Eriksson and Penker

adapter 6.8 - The Adapter Pattern zero or more antipatterns - solutions that are inferior or do not work in this context with the reason for their rejection design pattern How do you obtain the power of polymorphism when reusing a class whose methods have the same function but do not have the same signature as the other methods in the hierarchy?
You are building an inheritance hierarchy and you want to incorporate into it a class written by somebody else - i.e. you want to reuse an existing class.
Typically the methods of the reused class do not have the same name or argument types as the methods in the hierarchy you are creating.
The reused class is also often already part of its own inheritance hierarchy.
A pattern found in class diagrams in which you are able to reuse an 'adaptee' class by providing a class, (the adapter) that delegates to the adaptee facade, read-only interface, proxy
Rather than directly incorporating the reused class into your inheritance hierarchy, instead incorporate an ŤAdapterť class.
The ŤAdapterťis connected by an association to the reused class, which we will call the ŤAdapteeť.
The polymorphic methods of the ŤAdapterť delegate to methods of the ŤAdapteeť.
The delegate method in the ŤAdapteeť may or may not have the same name as the delegating polymorphic method.
You do not have access to multiple inheritance or you do not want to use it. one of the Gang of Four patterns.

antipattern design pattern design pattern 6.1 - Introduction to Patterns zero or more antipatterns - solutions that are inferior or do not work in this context with the reason for their rejection a sentence or two explaining the main difficulty being tackled a context A solution to a design problem that is inferior or does not work in this context zero or more related design patterns one or more forces one or more references which indicate who developed or inspired a pattern

composite 6.3 - The General Hierarchy Pattern zero or more antipatterns - solutions that are inferior or do not work in this context with the reason for their rejection design pattern a sentence or two explaining the main difficulty being tackled a context A specialization of the general hierarchy pattern, that uses an aggregation instead of an ordinary association zero or more related design patterns one or more forces one or more references which indicate who developed or inspired a pattern

delegation 6.7 - The Delegation Pattern
Overusing generalization and inheriting the method that is to be reused
Instead of creating a single method in the ŤDelegatorť that does nothing other than call a method in the ŤDelegateť, you might consider having many different methods in the ŤDelegatorť call the delegate's method? It would be better to ensure that only one method in the ŤDelegatorť calls the method in the ŤDelegateť. If many methods access the method in the ŤDelegateť, then when it changes, you may have to change every method that accesses it
a method must only accesses neighbouring classes
design pattern How can you most effectively make use of a method that already exists in the other class?
You need an operation in a class and you realize that another class has an implementation of the operation.
However, inheritance is not appropriate, either because the isa rule does not apply, or because you do not want to reuse all the methods of the other class
A pattern in which one procedure does nothing more than call another in a neighbouring class; this reduces total coupling in the system Adapter and Proxy patterns
Create a method in the ŤDelegatorť class that does only one thing: it calls a method in a neighbouring ŤDelegateť class, allowing reuse of the method for which the ŤDelegateť has responsibility
By 'neighbouring', we mean the ŤDelegateť is connected to the ŤDelegatorť by an association.
Normally, in order to use delegation an association should already exist between the ŤDelegatorť and the ŤDelegateť.
This association needs only to be unidirectional from ŤDelegatorť to ŤDelegateť.
However it may sometimes be appropriate to create a new association just so you can use delegation - provided this does not increase the overall complexity of the system.
You want to minimize development cost and complexity by reusing methods
You want to reduce the linkages between classes
You want to ensure that work is done in the most appropriate class
one or more references which indicate who developed or inspired a pattern

facade 6.9 - The Facade Pattern zero or more antipatterns - solutions that are inferior or do not work in this context with the reason for their rejection design pattern How do you simplify the view that programmers have of a complex package? html>
Often, an application contains several complex packages.
A programmer working with such packages has to manipulate many different classes
A pattern in which you create a class that provides a simplified interface to a package zero or more related design patterns
Create a special class, called a ŤFacadeť, which will simplify the use of the package.
The ŤFacadeť will contain a simplified set of public methods such that most other subsystems do not need to access the other classes in the package.
The net result is that the package as a whole is easier to use and has a reduced number of dependencies with other packages.
Any change made to the package should only necessitate a redesign of the ŤFacadeťclass.
html>
It is hard for a programmer to understand and use an entire subsystem - in particular, to determine which methods are public.
If several different application classes call methods of the complex package, then any modifications made to the package will necessitate a complete review of all these classes.
one of the Gang of Four patterns.

general hierarchy 6.3 - The General Hierarchy Pattern modelling a hierarchy of categories using a hierarchy of classes design pattern How do you draw a class diagram to represent a hierarchy of objects, in which some objects cannot have subordinates? many class diagrams where you often find a set of objects that have a naturally hierarchical relationship. A pattern in which two classes are related both by a generalization and by a one to many association, such that the generated graph of instances forms a hierarchy the Reflexive Association pattern, the Composite pattern (a specialization of the General Hierarchy pattern)
Create an abstract ŤNodeť class to represent the features possessed by each object in the hierarchy.
Then create at least two subclasses of the ŤNodeť class.
One of the subclasses, ŤSuperiorNodeť, must be linked by a Ťsubordinatesť association to the superclass; whereas at least one subclass, ŤNonSuperiorNodeť, must not be.
The subordinates of a ŤSuperiorNodeť can thus be instances of either ŤSuperiorNodeť or ŤNonSuperiorNodeť.
You want a flexible way of representing the hierarchy that naturally prevents certain objects from having subordinates
You also have to account for the fact that all the objects share common properties and operations
one or more references which indicate who developed or inspired a pattern

immutable 6.10 - The Immutable Pattern zero or more antipatterns - solutions that are inferior or do not work in this context with the reason for their rejection design pattern How do you create a class whose instances are immutable?
An immutable object is an object which has a state that never changes after creation.
An important reason for using an immutable object is that other objects can trust its content to not unexpectedly change.
A pattern in which the instances of a class cannot change state after creation Read-Only Interface pattern provides the same capability as immutable, except that certain privileged classes are allowed to make changes to instances.
Ensure that the constructor of the immutable class is the only place where the values of instance variables are set or modified.
If a method that would otherwise modify an instance variable must be present, then it has to return a new instance of the class.
html>
The immutability must be enforced.
There must be no loopholes that would allow 'illegal' modification of an immutable object.
one or more references which indicate who developed or inspired a pattern

observer 6.6 - The Observer Pattern
connecting an observer directly to an observable so that they both have references to each other
making the observers subclasses of the observable
design pattern How do you reduce the interconnection between classes, especially between classes that belong to different modules or subsystems?
When you create a two-way association between two classes, the code for the classes becomes inseparable
When you compile one, the other one has to be available since the first one explicitly refers to it
This means if you want to reuse one of the classes, you also have to reuse the other; similarly, if you change one, you probably have to change the other
to separate the model^2 from the controller in the Model-View-Controller architecture A pattern found in class diagrams in which instances of one class are informed of changes to instances of a second class zero or more related design patterns
Create an abstract class ŤObservableť that maintains a collection of ŤObserverť instances.
The ŤObservableť class is very simple; it merely has a mechanism to add and remove observers, as well as a method notifyObservers that sends an update message to each ŤObserverť.
Any application classes can declare itself to be a subclass of ŤObservableť.
ŤObserverť is an interface, defining only an abstract update method.
Any class can thus be made to observe an Observable by declaring that it implements the interface, and asking to be a member of the observer list of the ŤObservableť.
The ŤObserverť can then expect calls to its update method whenever the ŤObservableť changes.
Using this pattern, the ŤObservableť neither has to know the nature of the classes that will be interested in receiving the update messages, nor what they will do with this information.
You want to maximize the flexibility of the system to the greatest extent possible.
one of the Gang of Four patterns.

player-role 6.4 - The Player-Role Pattern merging all the properties and behaviours into the Player class which however, creates an overly complex class - much of the power of object orientation is lost design pattern How do you best model players and roles so that a player can change roles or possess multiple roles?
A role is a particular set of properties associated with an object in a particular context.
An object may play different roles in different contexts.
A pattern in found in class diagrams in which one class (the player) has several associated role classes. Instances of the role classes can change over the lifetime of a player Abstraction-Occurrence pattern
Create a ŤPlayerť class to represent the object that plays different roles.
Create an association from this class to an abstract ŤRoleť class, which is the superclass of a set of possible roles.
The subclasses of this ŤRoleť class encapsulate all the properties and behaviours associated with the different roles.
If the ŤPlayerť can only play one role at a time, the multiplicity between ŤPlayerť and ŤRoleť can be one-to-one, otherwise it will be one-to-many.
it is desirable to improve encapsulation by capturing the information associated with each separate role in a class but you want to avoid multiple inheritance
you cannot allow an instance to change class
one or more references which indicate who developed or inspired a pattern

proxy 6.12 - The Proxy Pattern Instead of using proxy objects, beginner designers often scatter complex code around their application to load objects from databases. A strategy that only works for very small systems is to load the whole database into memory when the program starts. design pattern How can you reduce the need to create instances of a heavyweight class? In particular, how can you reduce the need to load large numbers of them from a database or server, when not all of them will be needed? A related problem is this: If you load one object from a database or server, how can you avoid loading all the other objects that are linked to it.
There may be a time-delay and a complex mechanism involved in creating instances of heavyweight classes.
A pattern found in which a lightweight object stands in place of a heavyweight object that has the same interface. It transparently loads the heavyweight object when needed several patterns that obtain their power from delegating responsibilities to other classes, hence it uses the Delegation pattern
Create a simpler version of the ŤHeavyWeightť class.
We will call this simpler version a ŤProxyť.
The ŤProxyť has the same interface as the ŤHeavyWeightť, so programmers can declare variables without caring whether a ŤProxyť or its ŤHeavyWeightť version will be put in the variable.
You want all the objects in a domain model to be available for programs to use when they execute a system's various responsibilities
It is important for many objects to persist from run to run of the same program
in a large system it would be impractical for all the objects to be loaded into memory whenever a program starts
It would be ideal to be able to program the application as if all the objects were located in memory
one of the Gang of Four patterns

read-only interface 6.11 - The Read-Only Interface Pattern making the read only class a subclass of the ŤMutableť class, overriding all methods that modify properties, such that they throw an exception design pattern How do you create a situation where some classes see a class as read-only (i.e. the class is immutable) whereas others are able to make modifications?
You sometimes want certain privileged classes to be able to modify attributes of objects that are otherwise immutable.
A pattern in which an interface is used to restrict which classes have privileges to call update methods of a class zero or more related design patterns
Create a ŤMutableť class as you would create any other class, except make sure it is not public; this ensures that it can be accessed only from its package.
All classes that need to modify the class, often called ŤMutatorť classes, must be put in this package.
Then create a public interface we will call the ŤReadOnlyInterfaceť, that has only the read-only operations of ŤMutableť - i.e. only operations that get its values.
The ŤMutableť class implements the ŤReadOnlyInterfaceť.
Programming languages such as Java allow you to control access by using the public, protected and private keywords.
However making access public makes it public for both reading and writing.
one or more references which indicate who developed or inspired a pattern

related pattern design pattern design pattern 6.1 - Introduction to Patterns zero or more antipatterns - solutions that are inferior or do not work in this context with the reason for their rejection a sentence or two explaining the main difficulty being tackled a context A pattern that are similar to another pattern zero or more related design patterns one or more forces one or more references which indicate who developed or inspired a pattern

singleton 6.5 - The Singleton Pattern the Company or University classes in systems that run the business of that company or university zero or more antipatterns - solutions that are inferior or do not work in this context with the reason for their rejection design pattern How do you ensure that it is never possible to create more than one instance of a singleton class?
In software systems, it is very common to find classes for which you want only one instance to exist. Such a class is called a singleton
A pattern that ensures that a certain class can have only one instance zero or more related design patterns In a singleton class, create the following:
A private class variable, often called theInstance. This stores the single instance
A public class method (static method) often called getInstance. The first time this method is called, it creates the single instance and stores it in theInstance. Subsequent calls simply return theInstance
A private constructor, which ensures that no other class will be able to create an instance of the singleton class
If you use a public constructor, you cannot offer the guarantee that no more than one instance will be created
The singleton instance must also be accessible to all classes that require it, so it must often be public
one of the Gang of Four patterns.

Subject	is part of	is a kind of	is a subtopic of	have example	have antipatterns	is an instance of	have problem	have context	use	has definition	have related patterns	have solution	have forces	have references
abstraction-occurrence			6.2 - The Abstraction-Occurrence Pattern		using a single class creating a separate abstraction subclass for each occurrence making the abstraction class a superclass of the occurrence class	design pattern	What is the best way to represent sets of occurrences in a class diagram?	class diagrams that form part of a system domain model		A pattern in which two classes are related by an association, and one of the classes represents an abstraction of the other	Abstraction-Occurrence Square pattern if the abstraction is an aggregate (and the occurrences are also aggregates)	Create an ŤAbstractionť class that contains the data that is common to all the members of a set of occurrences. Then create an ŤOccurrenceť class representing the occurrences of this abstraction. Connect these classes with a one-to-many association	You want to represent the members of each set of occurrences without duplicating the common information You want a solution that maximizes the flexibility of the system	a generalization of the Title-Item pattern of Eriksson and Penker
adapter			6.8 - The Adapter Pattern		zero or more antipatterns - solutions that are inferior or do not work in this context with the reason for their rejection	design pattern	How do you obtain the power of polymorphism when reusing a class whose methods have the same function but do not have the same signature as the other methods in the hierarchy?	You are building an inheritance hierarchy and you want to incorporate into it a class written by somebody else - i.e. you want to reuse an existing class. Typically the methods of the reused class do not have the same name or argument types as the methods in the hierarchy you are creating. The reused class is also often already part of its own inheritance hierarchy.		A pattern found in class diagrams in which you are able to reuse an 'adaptee' class by providing a class, (the adapter) that delegates to the adaptee	facade, read-only interface, proxy	Rather than directly incorporating the reused class into your inheritance hierarchy, instead incorporate an ŤAdapterť class. The ŤAdapterťis connected by an association to the reused class, which we will call the ŤAdapteeť. The polymorphic methods of the ŤAdapterť delegate to methods of the ŤAdapteeť. The delegate method in the ŤAdapteeť may or may not have the same name as the delegating polymorphic method.	You do not have access to multiple inheritance or you do not want to use it.	one of the Gang of Four patterns.
antipattern	design pattern	design pattern	6.1 - Introduction to Patterns		zero or more antipatterns - solutions that are inferior or do not work in this context with the reason for their rejection		a sentence or two explaining the main difficulty being tackled	a context		A solution to a design problem that is inferior or does not work in this context	zero or more related design patterns		one or more forces	one or more references which indicate who developed or inspired a pattern
composite			6.3 - The General Hierarchy Pattern		zero or more antipatterns - solutions that are inferior or do not work in this context with the reason for their rejection	design pattern	a sentence or two explaining the main difficulty being tackled	a context		A specialization of the general hierarchy pattern, that uses an aggregation instead of an ordinary association	zero or more related design patterns		one or more forces	one or more references which indicate who developed or inspired a pattern
delegation			6.7 - The Delegation Pattern		Overusing generalization and inheriting the method that is to be reused Instead of creating a single method in the ŤDelegatorť that does nothing other than call a method in the ŤDelegateť, you might consider having many different methods in the ŤDelegatorť call the delegate's method? It would be better to ensure that only one method in the ŤDelegatorť calls the method in the ŤDelegateť. If many methods access the method in the ŤDelegateť, then when it changes, you may have to change every method that accesses it a method must only accesses neighbouring classes	design pattern	How can you most effectively make use of a method that already exists in the other class?	You need an operation in a class and you realize that another class has an implementation of the operation. However, inheritance is not appropriate, either because the isa rule does not apply, or because you do not want to reuse all the methods of the other class		A pattern in which one procedure does nothing more than call another in a neighbouring class; this reduces total coupling in the system	Adapter and Proxy patterns	Create a method in the ŤDelegatorť class that does only one thing: it calls a method in a neighbouring ŤDelegateť class, allowing reuse of the method for which the ŤDelegateť has responsibility By 'neighbouring', we mean the ŤDelegateť is connected to the ŤDelegatorť by an association. Normally, in order to use delegation an association should already exist between the ŤDelegatorť and the ŤDelegateť. This association needs only to be unidirectional from ŤDelegatorť to ŤDelegateť. However it may sometimes be appropriate to create a new association just so you can use delegation - provided this does not increase the overall complexity of the system.	You want to minimize development cost and complexity by reusing methods You want to reduce the linkages between classes You want to ensure that work is done in the most appropriate class	one or more references which indicate who developed or inspired a pattern
facade			6.9 - The Facade Pattern		zero or more antipatterns - solutions that are inferior or do not work in this context with the reason for their rejection	design pattern	How do you simplify the view that programmers have of a complex package?	html> Often, an application contains several complex packages. A programmer working with such packages has to manipulate many different classes		A pattern in which you create a class that provides a simplified interface to a package	zero or more related design patterns	Create a special class, called a ŤFacadeť, which will simplify the use of the package. The ŤFacadeť will contain a simplified set of public methods such that most other subsystems do not need to access the other classes in the package. The net result is that the package as a whole is easier to use and has a reduced number of dependencies with other packages. Any change made to the package should only necessitate a redesign of the ŤFacadeťclass.	html> It is hard for a programmer to understand and use an entire subsystem - in particular, to determine which methods are public. If several different application classes call methods of the complex package, then any modifications made to the package will necessitate a complete review of all these classes.	one of the Gang of Four patterns.
general hierarchy			6.3 - The General Hierarchy Pattern		modelling a hierarchy of categories using a hierarchy of classes	design pattern	How do you draw a class diagram to represent a hierarchy of objects, in which some objects cannot have subordinates?	many class diagrams where you often find a set of objects that have a naturally hierarchical relationship.		A pattern in which two classes are related both by a generalization and by a one to many association, such that the generated graph of instances forms a hierarchy	the Reflexive Association pattern, the Composite pattern (a specialization of the General Hierarchy pattern)	Create an abstract ŤNodeť class to represent the features possessed by each object in the hierarchy. Then create at least two subclasses of the ŤNodeť class. One of the subclasses, ŤSuperiorNodeť, must be linked by a Ťsubordinatesť association to the superclass; whereas at least one subclass, ŤNonSuperiorNodeť, must not be. The subordinates of a ŤSuperiorNodeť can thus be instances of either ŤSuperiorNodeť or ŤNonSuperiorNodeť.	You want a flexible way of representing the hierarchy that naturally prevents certain objects from having subordinates You also have to account for the fact that all the objects share common properties and operations	one or more references which indicate who developed or inspired a pattern
immutable			6.10 - The Immutable Pattern		zero or more antipatterns - solutions that are inferior or do not work in this context with the reason for their rejection	design pattern	How do you create a class whose instances are immutable?	An immutable object is an object which has a state that never changes after creation. An important reason for using an immutable object is that other objects can trust its content to not unexpectedly change.		A pattern in which the instances of a class cannot change state after creation	Read-Only Interface pattern provides the same capability as immutable, except that certain privileged classes are allowed to make changes to instances.	Ensure that the constructor of the immutable class is the only place where the values of instance variables are set or modified. If a method that would otherwise modify an instance variable must be present, then it has to return a new instance of the class.	html> The immutability must be enforced. There must be no loopholes that would allow 'illegal' modification of an immutable object.	one or more references which indicate who developed or inspired a pattern
observer			6.6 - The Observer Pattern		connecting an observer directly to an observable so that they both have references to each other making the observers subclasses of the observable	design pattern	How do you reduce the interconnection between classes, especially between classes that belong to different modules or subsystems?	When you create a two-way association between two classes, the code for the classes becomes inseparable When you compile one, the other one has to be available since the first one explicitly refers to it This means if you want to reuse one of the classes, you also have to reuse the other; similarly, if you change one, you probably have to change the other	to separate the model^2 from the controller in the Model-View-Controller architecture	A pattern found in class diagrams in which instances of one class are informed of changes to instances of a second class	zero or more related design patterns	Create an abstract class ŤObservableť that maintains a collection of ŤObserverť instances. The ŤObservableť class is very simple; it merely has a mechanism to add and remove observers, as well as a method notifyObservers that sends an update message to each ŤObserverť. Any application classes can declare itself to be a subclass of ŤObservableť. ŤObserverť is an interface, defining only an abstract update method. Any class can thus be made to observe an Observable by declaring that it implements the interface, and asking to be a member of the observer list of the ŤObservableť. The ŤObserverť can then expect calls to its update method whenever the ŤObservableť changes. Using this pattern, the ŤObservableť neither has to know the nature of the classes that will be interested in receiving the update messages, nor what they will do with this information.	You want to maximize the flexibility of the system to the greatest extent possible.	one of the Gang of Four patterns.
player-role			6.4 - The Player-Role Pattern		merging all the properties and behaviours into the Player class which however, creates an overly complex class - much of the power of object orientation is lost	design pattern	How do you best model players and roles so that a player can change roles or possess multiple roles?	A role is a particular set of properties associated with an object in a particular context. An object may play different roles in different contexts.		A pattern in found in class diagrams in which one class (the player) has several associated role classes. Instances of the role classes can change over the lifetime of a player	Abstraction-Occurrence pattern	Create a ŤPlayerť class to represent the object that plays different roles. Create an association from this class to an abstract ŤRoleť class, which is the superclass of a set of possible roles. The subclasses of this ŤRoleť class encapsulate all the properties and behaviours associated with the different roles. If the ŤPlayerť can only play one role at a time, the multiplicity between ŤPlayerť and ŤRoleť can be one-to-one, otherwise it will be one-to-many.	it is desirable to improve encapsulation by capturing the information associated with each separate role in a class but you want to avoid multiple inheritance you cannot allow an instance to change class	one or more references which indicate who developed or inspired a pattern
proxy			6.12 - The Proxy Pattern		Instead of using proxy objects, beginner designers often scatter complex code around their application to load objects from databases. A strategy that only works for very small systems is to load the whole database into memory when the program starts.	design pattern	How can you reduce the need to create instances of a heavyweight class? In particular, how can you reduce the need to load large numbers of them from a database or server, when not all of them will be needed? A related problem is this: If you load one object from a database or server, how can you avoid loading all the other objects that are linked to it.	There may be a time-delay and a complex mechanism involved in creating instances of heavyweight classes.		A pattern found in which a lightweight object stands in place of a heavyweight object that has the same interface. It transparently loads the heavyweight object when needed	several patterns that obtain their power from delegating responsibilities to other classes, hence it uses the Delegation pattern	Create a simpler version of the ŤHeavyWeightť class. We will call this simpler version a ŤProxyť. The ŤProxyť has the same interface as the ŤHeavyWeightť, so programmers can declare variables without caring whether a ŤProxyť or its ŤHeavyWeightť version will be put in the variable.	You want all the objects in a domain model to be available for programs to use when they execute a system's various responsibilities It is important for many objects to persist from run to run of the same program in a large system it would be impractical for all the objects to be loaded into memory whenever a program starts It would be ideal to be able to program the application as if all the objects were located in memory	one of the Gang of Four patterns
read-only interface			6.11 - The Read-Only Interface Pattern		making the read only class a subclass of the ŤMutableť class, overriding all methods that modify properties, such that they throw an exception	design pattern	How do you create a situation where some classes see a class as read-only (i.e. the class is immutable) whereas others are able to make modifications?	You sometimes want certain privileged classes to be able to modify attributes of objects that are otherwise immutable.		A pattern in which an interface is used to restrict which classes have privileges to call update methods of a class	zero or more related design patterns	Create a ŤMutableť class as you would create any other class, except make sure it is not public; this ensures that it can be accessed only from its package. All classes that need to modify the class, often called ŤMutatorť classes, must be put in this package. Then create a public interface we will call the ŤReadOnlyInterfaceť, that has only the read-only operations of ŤMutableť - i.e. only operations that get its values. The ŤMutableť class implements the ŤReadOnlyInterfaceť.	Programming languages such as Java allow you to control access by using the public, protected and private keywords. However making access public makes it public for both reading and writing.	one or more references which indicate who developed or inspired a pattern
related pattern	design pattern	design pattern	6.1 - Introduction to Patterns		zero or more antipatterns - solutions that are inferior or do not work in this context with the reason for their rejection		a sentence or two explaining the main difficulty being tackled	a context		A pattern that are similar to another pattern	zero or more related design patterns		one or more forces	one or more references which indicate who developed or inspired a pattern
singleton			6.5 - The Singleton Pattern	the Company or University classes in systems that run the business of that company or university	zero or more antipatterns - solutions that are inferior or do not work in this context with the reason for their rejection	design pattern	How do you ensure that it is never possible to create more than one instance of a singleton class?	In software systems, it is very common to find classes for which you want only one instance to exist. Such a class is called a singleton		A pattern that ensures that a certain class can have only one instance	zero or more related design patterns	In a singleton class, create the following: A private class variable, often called theInstance. This stores the single instance A public class method (static method) often called getInstance. The first time this method is called, it creates the single instance and stores it in theInstance. Subsequent calls simply return theInstance A private constructor, which ensures that no other class will be able to create an instance of the singleton class	If you use a public constructor, you cannot offer the guarantee that no more than one instance will be created The singleton instance must also be accessible to all classes that require it, so it must often be public	one of the Gang of Four patterns.

Next pattern: multiplicity pattern Up: pattern Previous pattern: architectural pattern