This shit makes me want to scream

This shit makes me want to scream.

Attached: 0201633612.jpg (380x473, 35K)

how should i learn design patterns?

OOP was a mistake

Prototype Oriented programming is the closest we can currently be to using Lisp like programming.

Attached: 1566248948907.jpg (1536x2048, 183K)

write programs and see if you can match up any of your structures with the design patterns in the book
should be pretty easy to memorise quite a few when you actually know what theyre for

You just need to reference them when you need them.

Example: Singleton pattern
- When you only need one fucking single class instance in the entire executable

public class SendMail
{
private static SendMail instance = null;
public static SendMail Instance{
get{
if(instance == null)
instance = new SendMail();
return instance;
}
}

public void Send(string Message)
{....}
}

------------
SendMail.Instance.Send("Something");

Also note that you should never use singletons

You are fucking wrong
>hurr durr, use static methods

it could be a case where you don't have an actual implementation of the object, in which you only have a Interface, where you could properly use singletons

you are just a moron, but you are unaware that you really are a moron

what if it's useful for keeping the state of some data and that data needs special manipulation and access logic

that person obviously lacks any critical thinking, and just meme's whatever his relevant programming blog tells "they" to do

>never do this, never do that
that's just childish, there is always an exception do to x

Service locators are a good use of singletons.

oop fucking sucks and I wish people didn't fall for that meme because now I have to work with that shit

@Component
@Service
@Autowired
@Bean
@Singleton
@Builder

I used to be a OOP fanboy until recently where I met Prototype-based programming

Its the closest thing I have ever been to Lisp, but of course, only few people with critical thinking can actually exploit it

the rest are just kiddie-script programmers who lurk stackoverflow for every trivial problem

Why do they have to invent fancy words for everything man.

>Its a good idea to reuse good code structure to solve similar problems

Yeah no shit, no need to make entire books about it or to shit on devs who don't know the term.

Design patterns are useful, AS A REFERENCE, its not something you need to shove up your brain and use it every single fucking time

ironically, don't apply design patterns at design time. design patterns increase code complexity (for other positive trade-offs), you should keep your code as simple as possible for as long as possible to keep your sanity.
only after you start feeling your code is getting out of hand in terms of extendability and/or maintenance, and you identify some piece of your logic is surely something someone must have done before you in a more elegant way, you take out design patterns and check if there are any that you can apply to your code

it's important to have the problem (solvable by a pattern) yourself so you feel the need for a good solution. don't just read/rewrite code examples for the patterns, they are always over-simplified and lack any context

design patterns seem like they're strictly just working around the limitations of java

"work around limitations" of a language by implementing stuff in that language? usually the only limitation seems to be the person making this claim

design patterns aren't even language specific.
the GoF book is older than java and has examples in C++, iirc

Behold, the most misunderstood book in programming.
Bad programmers and project managers tend to love patterns because of an "if we use them, our code is good" attitude, which needless to say, is bullshit.
Of course, that's never what the book was about. If you read it, make sure to pay attention to the foreword and all of the text in between pattern explanations.
Understand the problems the patterns solve, and what alternatives you have.
The book is actually quite good if used correctly.

By now it's very dated and only useful to help you understand problem analysis and examining possible solutions to new problems. For everything else, read Effective Java.

>Prototype Oriented programming is the closest we can currently be to using Lisp like programming.
Lisp is the closest we can currently be to using Lisp-like programming.

