Design Patterns

Why should I bother learning all these design patterns as a programmer? Convince me, you got 30 seconds. Go.

Attached: gof_cover.jpg (520x648, 93K)

Because you and I have very high IQs in the 150 range. We quench for knowledge and learning about the plethora of design patterns is intellectually stimulating.

>reusable
I love this meme

Honestly, I didn't understand oop before I read that book.

You shouldn't, they're garbage used to build enterprise software.

You only need design patterns if your language sucks.

How many of you actually studied all or most of these patterns?

Are you using them regularly and was it worth it?

Many of the patterns we take for granted nowadays (singletons, proxies, etc.) come from that book.

But I understand oop

to "get" what people are doing with their code and to write code that other people will "get" what you intended to do

You're probably already using a lot of them and don't even know. A lot of times these books are just filled with best practices and give names to common themes seen in source code. Not all the patterns are useful all the time but it's handy to know. You don't always have to ensure your code has 100% test coverage and continuous integration but knowing it is interesting and sometimes helpful.

>IQ in the 150 range
>can't use the word "quench" in a sentence

Which one did I coincidentally use? I've never accidentally made a singleton. I'm too retarded for that.

But do you "get it"? Gof has a lot of "ah ha!" moments.

Null references, iterators, and interpreters were all written about in the Design Patterns book.

They are mostly good for talking about code with other people. Many of them are good ideas for SOLID designs (applicable to multiple programming paradigms, not only OOP), some of them are so widespread they became features in modern languages and frameworks, so you use them without even knowing... And some of them are now kind of deprecated, the GOF guys are smart, but they write shit too

I thought I understood OOP but I am completely baffled by that book. I understand OOP principles but when I look at a certain pattern it just turns to wordsalad.

Are there any OOP books that you might recommend, because perhaps I haven't had enough of a formal exposure to the prerequisite ideas.

Many people recommend "head first design patterns" by E&E Freeman over GOF
I haven't read it, but I'm keeping it on my backlog. It definitely seems more sane

Here we go.
Design patterns are not meant to be building blocks of all software that you write. You learn from them. You adapt them to your needs. They help you recognize patterns that arise naturally in your software design.
Also these don't cover all the patterns. There are literally thousands of software design patterns. These are just some of the most common ones for OOP.
Also design patterns help developers communicate with each other in a higher level about system design.

/thread

>head first design patterns
I remember finding that book and using it to implement a menu, using the composite pattern. That chapter was total garbage. I vaguely remember there being two classes, Menu and MenuItem, but down the line I realized that makes things way more fucking complicated and that everything could just be one kind of item. And because they used two classes where just one would do they also had to write an interface that was responsible for making up the deficiency of the brain dead design.

>take for granted
>singleton
literally 0 singletons in the wild have a single instance

does this book have exercises?

Meme CV.
Usually design pattern are very obvious if get experience as programmer, and design pattern name allow programmer could discute and learn about design build references and guides for it.

But as theorical foundament begin a bunch ad hoc rules and superfluous terms.

Mathematics begin better for design,modeling and organize computational systems.

learn English

Because expressing the things you want to do as sensible software patterns is an enormous part of your job.

Head First Design Patterns is a great tutorial book. The writing tries pretty hard to be "funny", but after a million dry systems manuals without a shred of humanity, that's almost a plus. And it makes it easier to learn the shit it's teaching.

Design Patterns is a must if you want to make any kind of decent-sized software that isn't held together with paper clips and chewing gum. It isn't a textbook so much as like a catalogue of different ways to make your software easier to develop and maintain.

Read Head First and then decide if the material is relevant to you.

Don't waste your time with design patterns.
Good programmers gain nothing from them.
Bad programmers somehow become even worse when they learn about them.

Why should an architect learn how houses are usually built? They can figure it all out themselves on the go, right?

>Quenching for knowledge

>Factory pattern

Fucking end my lif-

>Here use these smart pointers

END ME

because you have to clean up the mess made by other programmers who read this book.

You shouldn't have gotten tested, now the low number is fucking with your head

I say that shit to impress people whenever I can.

I have never ever used knowingly any pattern except for univ projects when they were forced. I just think azbout what has to bo done to solve problems not about what fancy pattern to use. And I have the job done as a result. Plus i program procedurally as I'm kernel developer. and most of patterns are oop only crap

Well aren't you a smart little snowflake

When's high school starting back up, junior?

>When's high school starting back up, junior?

?

Because others used them in the large code base you are working on. It's worth knowing when you see a horrible contraption that the intent is to implement one of these. Many of these are garbage though.

I'm sorry, did you start already?

he explicitly said he was a university student, moron.

>t. certified fizzbuzzer

>smart pointers are bad
nice meme

Why are you speaking for him is this your fucking boyfriend?

frustreted gay virgin detected

I studied videogame design patterns and most of them are great.
Literally every C/C++ programmer should know the object pool, factory, component, type object (!), and flyweight patterns.

what book?

>Literally every C/C++ programmer should know the object pool, factory, component, type object (!), and flyweight patterns.

No.

Videogame design patterns.
Yes.

>Yes
No.

>Иo.
Уeз

>No.
Yes.

>¥ęś
Ńó

>Yes.
No..

It's irrelevant trash for the most part. A lot of it is pretty obvious and you probably already do some of these without knowing the meme name for it. At best you should have a vague idea of some things to keep in mind but don't read that thing like a book. Treat it like a reference manual to help jog your thinking when solving the problems you're working on.

This!

Because they are useful. Very useful.

This tbqh, i was so proud when i made my first factory

I'm 33 and I have only ever had one interview that asked me about design patterns. They asked about a client-server queue or something in Java. It seemed like a decent company, but it's only something that comes up if you're doing actual software architecture.

Onl brainlet and subpar programers feel need to study design cuckterns

I learn them on the fly as I pogram, I will search for the best solutions to a problem.