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

<html>

Günter Kniesel wrote:

<br> 

<p>Hi Gïnther:

<p>                   

Well if you are not worried in saving Mother Earth,

<br>I am. I need OOP to build sustainable cities. I  know most computer

<br>scientists prefer to build interplanetary stations when life on earth

<br>will not be possible anymore. Please don't take this as aggressive,

but all my life orbits around this concern.

<br>                       

Otherwise,  the  brightest computer scientists seem eager

<br>to see the take-off of the prototype paradigm. And gracefully you made

<br>public electronically all you do. I am asking for a grant to have facilities

that will enable me to make all that I do available at the Internet.

<br>                        

And above all I am an artist. I have just finished writing

something about hermeneutics. Music is the most hermeneutic art.

<br>So for me a discussion like the one I am proposing is like mimicking

a symphony. Why can't we play together?

<br>                               

In real music, specially contemporary music

<br>dissonances are welcome. So why to get worried?  Musicians

say that dissonances are more difficult consonances.

<br>                               

I read through your response fast. I have to go

<br>swimming now as part of my health recovery. All the information

<br>is my head is fuzzy, so I cannot agree or disagree if you said

<br>delegation is better or not than patterns. As far as I know I have

to

<br>read at least your whole chapter 8 Applications (165-178) and

many more papers  about design patterns to conclude something.

You would help my poor brain to stay fit if you agreed in cooperating.

<br>Please be gentle. There is no better way to learn than discussing and

<br>making errors. Randy Smith made a good contribution to this through

<br>his Distributed tutored video instruction. I loved it and it emphasized

the musical nature of Self.

<p>As soon as I can, I will dialogue with you all about Günther's

statements.

<p>Best wishes

<p>Albertina

<br> 

<br> 

<br> 

<blockquote TYPE=CITE>Dear all,

<p>> Bharat Bedia wrote:

<br>>

<br>> > Firstly my apologies if people find

<br>> > this thread off topic. If they can point me to an appropriate place

> > then I'll glad take the conversation elsewhere.

My appologies too, to anyone not interested in this discussion.

<br>However, since I've been cited in a way that lends itself

<br>to being misinterpreted I have to make a few statements

for the people who read the previous mails.

<p>Any followup message will be sent just to those who

participat(ed) in this discussion.

<p>By the way, Albertina, there was no point in asking the whole

<br>world what I could have possibly meant with a certain passage

<br>of my PhD thesis. Just send ME your questions, I'll be happy to

answer them.

You can still make your conclusions public if you feel the need.

<p>Guenter

<p>-----------------------------------------------------------------------

<br>Albertina Lourenci wrote:

<br>>

<br>> Günther Kniesel seems to be making a good job in his Ph.D Thesis

<br>> (Take a look at the Darwin project. It is an extension of Java

<br>> supporting a

> form of delegation, so you get both classes and delegation.

<br>>

<br>> <a href="http://javalab.cs.uni-bonn.de/research/darwin/darwin_eng.html">http://javalab.cs.uni-bonn.de/research/darwin/darwin_eng.html</a>

<br>>

<br>> ... snip ...

<br>>

<br>> And what is best  he argues that the complexity of many patterns

<br>> is not intrinsic, it can often be seen as resulting from poor language

> support. (Kniesel, Ph.D thesis page 165 at the bottom).

<br>> So I invite him to join our discussion and show to us how

> delegation implements the design patterns better.

<p>Well, the GOF itself mentions several times the problems involved

<br>in implementing patterns like strategy, state, etc and

<br>refer to Self as an elegant alternative. In my phd thesis you can

<br>compare the code in the implementation chapter to the code in the

applications chapter.

<p>If you have delegation you can implement an "overriding decorator"

<br>which provides behaviour that will take effect in the

<br>context of the "decorated" object by essentially one keyword:

<p>class Decorator extends Whatever {

<p>  protected final delegatee Decorated _decorated;

<br>                 

^^^^^^^^^

<br>  Decorator( Decorated d) { _decorated = d }

<p>  // ... any methods

<p>}

<p>Decorator will automatically be a subtype of Decorated,

<br>locally unimplemented messages will automatically be delegated

<br>to objects referenced by _decorated and

methods in Decorator will override methods from Decorated.

<br>This works even if there are no hard-coded hooks in Decorated

<br>to enable such an extension. *Unanticipated* extension is

not possible with patterns.

<p>If you do not have delegation as a first class language feature

<br>you have to anticipate the extension and hand-code anything that

is described in the "implementation" chapter.

<br>And that is substantially more than what is discussed in most

<br>"delegation-like" patterns. For instance, the problem of direct

access to public variables is usually ignored.

<p>I'd say that the step

<br>- from "many, many lines of code all over your application" to

<br>  "one keyword" and

<br>- from "imposible" to "possible" in the unanticipated extension

<br>  case

<br>is a significant simplification ;)