GoF design patterns are arguably the most horrendous concept people ever came up with in software history.
They are literally, unironically, workarounds for limitations older versions of C++ had. They teach you how to be a human compiler, not how to actually design software (which, remember, is a mostly language/technology agnostic activity).
You don't even have to look at other languages to see how true that is: even modern C++ and fucking Java 8 and beyond make many patterns in the book completely unnecessary: that's how outdated that is (although "outdated" is not the most accurate word, as there were programming languages that didn't need "patterns" long before GoF was published).
Even when patterns were more popular, every project I've seen using them more religiously ended up heavily tailoring them to the problem at hand (as it should be), therefore defeating the entire point of "design" patterns.
The fundamental problem with GoF "design" patterns is that they don't actually teach you how to design software: they just give you a way to deal with repetition at the language level, but that is simply a symptom of inadequacy of the tools at hand.
A kind of "design patterns" that are actually useful, for a contrasting example, are Cole's parallel algorithmic skeletons: this is because they are language-agonstic and actually help you deal with the problem at hand by decomposing it into phases that have a known, efficient implementation, with formally proven cost estimation models. Even SICP describes a related technique of "sequence operations" at the start of chapter 2. You should read it if you haven't.
Pic not related, Suckless fags know nothing about software design.

Attached: 418964_1.jpg (125x128, 5K)

>"work around limitations" of a language by implementing stuff in that language? usually the only limitation seems to be the person making this claim
Let's take a very basic example first: in machine code and assembly you usually have no native "for" construct: in order to achieve equivalent functionality, you have to explicitly test a condition in an instruction, then write code that will be exexuted if the comparison succeeds, then a jump instruction to the comparison again, then a label with the code that is executed afterwards, and so on. This is all more tedious and error prone than just writing for() {} and be done with it. Yet this very general pattern of iteration is extremely common and having a dedicated language feature to take care of the details is beneficial. You'll agree that the assembly solution is just going through hoops to implement what C gives you for free.
Now for a less orthodox example: try writing a method in Java whose dynamic dispatch depends on more than one argument (including the object it's called on).
You can't do this. The language simply doesn't allow it. You can obtain the same functionality via the visitor pattern, but that has many pitfalls, sich as more boilerplate code obviously, but most importantly the class needs to accomodate for it. You can't just create another visitor class in isolation and be done with it.
If you are honest with yourself, you'll come to the conclusion that all this stuff is just a workaround for the lack of multimethods. In other words, the people claiming design patterns as described in GoF are in fact workarounds for missing language features are correct.

Many people here and everywhere seem to hate them, but the whole idea is to make a quick idea of what your program will look like at a glance. Nothing more.
It is by no means the way you should then make the program though, it is just to have an idea of how to separate behaviour in your design.
The whole idea is to decompose your program into something you can understand, measure the effort and is separated into parts you can actually code and don't lose your mind about the logic.
Now, on a real case scenario, on top of that, you have to apply the context of the logic of the model. Which makes everything exponencially harder if you have no idea on how to separate behaviour properly.

How can i get started on this? I need a job.

OOP -> design patterns
POOP -> streaks
>usually the only limitation seems to be the person making this claim
No, he's right. He just needs to add C++ to the shitpile.
See:

kneepads. You know what to do.

>Service locators
>good

You cannot even begin to imagine the ball of twine I have inherited.

Attached: 1509779838401.jpg (380x380, 168K)

honestly that's just a pile of drivel.
>in machine code and assembly you usually have no native "for" construct
>try writing a method in Java whose dynamic dispatch depends on more than one argument
i don't see how any "try doing this" argument is valid without actual context, what is the application that requires this feature supposed to do?

lack of some feature that you can fairly easily implement in a reusable way (i.e. procedure/macro/method/etc) isn't much of a "limitation", or at least calling it that makes it sound more dramatic than it should be. if you need to iterate, you can still do it with a jump, test and inc/dec

i think you're just completely missing the point what design patterns are supposed to be and your "workarounds for language features" is strawman

>i don't see how any "try doing this" argument is valid without actual context, what is the application that requires this feature supposed to do?
As a practical example, say you're writing a drum synthesizer. The actual sound produced in a single hit can reasonably be assumed to be a function of the specific drum that is being hit, of the stick used and other aspects such as force.
Now, a possible OO approach for the problem is to represent drums and sticks as classes, and use the "sound" function as a method with dynamic dispatch.
Fine. But should this method "belong" to the drum class, or to the stick class? Or to some other class representing additional parameters?
In a language with single dispatch, you're forced to make this choice, which is actually a language-specific detail and has nothing to do with the general problem you're trying to solve. You must choose, then call other methods inside on the arguments in order to obtain this effect, which is similar to what the visitor pattern does, as I previously pointed out. And what if you add other dispatching arguments?
But in a language with multimethods (methods whose dynamic dispatch depends on more than one argument) all these problems are completely avoided. You waste less time adapting the language to your high-level design.
>calling it that makes it sound more dramatic than it should be. if you need to iterate, you can still do it with a jump, test and inc/dec
The lack of a feature (or the lack to define it) in a programming language IS a limitation and an additional complication, as it's yet another barrier between the final running code and your thoughts. The entire point of higher-level tools, languages and features is precisely to reduce these barriers in order to make development easier and more efficient.
The main issue, as I said, is that GoF patterns are in my opinion too language specific, leading them to be inherently limited by said languages, hence their "workaround“ nature.