The problem is you buried your point in the 5th sentence in the 5th paragraph of basically a rant.
And it's wrong. No modern programmer does that any more.
When I first came here 9 years ago people would refer to patterns all the time. But this is the first time I've seen the GoF even mentioned in a year or so. People stopped caring about design patterns years ago because they stopped being relevant.
And good riddance, the whole thing was a farce that spawned factoryFactoryFactories and newbies constantly asking how to implement a singleton because actually they wanted glorified global variables because they can't program properly.
Where the GoF completely failed, javascript, ironically, saved us (with Crockford doing the nudging). It forced functional paradigms, lambda expressions, anonymous types, function objects, etc. into the mainstream languages where lisp had failed and almost overnight made design patterns obsolete. It fundamentally changed how we programmed so that the problems the patterns aimed to solve weren't problems any more.
Precisely. Each language and domain of programming gets its own set of patterns. Some patterns are obsoleted (by virtue of being unneeded, or baked into the language), some new ones are created. Some are amalgams of old ones.
This is the way of the world, design patterns are intended to offer a language, and languages evolve. The uniqueness of design patterns to certain domains/languages can be seen as equivalent to the jargon between different technical fields. It doesn't mean that one set of jargon is obsoleted, it just means it's inappropriate. The failure, if any, in our world (programming) is to recognize and emphasize that different levels of programming, different languages, different operating systems, require different jargon and patterns and approaches.
> And good riddance, the whole thing was a farce that spawned factoryFactoryFactories and newbies constantly asking how to implement a singleton because actually they wanted glorified global variables because they can't program properly.
Number one on HN at the moment for me is "Async/Await support landed in Firefox Nightly". With Async/Await, instead of explicitly queuing callbacks in the main event loop and then returning control to the main event loop (ala Reactor Pattern), I create a queue of callbacks that are scheduled to run one after the other when each one terminates. This is different from a Continuation, where I queue my current state, schedule a callback to be run and then restore my state.
I often use Rails (not usually by choice ;-) ). Data is mapped from relational tables into objects using a pattern known as Active Record. In this scheme you generally have one model object per table and the model object itself is responsible for writing data to the database. There are other schemes for mapping relational data to model objects. Active Record is very convenient for simple data models, but is not great for more complex systems.
The opinion you express (that modern programmers need know nothing of patterns) is one of the reasons why programmers don't understand the tradeoffs between Reactor, Async/Await, and Continuations. It is one of the reasons I have to pull out my hair dealing with domain object models that mirror relational layout exactly.
I haven't mentioned a single pattern from GoF, but it's all the same. These are design techniques that are appropriate in some situations, but not in others. Even the very, very simple design pattern in GoF are unknown by a large proportion of programmers out there. Things like Flyweight pattern should be basics for any programmer, but most people haven't got a clue. And if I had a nickle for every time I've seen Composite Pattern where one of the terminating objects is not a subclass of the container (with obvious hilarity ensuing), I'd be a rich man.
How many times have I seen people deriding OOP and espousing the advantages of pattern matching? We can write functions that are polymorphic to their parameters so that we can group all the functions doing a particular thing in one place, regardless of type! The same people will chop my hands off if I mention Visitor pattern.
The paradigms you espouse are patterns. They even have names. And they have situations where they are appropriate and where they are not. If you get it into your head that the language designer will tell you how to do it, so that you don't have to know, it will limit your growth as a programmer dramatically. If you think that your programming culture will somehow allow you to escape the need to think about and discuss techniques -- using names, and describing situations where the techniques are beneficial and when they are unwanted -- then you will never understand what you are doing.
I don't for a minute believe that you intend to stay so ignorant, but the words that you type have been used to keep many from improving their abilities beyond basic repetition.
`The opinion you express (that modern programmers need know nothing of patterns) is one of the reasons why programmers don't understand the tradeoffs between Reactor, Async/Await, and Continuations. It is one of the reasons I have to pull out my hair dealing with domain object models that mirror relational layout exactly.`
I actually rather a domain model that mirrors the relational layout exactly, as this reduces my time spent in some god unknown framework who is over-engineering with `design patterns`.
`These are design techniques that are appropriate in some situations, but not in others`
Like what? Seriously? Do you have any evidence to backup the assertion of design techniques that are appropriate for some situations but not others? Otherwise you're just kidding yourself.
'Like what? Seriously? Do you have any evidence to backup the assertion of design techniques that are appropriate for some situations but not others? Otherwise you're just kidding yourself.'
Really? This requires proof? I would have thought it was self evident. Take the Flyweight pattern mentioned previously - appropriate when you have thousands (millions, billions...) of entities and memory is constrained.
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
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.
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.
> Like what? Seriously? Do you have any evidence to backup the assertion of design techniques that are appropriate for some situations but not others?
It's hard to say what you mean by this. I have difficulty believing that you think that a technique used in one situation is always going to be the best technique to use.
As someone has already graciously described situations where Flyweight can be used, perhaps something simpler than that like the Singleton can be illustrative.
The OP opined that the Singleton is only useful to people who don't know how to use a global variable. If that were the case, it would not be useful at all. In fact, it's usually something to stay away from. However, it absolutely shines when you want to make sure that an entity's constructor is only called exactly once.
There are many situations where you need to do this -- often when interacting with hardware, this kind of thing is crucial. As the OP suggested, though, it's easy to misuse this pattern.
And it's wrong. No modern programmer does that any more.
When I first came here 9 years ago people would refer to patterns all the time. But this is the first time I've seen the GoF even mentioned in a year or so. People stopped caring about design patterns years ago because they stopped being relevant.
And good riddance, the whole thing was a farce that spawned factoryFactoryFactories and newbies constantly asking how to implement a singleton because actually they wanted glorified global variables because they can't program properly.
Where the GoF completely failed, javascript, ironically, saved us (with Crockford doing the nudging). It forced functional paradigms, lambda expressions, anonymous types, function objects, etc. into the mainstream languages where lisp had failed and almost overnight made design patterns obsolete. It fundamentally changed how we programmed so that the problems the patterns aimed to solve weren't problems any more.