Are ((design patterns)) just meme or are they useful? When I

ITT /g/ can't into programming

File: 1487543364025.gif (9KB, 200x200px) Image search: [Google]

9KB, 200x200px

and people say functional programming is a meme.

I think it's a bit of a hammer/nail problem, some ppl just try to use them for everything, even if it doesn't fit.

>>61236973
If you think about your objects intelligently, you'll probably end up using bunch of patterns without even realising it. There is no substitute for good system design. Sometimes patterns are appropriate but sometimes they can limit you.

>factory
>not an antipattern

Knowing your patterns really is what separates a koder from a programmer. The patterns you learn in your average class are just ways to work around obhect oriented languages. What you need to get comfortable with are the ones that are relevant to your field of work.

t. never wrote a useful program but studied cs

>>61236973
Design Patterns are a corporate meme to ensure you can be replaced by pajeets or low skilled workers.
I have never used Design Patterns because it makes me easily replaceable. As long as UX design patterns are followed you are ok. Coding design patterns should not be followed to ensure long term employment.

>>61237314
Pretty much spot on

>>61237314
>What separates me from other codemonkeys is that my code is unreadable
Well, at least you're not pretending to be good at programming

>>61237368
>good at programming

No such thing as a good programmer. The only people who care about quality code are open source fags and people hiring programmers.
Delivering goods in time is all that matters.

>>61237431
Yeah, and then half a year later a customer tells you there's a bug in the program, and you have to wade through piles of shit to find it. Even worse if it is someone else's piles of shit

>>61237558

Bugs are everywhere regardless of quality of the code. No one, regardless of skill can avoid them.

The dumb fucking customer would probably fired you because someone offered the "same" services for 85% less. If you can't wade through your own shit you are an idiot.

>>61237674
>Bugs are everywhere regardless of quality of the code. No one, regardless of skill can avoid them.
Yes, but readable code makes debugging easier

>If you can't wade through your own shit you are an idiot.
That's what you say, but go look at some non-trivial code you wrote 1-2 years ago and check for yourself whether it is still easily readable for you.

>>61236973
you will feel like you're getting memed until you encounter a problem that will be solved by applying one of the patterns

>>61237816
can be solved*

>>61236973
it's like asking if learning music theory is a meme
>protip: it's not

They're byproducts of OOP

>>61237856
Music Theory is not a meme, no one argued it is not.

Prove that Builder or Factory pattern is not a meme.

>protip: Music Theory is not the same as Builder or Factory pattern

>>61237856
>>61238251
You can create quality music using the Music Theory. You cannot create a quality program with a Builder or Factory Pattern.

As I understand it, these patterns are best used in really huge software systems to avoid whatever problems comes with those. I don't think you need to implement a factory pattern in some personal project. The only pattern I use consistently in small projects is MVC because it just makes sense for gui shit.

Patterns can be useful. I'm working on an enterprise level web/desktop app any we use DI to inject factories that map between entity and business models and vice versa. The factories used depend on the scope, like a particular API or if it is in the web app or on desktop.

Shouldn't just use them for the sake of using them though.

>>61236973
Of course they're useful. They're just names for things that end up happening a lot anyway. Hence "patterns". They are most important as a tool for communicating about code.

You can study the implications of a design pattern in somewhat language-agnostic way, so when you find yourself needing something like X pattern (or antipattern), you'll know the benefits and drawbacks.

Patterns are just putting a name on something natural. If you program long enough, you'll learn what works, and what doesn't. The things that work tend to be highly reusable, and voila: It's now a pattern. You can't just shoehorn them in places though. When you need one, it just feels right, and you know the solution is a good one because you've seen it before. You probably won't even think about the name. The name and implementation is secondary to the concept.

Don't try to use patterns as templates, and don't frame your code around mixing patterns. That's a good way to invent novel anti-patterns.