<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<br> Well I am overstressed and I may be coopting what I read
to tune with
<br>what I expect but let us examine this passage from Günther's PhD
<br>thesis (page 49-50)
<p>Class-based systems. Traditional class-based systems do
<br>not effectively support behaviour evolution.
<br>The class-based model cannot easily express changes
<br>in the structure or behaviour of an object. Required behaviour
<br>evolution has to be hard-coded into application programs.
<br>As seen in the previous section, manually coded behaviour
<br>evolution is a possible workaround for the limitations of the
<br>class-based model but not a satisfactory solution.
<br>The essence of various design patterns suggested in this
<br>context are more or less faithful simulations of delegation. These
<br>simulations do not achieve the full functionality of delegation (3.6.3)
<br>Because the functionality missing from the language is
<br>simulated by a set of cooperating classes, these classes
<br>tend to be tightly dependent on each other in ways that are
<br>not grounded in the application but just in the technical details of
<br>pattern. Such additional dependencies and assumptions built into
<br>the design require consistent changes in a complete hierarchy
<br>of classes even for small unanticipated changes int he application
<br>logic, e.g. addition of a method to a class of addition of a new
<br>class (see 18.104.22.168 and 3.6.3). Thus the application of design
<br>patterns for simulating BEHAVIOUR EVOLUTION CAN
<br>IMPEDE REUSE (OF EXISTING CODE AND DESIGNS)
<br>AND COMPLICATE PROGRAM MAINTENANCE, achieveing
<br>\the opposite of what is widely regarded as a main benefit of OOP.
<br>Therefore, extension of traditional class-based object models
<br>by a mechanism for unanticipated behaviour evolution is
<p>I invite Günther to throw light in this passage. But I interpreted
<br>as delegation is better than design patterns.
<p>And I put forward that both Christopher Alexander and I recognize
<br>the failure of "A pattern language" to grasp the essence of
<br>the nature of architecture and urban design. The granularity
<br>of the patterns is too coarse. The granularity of my ecodesign
<br>model is fine. I would say it will be very hard to build
<br>ecodesign model. It grasps the macro as well as the micro aspects
<br>involved in the design process. I mean it deals with modeling
<br>geoengineering and climate as well as with comfort zone and
<br>the ergonomics of the behavior of the human being.
<br>If architecture is not translated into forms it is not architecture
<br>And there is no geometric modelling in A Pattern language.
<br>My geometric modelling consists of the theory of tilings,
<br>(based on the graphical artist Maurits C. Escher , I extended
<br>the theory of tilings with the notion of prototiles, tiles of
<br>different formats - so I can reproduce through this concept
<br>exactly what an organic designer would do. I mean I can
<br>layout the behavior of the human being around the furniture and
<br>crystalize it with this concept), symmetry groups of the plane
<br>and the dotless plane. Similarity and conformal symmetry
<br>groups are fractals!!!The two most importants models to
<br>model phenomena are catastrophe theory and chaos theory
<br>(as far as I know fractals are within chaos theory context).
<br>Through the relationship of the subgroups of the crystallographic
<br>groups of the plane as well as the notion of metamorphosis
<br>so well grasped by Escher in his xylogravures I arrived at the
<br>essence of the free plan.
<p>I mean I am building a knowledge based system in a seamless
<br>process. The domain dependent model follows the geometric
<br>modeling and I hope through delegation I can achieve a
<br>computation model that is "isomorphic" to the previous two.
<p>I love Alexander's work although I have read his book only
<br>after I had finished my master's dissertation in 1988. And I
<br>was already involved with Lionel March the head of the
<br>Graduate School of Architecture and Urban Planning at UCLA.
<br>Lionel was Alexander's colleague at Cambridge.
<br>He introduced in his PHD thesis in the sixties the notion
<br>'that architects since Leonardo da Vinci have applied
<br>symmmetry groups of the plane to architecture.
<br>In this century Frank Lloyd Wright, the greatest formmaker
<br>of this century as well as Le Corbusier applied symmetry
<br>groups to their designs.
<p>However they applied the traditional notion of tilings.
<br>The outcome of their work is not a free plan, a fundamental
<br>paradigm of the Modern Movement with respect to the
<br>inner layout of an apartment.
<p>Let's feel how Alexander is:
<br>I sleep in a room that has windows in two sides. It is
<br>simply gorgeous. My house is located in a villa that
<br>was built in 1903.
<br>So let's see what Alexander writes on page 745.
<p>prepare to knit the inside of the building to the outside,
<br>by treating the edge between the two as a place in its
<br>own righ, and making human details there:
<br>159. light on two sides of every room
<br>160. building edge
<br>161. sunny place
<br>162. north face
<br>165. opening to the street
<br>167. six-foot balcony
<br>168.connection to the earth
<p>one reads on page 747
<p>...once the building's major rooms are in position, we have to fix
<br>its actual shape: and this we do essentially with the position
<br>of the edge. The edge has got its rough position already from
<br>the overall form of the building -
<br>Wings of Light (107), positivive outdoor space (106)
<br>Long Thin House (109), Cascade of roofs (116).This
<br>pattern now completes the work of Wings of Light (107),
<br>by placing each individual room exactly where it needs to
<br>be to get the light. It forms the exact line of the
<br>building edge, according to the positin of these individual
<br>rooms. The next pattern starts to shape the edge.
<br>Well The two projects I designed to illustrate my design
<br>model curiously if they don't have windows in both sides
<br>light falls from the top of the roof, so one can see the
<br>moon, the sun, the flowers with different colours all around
<p>I love windows at the corners. And I love to let light fall from
<br>I also designed a project for a small church. When I applied
<br>the formula to see if I had calculated the right amount of
<br>area necessary for daylight illumination and natural ventilation
<br>they fit the needs perfectly well.
<p>Indeed Alexander and I were anxious to work together.
<br>However Berkeley was not a center of OOP in 1990 -1992.
<br>The only interesting researcher was STephen Omohundro
<br>the author of the Sather Language, an optimization of the
<br>Eiffel language from International Computer Science
<br>Institute and so the Brazilian agencies made up their minds
<br>not to send me to Berkeley.,
<p>Lionel March and the CAD group finally recognized I was
<br>an expensive student and UCLA could not cope with my
<br>needs, not only in terms of facilities as well as human
<p>as far as I know Günther (I know him) does not claim that delegation
is better than design patterns.
<br>I reckon he says that with delegation most design patterns are easier
<p>> Kniesel in his thesis wants to show the superiority of delegation
<br>> I am still reading through his thesis and the papers I gathered and
<br>> have no conclusion.
<p>I'd be very interested in the list of papers you gathered for this topic
and maybe even your opinion on them.
<p>I am currently looking at delegation as a means to modeling as opposed
to class based modeling how it is usually done. I am be happy to share
<br>findings with you and the list but at the moment I am trying to get
a handle on prototyping, i.e., find out when you would prefer it when
<br>Dr. Thomas Kuehne
<br>0178 4314387, <A HREF="http://www-agce.informatik.uni-kl.de/~kuehne">http://www-agce.informatik.uni-kl.de/~kuehne</A>
<br>The difficulty in doing research is to find the right questions
<br>so that all the answers come easily. -- TK
| Albertina Lourenci |
| PhD in Architecture and Urbanism |
| post-doctorate researcher |
| Laboratory of Integrated Systems University of Sao Paulo |
| Avenida Professor Luciano Gualberto, 158 Travessa 3 |
| CEP: 05508-900 |
| Sao Paulo Sao Paulo State Brazil |
| Voice: +55 011 818 5254 |
| Fax: +55 11 211 4574 |