Hotspots: Admin Pages | Turn-in Site |
Current Links: Cases Final Project Summer 2007
Discussion 2 - Samuel Young
The Portland Form is a method of formatting a solution to a design problem. These solutions are more commonly known as design patterns when they arise or inspire similar solutions in more than one area of computing. When many design patterns congregate within a single domain of problems, a pattern language may begin to form. A pattern language is essentially an abstract set of recurring solutions to common problems in computing and design.
In the Portland Form, a common template for describing design patterns aims to help pattern languages emerge and evolve. The idea is that pattern languages can be understood in a way quite similar to the way that the human mind understands natural language. Provided this is true, people may begin to solve design problems in a way which feels natural and requires more instinct as opposed to intuitive thinking.
The Portland Form strives to link patterns together as well, also in the spirit of influencing the development of pattern languages. In order to do this, the form primarily enforces three sections of a paper submission: Language, Pattern and Summary. The Language section has actual submission guidelines for its format. This is the section that links patterns to their appropriate language. The Pattern section contains paragraphs dealing with specific design patterns. The structure of a pattern paragraph does the following:
- bulleted Having done so and so you now face this problem...
- bulleted Here is why the problem exists and what forces must be resolved...
- bulleted Make something along the following lines. I'll give you the help I can..
- bulleted Now you are ready to move on to one of the following problems...
(from About the Portland Form)
The Summary section discusses all patterns that deal with the problem at hand.
Finally, and perhaps most notably, the Portland Form is a narrative form. This is another attempt to make a pattern language feel like a natural language.
One very popular and often-used design pattern is the Singleton. A singleton is used to ensure that only one instance of class may be created. To accomplish this, the singleton contains a single reference to the only instance of its class. It contains a class method that returns a reference to this instance. Therefore, the single instance may be reference in a static/global way.
My interest in this pattern is that it is a clever way to use the mechanics of OO programming to ensure efficiency of certain tasks. For example, since the singleton is essentially global within a program, it provides an easy way to link together information. In fact, the Portland Pattern Repository entry states, "Singletons are most appropriate for services that do not change their nature based on their invocation context." It is the many semantics of OO languages that allow such a simple yet effective solution to a problem to exist.
In fact, I have used singletons before. The most notable example comes from a player management system in an online casino project. The casino's records of each player were kept as hard copies, and in order to access or make changes to the records, a singleton was used. I chose this design in order to allow multiple parts of the casino to access player records, and also to ensure synchronization of the multi-threaded server environment. In the case of this singleton, it was easy to accomplish synchronization, because the class method which returns the only instance of the player management object could be synchronized (essentially ensuring that no two parts of the casino could corrupt records).
Link to this Page