3 ms·

How can it be self evident? You made a statement saying `Some are appropriate for some situation but not others` You've listed one example of Flyweight, but wi

by hackits 10y ago

How can it be self evident? You made a statement saying `Some are appropriate for some situation but not others` You've listed one example of Flyweight, but without any sources to backup the claim it's appropriate when memory is constrained.

afro88 10y ago
The whole premise of the GoF book is to offer patterns that are helpful in certain situations. They describe when a certain pattern will help and when it will not in detail. They also take care to tell you that you should think carefully before using a pattern and consider all the alternatives to be sure you're using the right tool for the job (or maybe a pattern that isn't in the book would work too of course) To use the building architecture analogy FTFA, the "door" design pattern is good for some circumstances and the "window" pattern for others. This is the same thing. Not sure what proof you're after? It's a great collection of patterns that you can pick and choose from, not the be all end all, and totally worth reading even if you only get 1 idea for how to solve a problem from it
jfoutz 10y ago
I'm not sure if you're seriously questioning, or if you're trying to win an argument. i'm going to go with the notion that you're genuinely curious. I worked on a project with grids, an editable table like an excel sheet. Each grid, row, column, and cell could be styled. Font as Arial, Comic Sans ...; Color as rgb; padding top, left...; background color as rgb; Alignment as left, right or justified; format as freeform string, integer, float money or regex; decimal separator as . or , ; thousands separator as . or ,; and a whole bunch more. The first cut just naively associated a style struct as part of each cell's data. Several customers complained that grids were very slow to start up, a few complained that they were running out of memory. They were using very large datasets for the grid, and the naive implementation wasted a lot of time on initialization, and a lot of memory on duplicate representation of style. In retrospect it was a stupid mistake to make. We'd only tested against small amounts of data on relatively fast machines. Customers were using millions of rows. The solution we went with was the aforementioned pattern. it saved a ton of memory and a ton of time avoiding all of that initialization. There were a few rounds dealing with smart lookup of style based on cell, row, column, and overall table. My c++ is rusty, but i'm a little baffled by your confusion. Iterating over data structures in a uniform was was kind of a big deal back in the day. IIRC, implementing preorder, inorder and postorder iterators for a binary tree was homework. Have iterators fallen out of fashion? I don't have a peer reviewed paper paper indicating flyweight is helpful. I don't have a peer reviewed paper saying multiplication is better than looping over adding m to itself n times. It's just better. Some of them are mostly stupid, ala singleton. Of course even stupid singleton is a nice place to stick environment variables, because they are globals. I never thought decorator was all that great. I really like composite, but i like tree representations that i can recurse over. If i had a scale, where you could place code on one side, and a design pattern on the other side, and it would balance if adding the design pattern was worth it, i would give it to you. To my knowledge, no such thing exists. If you have questions, i'll try to answer. here or jfoutz at gmail.
fusiongyro 10y ago
It says so in GoF. The example in the book is having an object represent each character on the screen. You don't want to pay the overhead of an object for each byte in a file, so you use flyweight to share all the instances of each character.

by hackits 10y ago

afro88 10y ago

The whole premise of the GoF book is to offer patterns that are helpful in certain situations. They describe when a certain pattern will help and when it will not in detail. They also take care to tell you that you should think carefully before using a pattern and consider all the alternatives to be sure you're using the right tool for the job (or maybe a pattern that isn't in the book would work too of course) To use the building architecture analogy FTFA, the "door" design pattern is good for some circumstances and the "window" pattern for others. This is the same thing. Not sure what proof you're after? It's a great collection of patterns that you can pick and choose from, not the be all end all, and totally worth reading even if you only get 1 idea for how to solve a problem from it

jfoutz 10y ago

I'm not sure if you're seriously questioning, or if you're trying to win an argument. i'm going to go with the notion that you're genuinely curious. I worked on a project with grids, an editable table like an excel sheet. Each grid, row, column, and cell could be styled. Font as Arial, Comic Sans ...; Color as rgb; padding top, left...; background color as rgb; Alignment as left, right or justified; format as freeform string, integer, float money or regex; decimal separator as . or , ; thousands separator as . or ,; and a whole bunch more. The first cut just naively associated a style struct as part of each cell's data. Several customers complained that grids were very slow to start up, a few complained that they were running out of memory. They were using very large datasets for the grid, and the naive implementation wasted a lot of time on initialization, and a lot of memory on duplicate representation of style. In retrospect it was a stupid mistake to make. We'd only tested against small amounts of data on relatively fast machines. Customers were using millions of rows. The solution we went with was the aforementioned pattern. it saved a ton of memory and a ton of time avoiding all of that initialization. There were a few rounds dealing with smart lookup of style based on cell, row, column, and overall table. My c++ is rusty, but i'm a little baffled by your confusion. Iterating over data structures in a uniform was was kind of a big deal back in the day. IIRC, implementing preorder, inorder and postorder iterators for a binary tree was homework. Have iterators fallen out of fashion? I don't have a peer reviewed paper paper indicating flyweight is helpful. I don't have a peer reviewed paper saying multiplication is better than looping over adding m to itself n times. It's just better. Some of them are mostly stupid, ala singleton. Of course even stupid singleton is a nice place to stick environment variables, because they are globals. I never thought decorator was all that great. I really like composite, but i like tree representations that i can recurse over. If i had a scale, where you could place code on one side, and a design pattern on the other side, and it would balance if adding the design pattern was worth it, i would give it to you. To my knowledge, no such thing exists. If you have questions, i'll try to answer. here or jfoutz at gmail.

fusiongyro 10y ago

It says so in GoF. The example in the book is having an object represent each character on the screen. You don't want to pay the overhead of an object for each byte in a file, so you use flyweight to share all the instances of each character.