Ptidej Team WIki

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== Quintero, F. M. Software that has the Quality Without A Name. 2011 ======

===== Abstract =====

//(This article contains the author's thought and is not structured as a research paper. Hence, the following is a paragraph taken from the article but not its actual abstract; the article does not have one.)
//

So you can see the essence of design patterns: good, tested recipes that don't constrain your implementation in unnecessary ways. The patterns do not mandate a particular style, nor include superfluous decorations: the book doesn't tell you, "make this shape of flourishes in the handrails"; instead it tells you, "a house should have its rooms placed such that sunlight enters them according to the time of the day in which they are most used - East for the bedrooms in the morning, West for the living room in the afternoon".
===== Comments =====

//Yann-Gaël Guéhéneuc, 2014/05/16//

This article describes the author's progress from casual observer to expert in design patterns through learning and using real-world architectural patterns. The author start by stating that he used to dismiss refactorings and design patterns as "nothing that you could not discover yourself". Then, while renovating/expanding his house, he started studying Alexander's patterns and "became tremendously interested in [Alexander's work]". He realised that the patterns "do not mandate a particular style, nor include superfluous decorations" and they are an "approach [to] design" with "good solutions [...] that wouldn't constraint [the] implementation unnecessarily". Moreover, the patterns "give [...] a vocabulary to talk about how things are constructed".

From then on, the author introduces the idea of "Quality without a name": "[a] thing or place has the quality without a name if it is comfortable, has evolved over time in its own terms, is free of inner contradictions, doesn't try to draw attention to itself, and seems to have archetypal qualities". Things that have the quality without a name seem to have 15 properties in common, according to Alexander's work. The author summarises these 15 properties:
  * Levels of scale: There is a balanced range of sizes. You don't have abrupt changes in the sizes of adjacent things. Elements have fractal scale.
  * Strong centers: You can clearly identify parts of the space or structure.
  * Thick boundaries`: Lines delimit things. In living systems, edges are the most productive environments (e.g., all the critters that live at the edge of the water).
  * Alternating repetition: High/low, thick/thin, shape A and shape B. Things oscillate and alternate to create a good balance.
  * Positive space: Space is beautifully shaped, convex, enclosed. It is not leftover space. Think of how a Voronoi diagram has cells that grow outward from a bunch of points, or how a piece of corn has kernels that grow from tiny points until they touch the adjacent kernels.
  * Good shape: The sails of a ship, the shell of a snail, the beak of a bird. They attain the optimal shape for their purpose, which is beautiful.
  * Local symmetries: The world is not symmetrical at large. But small things tend to be symmetrical, because it is easier that way. Your house is not symmetrical, but each window is.
  * Deep interlock and ambiguity: The crooked streets of old towns. Axons in neurons. It is hard to separate figure and ground, or foreground and background. Two strong centers are made stronger if a third center is placed between them, so that it belongs to both.
  * Contrast: You can distinguish where one thing ends and the next one begins, because they don't fade into each other.
  * Gradients: Things fade into each other where they need to. Concentrations in solutions, snow or earth banks, the wires that support a bridge. The way bandwidth decreases as you move away from the backbone.
  * Roughness: The world is not frictionless and smooth. Irregularities are good because they let each piece adapt perfectly to its surroundings, rather than being an exact copy that may not fit as well.
  * Echoes: Things repeat and echo each other. Things are unique in their exact shape, but the general shapes repeat over and over.
  * The void: Sometimes you get a big blank area for quietness of form. A lake, a courtyard, a picture window.
  * Simplicity and inner calm: Things are as simple as possible, but no simpler.
  * Non-separateness: Everything depends on everything else. You can't separate a fish from the pond and the aquatic plants. You can't separate a column from the base of the building.

The author goes on with Alexander's idea of transformations, which preserve the structure of the things, as refactorings preserve the behaviour of a software program. He then gives an example by Richard Gabriel to transform a ''PhoneCall'' class to create two strong centers, then extract the latent center in the middle, and then reach a design where multi-way calls, conference calls, can happen.

The author summarises the fundamental process to apply structure-preserving transformations:
  - Start with what you have - an empty lot, or an already-built building, or a program that looks ugly and is hard to use.
  - Identify the centers that exist in that space. Find the weakest center or the least coherent.
  - See how to apply one or more of the fifteen structure-preserving transformations to strengthen that weak center. Does it need to be delimited? Does it need to be blended with its surroundings? Does it need more detail? Does it need to be de-cluttered?
  - Find the new centers that are born when you apply the transformation to the old center. Does the new combination make things stronger? Prettier? More functional?
  - Ensure that you did the simplest possible thing.
  - Go back to the beginning for the next step.

The author recalls that Alexander does not like destroying things to build new ones. Similarly, we should refactor code rather than scrap it. Also, Alexander does not like detailed, up-front design because "you cannot predict absolutely everything that will come up during construction or implementation". Instead, we must "continually evaluate what [we create] against real users and real use cases". Finally, the author concludes that "Quality without a name" is really a (mysterious) synonym to "living structure", i.e., things "that are build according to that method".

This article is interesting because it put Alexander's consequent work into perspective and summarises Alexander's main ideas and finding. It also relates real-world architecture with software design and makes a good case for reading books about refactorings and design patterns.