Update: Having found and read this description of Flyweight objects, I noticed first that the equipment being used was a DECstation 3100 (a machine I well remember playing "moonlander" on 16 or more years ago. It was "state-of-the art then and wowed everyone that saw it) and then noticed that the dates on the paper and the references therein were 1987,1988 & 1989. I then realised that this description of flyweight objects comes from a time when it may well have been considered unusual and new, though I don't recall them having a great impact at the time.
Prior to this I was under the impression that "flyweight objects" were being hailed as something new and different, and was intrigued to learned more, but was confused by what I read. Effectively the referenced paper puts that idea to bed and makes the rest of this post redundant.
I'll leave it here as is the apparent preference of the community as testimony that just because you haven't encountered the name of something, that you haven't been unwittingly using it for years. I guess what goes around comes around:^)
End update
Getting by the fact that I was arguing against the example given rather than the definition itself.
Can you explain to me how an object can have extrinsic state?
Using the Glyph example. The text given said that Doc was fast because it used Glyphs, which had no extrinsic state. The example give for what they did not have was position. If you add the position at which a Glyph is displayed or formatted to the Glyph itself, then you do indeed need many more instances than you would without it.
However, if you add the position information to the Glyph class it then becomes intrinsic? But what you now have is no longer a Glyph class, but a Glyph_At_This_Position class. To my way of thinking that just doesn't make sense.
You have a list (small-l) of Positions at which to display Glyphs, and you give the Glyph to the Position not vice-versa. That way, when you reformat to a different page width, you run down the list of Posistions and adjust them and the Glyphs move appropriately. If that means I'm wanting to use Flyweight objects for my Glyphs, then so be it, but it seems like a strange name for the concept and hardly new.
I mean, we build strings from chars, we don't tell a char that it occupies position 7 in this string?
Examine what is said, not who speaks.
| [reply]
[d/l] |
I'll leave it here as is the apparent preference of the community as testimony that just because you haven't encountered the name of something, that you haven't been unwittingly using it for years.
That's what I think is the great thing about design patterns. They give names to all those things that we've been doing for years. This makes it a lot easier to talk about the concepts in question.
By definition, a design pattern cannot be new. It has to have been done several times before people can spot it as a pattern :-)
Getting by the fact that I was arguing against the example given rather than the definition itself.
Apologies for the confusion caused by my poor nomenclature.
| [reply] |
No apology necessary. As far as I am aware you were simply passing on the example given in the Design Patterns book you mentioned. That in turn was quite possibly re-telling an example from an intermediary going all the way back to the article I found. I haven't located any early references to the term "Flyweight objects". Maybe there were many itermediaries between the original example and the version in the book, and like the child's game of chinese wispers, the example becomes slightly distorted with each retelling. By the time I read your description, and coming to it from the perspective that I didn't understand the term and trying to associate it with Abigail's Inside-Out objects, I simply got confused.
I understand what you (they) mean about patterns, but again, applying the label "Design Patterns" suggests that it is a new discovery where I would see it as a re-recognition of a long know phenomena summed up previously by such adages as "There's nothing new on earth" or even "History repeats itself".
The first time I recall encountering something that was similar was whilst working on the functional verification program for Presentation Manager, the GUI of OS/2. One of our early tasks was to write test programs to exercise as many aspects of that GUI as possible. However, the only documentation available was a 6 inch thick stack, of 132 column green and white lined, fanfold listing paper known colloquially as "the brick", but officially as "The Specification Document". This was the most amazing mix of high and low level design work ranging from what fore/background color schemes worked best, down to the bits and bytes of the algorithms used to minimise redrawing of overlapping windows, and pseudo code descriptions (that changed almost daily) of the API's. From this document and twice weekly builds almagamated from development teams spread across 4 continents and the full 24 hours of timezones, we were expected to put together applications that could be verified and then used a regression tests.
One of the guys decided to put together a simple, mini-spreadsheet program. Reading the spec he noted that each window could have one or more user-defined window words associated with it. These seemed like an ideal place to store the cell values, formulea, formatting information etc as you could then write a generic window procedure that each time any event (mouse click, keystroke etc.) occured in any window of that class, the window procedure was called in the context of the window generating the event. It was then a simple call to access the window words (instance data) for the cell of the spreadsheet the user was intereacting with. Whilst the spreadsheet was a being written, it had a 4 x 4 grid of cells and seemed to work fine. However, once he tried to scale this up to 26 wide by 255 deep, it fell in a heap.
Not surprising really as the system only had 4k window handles available and this one application was trying to allocate around 6k of them!
The simple expedient of moving the spreadsheet data into a 2d array, indexed by the (x,y) coordinates of the cell. This meant that the cell data could be accessed by a simple translation of the position of the click in the main window. Passing that data to a single, Cell-class window that got positioned relative to the click, meant that with changing about 10 lines of code, the spreadsheet could handle a grid of 676x1024 easily on a state-of-the-art machine which at that time had a 16 MHz processor and 4MB of ram! Fun times.
Examine what is said, not who speaks.
| [reply] |