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

<html>

Jecel Assumpcao Jr wrote:

<br> 

<blockquote TYPE=CITE>As promissed, here are some quick comments from a

Self programmer's

<br>viewpoint on the patterns in the "Design Patterns" book by Erich Gamma,

<br>Richard Helm, Ralph Johnson and John Vlissides. The numbers in

parenthesis are the page numbers where each pattern is described.

<p>I hope this helps,

<br>-- Jecel

<br> </blockquote>

<p><br>Jecel:

<br>I do thank you for your efforts, although I will not be able to examine

<br>all the GOF's D.P. for the time being. It is adding a special flavour

to my reading of Peter Wegner's paper.

But let's examine the Abstract Factory.

<p>I immediately realized   it could be used to achieve portability

across

<br>different systenms. Well, indeed GOF states that Et++  (paper 

46-57)

<br>OOPSLA 88 uses the Abstract Factory pattern to achieve

<br>portability across different Window Systems (X windows and Sun View)

page 95f in Known uses GOF's book.

<p>So delegation is a powerful abstraction mechanism. There are various

<br>viewpoints on what precisely makes a system "open"

<br>One of the requirements is:

<br>Interoperability. Open systems typically run on heterogeneous

<br>hardware and software platforms. Platform differences should

be encapsulated in the system architecture to ease integration.

<p>There are different versions of Self (???) for Macintosh, Sun,

now for Linux and later for Windows and so on...

<br>Why not to build a  unique software architecture (? framework?)

to cope with this requirement?

<p>What are the difficulties involved? What role  does Abstract Factory

<br>play here? Can delegation alone do the same? I mean is it as

expressive the Abstract Factory pattern?

Hope I have expressed my impressions in correct technical terms.

If not please help me to clarify my reasoning.

<p>Cheers

<br>Albertina

<blockquote TYPE=CITE> 

<br>Creational Patterns

<br>--------------

<p>===> Abstract Factory(87):

<p>I have suggested that it might be interesting to add abstract types

to

<br>Self in the form of interface (to use Java terms) objects. This would

<br>be a good use of this pattern. Instead of writing

<p>              

a: list copyRemoveAll

<p>which refers to a specific prototype (list) directly, we could have

<p>             

a: interfaces sequence getOneFor: 'fifo'

<p>Of course, with dynamic types this pattern is considerably simpler in

<br>Self than in the book. I can't think of an example where this is used

<br>in Self 4.1.2.

<p>===> Builder(97):

<p>This goes against the idea of creating new objects by simply cloning

an

existing one. Of course, sometimes cloning is anything but simple.

See

<br>the copy method for morphs, for example. But it is probably better

to

<br>stick with the current Self style of stuffing all the complexity in

the

'copy' method instead of creating separate "builder" objects.

<p>===> Factory Method(107):

<p>It is hard to see what the fuss is all about when you have dynamic

<br>types and cloning. Just put a prototype of the "concreteProduct" in

a

<br>slot in the prototype of the "concreteCreator" and patch the copy

<br>method to go down one level, here. See the low level graphical

<br>framework in Self (canvas, windows, graphics contexts...) for an

example. No big deal.

<p>===> Prototype(117):

<p>This *is* a prototype based language. You can't avoid using this

pattern if you want to! No big deal.

<p>===> Singleton(127):

<p>All objects in Self are singleton unless they have traits clonable (or

some suitable replacement) as one of their ancestors. No big deal.

<p>Structural Patterns

<br>--------------

<p>===> Adaptor(139):

<p>This is *so* much simpler with implicit, dynamic delegation (data

<br>parents). When wrapping an objects with many methods, you only have

to

worry about the ones you will need to change, not about all of them.

<br>And Self really makes this pattern more powerful by allowing you to

<br>override data slots as well as method slots (even better: you can

<br>override a data slot with a method slot and vice versa). The only thing

<br>to watch out is how to handle copying and how to avoid having the

<br>adapted object's identity "leak out". Reflection might help with these

problems. I don't know of any examples in Self 4.1.2.

<p>===> Bridge(151):

<p>You could use implicit delegation for this pattern, but the example

in

Self (canvas) uses explicit delegation instead.

