<!doctype html public "-//w3c//dtd html 4.0 transitional//en">

<html>

<p>Hi Thomas:

<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

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

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

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

the

<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 3.6.2.3 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

\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

ultimately required.

<p>I invite Günther to throw light in this passage. But I interpreted

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

a finer

<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

the ergonomics of the behavior of the human being.

<br>If architecture is not translated into forms  it is not architecture

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

(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

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

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

Graduate School of Architecture and Urban Planning at UCLA.

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

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

groups to their designs.

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

inner layout of an apartment.

<br> 

<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

was built in 1903.

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>163.outdoor room

<br>164.street windows

<br>165. opening to the street

<br>166.gallery surround

<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

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

the year.

<p>I love windows at the corners. And I love to let light fall from

the sky.

<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

they fit the needs perfectly well.

Indeed Alexander and I were anxious to work together.

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

resources.

<p>Cheers

<br>Albertina

<br> 

<br> 

<br> 

<p>Hi Albertina,

<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

to implement.

<p>> Kniesel in his thesis wants to show the superiority of delegation

but

<br>> I am still reading through his thesis and the papers I gathered and

I

> 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

my

<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

modeling.

<p>Cheers,

<p>    Thomas

<br> 

<p>--

<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

<br> 

<br> 

<br> 

<br> 

<br> 

<br> 

<pre>-- 

.----------------------------------------------------------.

| 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                                     |

.----------------------------------------------------------.</pre>

 </html>