Hotspots: Admin Pages | Turn-in Site |
Current Links: Cases Final Project Summer 2007
Discussion 2 - Dasha Kishinevskaya
Part I: Describe the Portland Form. Why is it useful?
The Portland form, which got its name from the city all three of its authors-creators were from, provides a template for writing pattern languages or documents as they are otherwise called. The form, described as a "direct emulation of Alexander's form" on Portland Pattern Repository's web site, produces writing that is normally organized in an essay form rather than an outline. The goal is to present the collection of patterns in a system–a language– that will be interpreted as a whole. The Portland form also includes a summary section which lists groups of thematically related patterns as well as the general problem that relates them. In his discussion of the Portland Form on the Repository's web site, Ward Cunningham writes that patterns normally contain statements of this kind: "such and so forces create this or that problem, therefore, build a thing-a-ma-jig to deal with them." He also notes that patterns contrast themselves and forces that create them with stronger and weaker forces and their solutions which they discuss at the beginning and at the end respectively.
The Portland form is useful because it provides a uniform way of addressing issues surrounding any problem-solution set but, even more importantly, it allows related languages (and patterns within them) to be grouped together. Even the presentation style–the essay form–of the Portland form helps to see things in terms of the big picture.
Part II: Design Pattern: Generated Accessors
It is doubtful that there exists such a programmer who has never had to deal with writing accessor methods. Specifically, with the problem of performing this simple task over and over and over again with slight differences in method names and return types/values. What the design pattern suggests is quite simply a creation of a code generator in Smalltalk. The choice of a programming language is quite specific in this pattern because the entire publication is centered around "Expedient Smalltalk Programming". However, similar generator models can be drawn up for other languages with environments/resources consistent with such level of automation. The pattern makes perfect sense to me. The problematic or possibly problematic issues consist mainly of the fact that some of these generated methods might never be used and that if proper care is not taken hand-written methods with the same names as generated accessors can be rewritten. However the first issue does not impede prototyping and is easily corrected by simply deleting not needed accessors. The second issue is solved by simply paying attention and care to the process. Furthermore, the pattern suggest a uniform way for naming the accessors (for instance, for attributes of different types) and indicates that while a generator would get the trivial and time-consuming part of the process out of the way (as well as eliminate a risk of human-error, a typo, a problem with returning a value) the programmer can always add things to the generated "frame" if additional functionality is needed. I do believe that such a generator would be useful in my coding if and when I get to the point where I code much bigger programs than those currently assigned in my classes. Although I do not see the need for such a generator with current amount of attributes in an average class I write, I do think that things will change as I start writing bigger classes/programs.
Links to this Page
- Dasha Kishinevskaya last edited on 14 December 2005 at 10:48 pm by c-24-99-14-166.hsd1.ga.comcast.net
- Fall 2005 Discussion 2 last edited on 3 October 2005 at 4:29 pm by adsl-068-209-116-021.sip.asm.bellsouth.net