Differences

This shows you the differences between two versions of the page.

--- software_that_has_the_quality_without_a_name [2014/05/16 07:37] – [Comments] yann
+++ software_that_has_the_quality_without_a_name [2025/01/15 21:40] (current) – external edit 127.0.0.1
@@ Line 30: / Line 30: @@
   * 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.
+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.