Jump to content
Main menu
Main menu
move to sidebar
hide
Navigation
Main page
Recent changes
Random page
Help about MediaWiki
Special pages
Niidae Wiki
Search
Search
Appearance
Create account
Log in
Personal tools
Create account
Log in
Pages for logged out editors
learn more
Contributions
Talk
Editing
Pattern language
(section)
Page
Discussion
English
Read
Edit
View history
Tools
Tools
move to sidebar
hide
Actions
Read
Edit
View history
General
What links here
Related changes
Page information
Appearance
move to sidebar
hide
Warning:
You are not logged in. Your IP address will be publicly visible if you make any edits. If you
log in
or
create an account
, your edits will be attributed to your username, along with other benefits.
Anti-spam check. Do
not
fill this in!
==Design problems in a context== An important aspect of design patterns is to identify and document the key ideas that make a good system different from a poor system (that may be a house, a computer program or an object of daily use), and to assist in the design of future systems. The idea expressed in a pattern should be general enough to be applied in very different systems within its context, but still specific enough to give constructive guidance. The range of situations in which the problems and solutions addressed in a pattern apply is called its context. An important part in each pattern is to describe this context. Examples can further illustrate how the pattern applies to very different situation. For instance, Alexander's pattern "A PLACE TO WAIT" addresses bus stops in the same way as waiting rooms in a surgery, while still proposing helpful and constructive solutions. The [[Design Patterns|"Gang-of-Four" book ''Design Patterns'']] by Gamma et al. proposes solutions that are independent of the programming language, and the program's application domain. Still, the problems and solutions described in a pattern can vary in their level of abstraction and generality on the one side, and specificity on the other side. In the end this depends on the author's preferences. However, even a very abstract pattern will usually contain examples that are, by nature, absolutely concrete and specific. Patterns can also vary in how far they are proven in the real world. Alexander gives each pattern a rating by zero, one or two stars, indicating how well they are proven in real-world examples. It is generally claimed that all patterns need at least some existing real-world examples. It is, however, conceivable to document yet unimplemented ideas in a pattern-like format. The patterns in Alexander's book also vary in their level of scale β some describing how to build a town or neighbourhood, others dealing with individual buildings and the interior of rooms. Alexander sees the low-scale artifacts as constructive elements of the large-scale world, so they can be connected to a [[#Aggregation in an associative network (pattern language)|hierarchic network]]. ===Balancing of forces=== A pattern must characterize the problems that it is meant to solve, the context or situation where these problems arise, and the conditions under which the proposed solutions can be recommended. Often these problems arise from a conflict of different interests or "forces". A pattern emerges as a dialogue that will then help to balance the forces and finally make a decision. For instance, there could be a pattern suggesting a wireless telephone. The forces would be the need to communicate, and the need to get other things done at the same time (cooking, inspecting the bookshelf). A very specific pattern would be just "WIRELESS TELEPHONE". More general patterns would be "WIRELESS DEVICE" or "SECONDARY ACTIVITY", suggesting that a secondary activity (such as talking on the phone, or inspecting the pockets of your jeans) should not interfere with other activities. Though quite unspecific in its context, the forces in the "SECONDARY ACTIVITY" pattern are very similar to those in "WIRELESS TELEPHONE". Thus, the competing forces can be seen as part of the essence of a design concept expressed in a pattern. ===Patterns contain their own rationale=== Usually a pattern contains a rationale referring to some given values. For Christopher Alexander, it is most important to think about the people who will come in contact with a piece of architecture. One of his key values is making these people feel more alive. He talks about the "quality without a name" (QWAN). More generally, we could say that a good system should be accepted, welcomed and happily embraced as an enrichment of daily life by those who are meant to use it, or β even better β by all people it affects. For instance, when discussing a street cafΓ©, Alexander discusses the possible desires of a guest, but also mentions people who just walk by. The same thinking can be applied to technical devices such as telephones and cars, to social structures like a team working on a project, or to the user interface of a computer program. The qualities of a software system, for instance, could be rated by observing whether users spend their time enjoying or struggling with the system. By focusing on the impacts on human life, we can identify patterns that are independent from changing technology, and thus find "timeless quality" (Alexander).
Summary:
Please note that all contributions to Niidae Wiki may be edited, altered, or removed by other contributors. If you do not want your writing to be edited mercilessly, then do not submit it here.
You are also promising us that you wrote this yourself, or copied it from a public domain or similar free resource (see
Encyclopedia:Copyrights
for details).
Do not submit copyrighted work without permission!
Cancel
Editing help
(opens in new window)
Search
Search
Editing
Pattern language
(section)
Add topic