<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
Jecel Assumpcao Jr wrote:
<blockquote TYPE=CITE>As promissed, here are some quick comments from a
<br>viewpoint on the patterns in the "Design Patterns" book by Erich Gamma,
<br>Richard Helm, Ralph Johnson and John Vlissides. The numbers in
<br>parenthesis are the page numbers where each pattern is described.
<p>I hope this helps,
<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
<br>to my reading of Peter Wegner's paper.
<br>But let's examine the Abstract Factory.
<p>I immediately realized it could be used to achieve portability
<br>different systenms. Well, indeed GOF states that Et++ (paper
<br>OOPSLA 88 uses the Abstract Factory pattern to achieve
<br>portability across different Window Systems (X windows and Sun View)
<br>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
<br>be encapsulated in the system architecture to ease integration.
<p>There are different versions of Self (???) for Macintosh, Sun,
<br>now for Linux and later for Windows and so on...
<br>Why not to build a unique software architecture (? framework?)
<br>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
<br>expressive the Abstract Factory pattern?
<br>Hope I have expressed my impressions in correct technical terms.
<br>If not please help me to clarify my reasoning.
<p>===> Abstract Factory(87):
<p>I have suggested that it might be interesting to add abstract types
<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
a: list copyRemoveAll
<p>which refers to a specific prototype (list) directly, we could have
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>This goes against the idea of creating new objects by simply cloning
<br>existing one. Of course, sometimes cloning is anything but simple.
<br>the copy method for morphs, for example. But it is probably better
<br>stick with the current Self style of stuffing all the complexity in
<br>'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
<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
<br>example. No big deal.
<p>This *is* a prototype based language. You can't avoid using this
<br>pattern if you want to! No big deal.
<p>All objects in Self are singleton unless they have traits clonable (or
<br>some suitable replacement) as one of their ancestors. No big deal.
<p>This is *so* much simpler with implicit, dynamic delegation (data
<br>parents). When wrapping an objects with many methods, you only have
<br>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
<br>problems. I don't know of any examples in Self 4.1.2.
<p>You could use implicit delegation for this pattern, but the example
<br>Self (canvas) uses explicit delegation instead.
<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
<br>what objects can be plugged into what others more flexible.
<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
<br>used in Self 4.1.2.
<p>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
<br>is pushing it a little....
<p>I would say that Self's advanced inlining compiler technology makes
<br>this pattern less necessary than in other systems. This pattern is
<br>used as a classic example of the advantages of reflective systems (see
<br>the Open Implementation pages).
<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
<br>should never be used in Self.
<p>Exactly the same comment as for Adaptor. Except that there are plenty
<br>example of this in objects named, oddly enough, "proxies".
<p>===> Chain of Responsibility(223):
<p>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
<br>make much of a difference, here.
<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
<br>create a different class for each one.
<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
<br>develop and interpreter in a dynamic user environment really helps.
<br>think that most cases where this pattern might be used could be better
<br>implemented as a parser generated by Mango instead.
<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
<br>that made a lot of the higher level code considerably simpler.
<br>Iterators are important in languages like Self and Smalltalk that have
<br>a very awkward syntax for accessing vector elements.
<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
<br>don't see that Self is particularly helpful in this case.
<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
<br>great tools with a real persistent object store.
<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
<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
<br>as an example of how to implement this with implicit delegation,
<br>depending on your viewpoint).
<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
<br>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
<br>Self as well.
<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>
| 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 |