<p>===> Composite(163):

<p>Morphs are a great example of this. I am not sure that any Self

<br>features help very much, here, other than having dynamic typing make

what objects can be plugged into what others more flexible.

<p>===> Decorator(175):

<p>It would be more pleasing, in my opinion, to use data parents (implicit

<br>delegation) for this pattern. I don't know of any examples where it

is

used in Self 4.1.2.

<p>===> Facade(185):

I don't think Self makes this pattern simpler than in other languages.

<br>I was going to say that 'desktop' could be an example of this, but

that

is pushing it a little....

<p>===> Flyweight(195):

<p>I would say that Self's advanced inlining compiler technology makes

<br>this pattern less necessary than in other systems. This pattern is

also

<br>used as a classic example of the advantages of reflective systems (see

the Open Implementation pages).

<p><a href="http://www.parc.xerox.com/spl/projects/oi/workshop-94/foil/main.html">http://www.parc.xerox.com/spl/projects/oi/workshop-94/foil/main.html</a>

<p>Oddly enough, there are examples of this in Morphic. There are several

<br>cases where the strategy pattern should have been used but the

<br>information was represented as simple integers instead (see alignLeft,

<br>alignCenter and alignRight in columnMorph and similar options in

<br>related morphs). This is a design bug - I think the flyweight pattern

should never be used in Self.

<p>===> Proxy(207):

<p>Exactly the same comment as for Adaptor. Except that there are plenty

example of this in objects named, oddly enough, "proxies".

<p>Behavioral Patterns

<br>---------------

<p>===> Chain of Responsibility(223):

The event handling in the user interface partly uses this pattern.

<br>Having implicit delegation might be nice, but I am not sure it would

make much of a difference, here.

<p>===> Command(233):

<p>Event objects in the user interface could be considered an example of

<br>this. I think that this is nicer to do in Self since making lots of

<br>objects that are a little different isn't as bad as when you have to

create a different class for each one.

<p>===> Interpreter(243):

<p>The only example that comes to mind is tinySelf 1. While the Self

<br>language itself doesn't make this pattern much simpler, being able

to

develop and interpreter in a dynamic user environment really helps.

I

<br>think that most cases where this pattern might be used could be better

implemented as a parser generated by Mango instead.

<p>===> Iterator(257):

<p>As Smalltalk Stream classes show, this pattern is much easier to

<br>implement in dynamically typed languages. I don't know of any examples

<br>in Self 4.1.2 and sometimes miss them a lot. My students implemented

<br>iterators for matrix objects (for an unfinished 3D GUI project) and

that made a lot of the higher level code considerably simpler.

<br>Iterators are important in languages like Self and Smalltalk that have

a very awkward syntax for accessing vector elements.

<p>===> Mediator(273):

<p>Hmmm... I am not sure, but the damage/redraw logic distributed between

<br>morphs and the worldMorph might be considered an example of this. I

don't see that Self is particularly helpful in this case.

<p>===> Memento(283):

<p>Don't you just pity the poor slobs who have to program with systems

<br>that can't save Snapshots?  :-)

<p>You don't need this pattern with Snapshots, but in Self we do have it

<br>in the form of the Transporter. It would be nice to replace these two

great tools with a real persistent object store.

<p>===> Observer(293):

<p>I would say that the damage/redraw code also includes an example of

<br>this pattern. Self doesn't help with this either, but a reflective

layer might.

<p>===> State(305):

<p>Who needs this when you can have data parents? See the various tree

<br>objects in Self 4.1.2 as an example of why we can live without this

(or

<br>as an example of how to implement this with implicit delegation,

depending on your viewpoint).

<p>===> Strategy(315):

<p>This can also be implemented as data parents, but I have used explicit

<br>delegation in my own programs instead. In the latter case Self doesn't

bring much to the party.

<p>===> Template Method(325):

<p>This is used in many places in Self, including in the C++

<br>implementation of the virtual machine. For some reason I tend to think

<br>of the Beta language when I look at this pattern, but it is easy in

Self as well.

<p>===> Visitor(331):

<p>I can't think of any examples of this in Self, though some of the

<br>runtime code generated by Mango might qualify.</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>