what's your favorite design pattern, /g/?mine is facade or strategy
>>108781226Most of these things a talented programmer will just implement naturally. I hate “Design Pattern” niggers so much, weird cult who attached themselves to Java in the early 2000s.
>>108781226Sorry I only use anti-patterns
don't be a parrot op. create your own patterns. think for yourself. don't live someone else life ffs
>>108781239FPBPit's genuinely hard to know which "Pattern" is best to implement into the software without making it into spaghetti code. Same thing with these dogshits known as "Micro-Services" and "Reactive Programming".Combine all of the above with vibe coding and you got yourself an unmaintainable clusterfuck of a program
>>108781295These are newer nuisances. I’m haunted by “Reusable Enterprise Java beans”. Reuse? Never once!
>>108781310and how about reusable classes for said software?you wouldn't reuse someone's mystery undocumented code, unless you're forking said project, would you?
>>108781239>>108781289The point of design patterns is communication. Instead of saying "I encapsulated these two classes inside a new class which shares the same interface" you say "I wrote a facade".Most of these patterns are idiotic, though.
>>108781239True.
>>108781289>don't be a parrot op. create your own non-round wheels. think for yourself. don't live someone else life ffs
>>108781226my favorite design pattern was the mementoalthough we implemented it in a totally different way i recognized it
>>108781617yes. create your own wheels. allocate manually your memory. embrace state mutation. embrace null terminated signs. make your own naming convention. format code in your own way. see how far can you go before it starts to get unwieldy and brittle. your own experience is the best teacher. introduce bus. eperience segfaults. embrace FAFO. grow some balls. live free or die.
I like indenting my code, it makes it readable
>>108781226I only recently realized that dependency injection means function argument are the rest of the design patterns similar bullshit?
>>108781723>dependency injection means function argument are the rest of the design patterns similar bullshit?wut?
>>108781226I'm a big fan of the visitor
>>108781226"Design Patterns" are not actually good. They exist largely to help wagies refactor old code bases into forms other wagies can recognize and read. Outside that use-case, they don't really have a purpose.If you find yourself reaching for any of the patterns in this specific book, what has actually happened is that your program has scaled to a level of complexity/size that OOP is not well suited to and you should consider using a different language. The only reason to care about this book is if you are a wagie tasked with refactoring some legacy code base for other wagies. You're just kind of torturing your code into silly shapes to cope with the fact that OOP is not the correct tool for your project.
>>108781391ok except one of these is only understandable to someone who hasn't wasted time memorizing names of design patterns
>>108781226Some times I look at my code and think "hmmm, this could use the prototype pattern"
>>108781226Adapter pattern master race.
>>108781391>Instead of saying "I encapsulated these two classes inside a new class which shares the same interface" you say "I wrote a facade".but then they will ask you>wtf you mean by I wrote a facadeat which point you will reply>I encapsulated these two classes inside a new class which shares the same interfaceafter all these years the only useful "design pattern" I've encountered and go out of my way to teach newfags is dependency injection. everything else is just overly anal retroactive taxonomy
>>108782163>Adapter pattern>look inside>it's literally just a wrapper
>>108781723>dependency injection means function argumentwhat if your dependency is a string? or a file pointer? or an abstract observer base interface factory?
>>108781226Are your factories carbon-neutral?
>>108781723>I only recently realized that dependency injection means function argumentLow IQ take that's been making the rounds recently. DI as a pattern shows its true benefits when it comes to object composition.
>>108781239>a talented programmer*any programmer with enough time and frustration there's usually only so many ways to skin the cat and sufficient bashing of the head against the nearest wall will usually recover most of them eventually
>>108782227it's just a generally useful trick to solve chicken and egg problems of many varieties
>>108781990The book is descriptive, not prescriptive. The authors write about and categorize the recurring patterns that arose spontaneously across various codebases, as solutions to specific problems that various developers faced.Treating the book as prescriptive (ie "this is what you should be doing") just leads to clusterfucked codebases a la Enterprise grade FizzBuzz
I once had an interview where my interview ask me about design patterns and which ones I knew, than proceeded to claim Rails's ActiveRecord is a design pattern too. This is what we're dealing with.
>>108781226Yes.
All design patterns are pointless if your intent isn't to write good code but code to just meet functional requirements.
>>108781226The thing that gets me is there are probably a large number of similarly simple patterns that nobody has named yet (or will ever name). And probably many would be very useful to think in terms of. My feeling is some organization or community should deliberately try to map the space of all used patterns, and perhaps the space of all possible patterns -- at least try to glean something from that space. Probably something about assigning integers to sequences of integers, and developing a maximally expressive vocabulary to shorten the length of sequences the most for common expressions, or something