<p>> Jan Bosch wrote an interesting article "Design Patterns as Language

<br>> Constructs" in Journal of Object Oriented Programming May 1998

<br>>

<br>> He identifies four problems associated with their implementation

<br>> using conventional object-oriented languages. First, the traceability

<br>> of a design pattern in the implementation is often insufficient;

the

<br>> design pattern is lost. Second, because several patterns require

an

<br>> object to forward messages to other objects to increase flexibility,

<br>> the self problem often occurs. Third, because the pattern

<br>> implementatin is mixed with the domain class, the reusability

<br>> of pattern implementations is often limited. Finally,

<br>> implementing design patterns may present significant

> implementation overhead for the software engineer.

<p>I use to call patterns like state, strategy, decorator, flyweight,

<br>etc "split object patterns". They share the basic idea of splitting

<br>one conceptual object into (at least) two implementation objects

<br>that should act like one. For split object patterns, delegation

<br>is the natural implementation technique. It eliminates all the

shortcommings addressed by Jan Bosch.

<p>> > > At the right moment based on  Günther Kniesel's PHD

thesis

<br>> > > I am trying to figure out why he  argues that delegation

is

<br>> > > far better than design patterns.

I did not say that delegation is better than (any) design patterns.

<br>Obviously delegation is completely unrelated to tons of patterns

(e.g. singleton, template method, factory method, etc).

<p>What I say and mean is that delegation is the best way to implement

<br>split object patterns. Put differently, it is not an alternative to

<br>the patterns themselves, because it preserves their essential ideas,

<br>but it simplifies their implementation up to the point where it

becomes trivial.

<p>With delegation the implementation of many different patterns

<br>is so similar (because all the "simulation noise" vanishes)

<br>that it becomes obvious that all split object patterns

<br>are essantially instances of two basic cases:

<br>- unanticipated, identity-changing extension (decorator-like)

<br>- anticipated, identitiy-preserving splitting (strategy-like)

(See the "Applicatons" chapter of my thesis).

<p>-------------------------------------------------------------------

<br>Albertina Lourenci wrote:

<br>>

<br>>

<br>>

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

<br>>

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

<br>> ultimately required.

<br>>

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

> as delegation is better than design patterns.

<p>Just shift the stress in your citation an you'll get it:

<p>  > Thus the application of

<br>  > DESIGN PATTERNS FOR SIMULATING BEHAVIOUR EVOLUTION

<br>  > can impede reuse ...

<p>That's it: I do not refer to patterns in general but

to PATTERNS FOR SIMULATING BEHAVIOUR EVOLUTION.

Or, more general, to "split object patterns".

<p>-------------------------------------------------------------------

<br>> Thomas Kuehne <kuehne@informatik.uni-kl.de> wrote:

<br>>

<br>> Hi Albertina,

<br>>

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

Thanks Thomas. That is just what I meant.

<p>Regards

<br>Guenter

<p>-----------------------------------------------------------------------

<br>Guenter Kniesel                              

e-mail: gk@cs.uni-bonn.de

<br>Computer Science Department III              

Phone:  (+49-228) 73-4511

<br>University of Bonn                           

Fax:    (+49-228) 73-4382

<br>Roemerstr. 164

<br>D-53117 Bonn                                 

Office: A118

<br>-----------------   <a href="http://www.cs.uni-bonn.de/~gk/">http://www.cs.uni-bonn.de/~gk/</a>  

------------------</blockquote>

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