@asuffield said:
The "object pool" pattern is a workaround for impure languages with slow object allocation; in a pure functional language like Haskell, it has no relevance or purpose, since there is no object allocation at all.
This statement seems extremely narrow minded. "Object pools" are mostly used for objects that are inherently slow to allocate and/or resource intensive, like database connections. It's not a limitation of Java that it takes (say) 1.5 secs and 5MB RAM to open a connection to a database server.
There's a whole bunch of "patterns" that fall into this category - a differently designed language, like (for example) Haskell or Prolog, completely obliterates any need or meaning for them.
Of course. That's because design patterns are described in the context of object oriented programming.
This kind of lego-brick thinking is counter-productive. Software cannot be decomposed into a set of discrete components that you can name, and attempting to do so merely leaves you unprepared for the highly fluid nature of non-trivial design work.
There are no intrinsic 'advantages' and 'limitations' - they're things which were made up along with the brick itself. Any or all of them can be moved, eliminated, or worked around as necessary. Teaching people about bricks just means that later they're going to have to make the very difficult leap to realising that there are no bricks. This does not make somebody a better programmer.
I have lost count of the number of times I've seen some Java nut do things in a sub-optimal way, and when you point out to them how it could be done better, they just look at you blankly and say "that's not how the pattern works".
Software development is not a sack of lego bricks. It's a way of thinking.
SW Developers must be aware that reasonably complex software cannot be entirely composed of standard lego bricks. On the other side, for many routine tasks, those lego bricks are suitable. Since many programmers use those bricks anyway, why not give them a name?