Programming Design patterns part 1 :- remembering "The Gang of four..!"

Downloaded

@rant1ng I will also upload part 2 :)

Anyone seen any similar work targeting functional programming? Book, for instance?

@deepender im waiting!

Oh.. Wait are you making these?

You can take a look at http://blackwasp.co.uk/GofPatterns.... for detailed explanations

And you know what? All this shit is mumbo-jumbo that shall conceal that OOP doesn't and won't deliver.

Guys I had not made these... poster , this is a work of cool learners.

I have downloaded from http://celinio.net/techblog/?p=65

So for part 2 you can download from above link with better resolution.

@platypus Doesn't the FP ivory tower dictate that design patterns are just a sign of missing features in the base language?

A quick search uncovers this gem, showing 16 of the design patterns are irrelevant in functional languages.

FP for the win... Sorry GoF , but ur bullshit

Not sure about bullshit, but the fact of the matter is that Java has been slowly adding with each release stuff that Haskell had for 30 years now.

Damn epicycles man.

You know what's funny?

I never knew these, the names, and which is which, and the theory, etc.

I see a problem, I "invent" a way to deal with it in the most reasonable way I can think of.

And then I google my solution and find out I apparently used some design pattern.

Whatever, I don't care.

It works, it's the most reasonable solution (I can think of) to the problem, who cares about how others call it.

It happened several times to me, that I googled the official solutions to some problems, tried to understand them, unsuccessfully wasted 2-8 hours, then I said "fuck it, I'm going to invent my own", did precisely that, and after finishing the implementation I realized it's the standard solution which I had trouble understanding before.

Point: NOTHING beats the process of thinking through the problem by yourself, if you want to really understand it.

hey, but thanks to you I just learned that one of the things I do is Memento!

object.AsXNode / object.AsJSON

and then constructor of that object which takes the same kind of XNode/JSON as a parameter

that "Caretaker" is just where you save it into.

nice.

...but seriously, these things are just common-sense stuff given fancypants names.

also, in the "State" one, the object SHOULD NOT appear as if it changed its class, even though in reality it did...

...in my opinion.

otherwise the connection between Context and State breaks.

also, (as you can even see from the diagram) it's the same as Strategy pattern. Only the name changes depending on usage context, instead of internal structure/implementation, which is wrong, imo.

...oooh, i never knew how many criticisms I had against these patterns until I saw this cheatsheet of yours. thank you very much.

as a token of my gratitude, I will stop spamming those criticisms in the comments here =D

@karelian Depends what we mean by design patterns, I guess. FP tends to be more general, but I think of things like the following as design patterns:

- Composition

- HoF

- Map

- Fold/Reduce

- Lazy eval

- Iterators

- Tail recursion

- Monads

- Pure functions

- Closures

- Currying

@platypus Don't forget monoid, semigroup and kleisli :P

But it's funny, most of the stuff you enumerated are _features_ in FP languages and not necessarily patterns.

@karelian But, they would be functional patterns if implementing them if they weren't in the language natively---to the extent you could.

Maybe the definition of patterns in FP is a level higher than these. If so, I don't know what they are.

Awesome! Thnx.

@Hexwell @isDev

Thanks for your sharing :)

I had a link to the original creator with pdf version available :

http://mcdonaldland.info/2007/11/...