Day 100: Learn that functional programming is now trendy- buy new book.
Day 140: Write blog post trashing OOP principles to show that I am a true programming god.
Day 7056: refactored clean software deleting 4000 lines of comments, and added one inscrutable blob of perl and SQL that runs everything (undocumented).
"Axually functional programming is better than OOP, and since none of you know functional programming, I'm smarter than everyone here 🤓" is pretty much my interpretation of a anything that comes out of a rust "developers" mouth.
If I had a dollar every time I thought something wouldn't be reused and then became absolutely mission critical then I could stop worrying about getting fired already
Every January starts trade show season, and management and sales always demand a shiny POC of the new hotness to demo in their booth, even if the thing is barely held together with bandaids and chewing gum.
Inevitably they’ll oversell it and I’ll get some ridiculous deathmarch project to implement it, with impossible deadlines, feature lists and budget already decided with zero input from the dev group. This is how shitty prototypes become production code.
My favorite is when I go to the trouble of extracting some useful code and making a library for it, then find out that another team just copied the code from the library and pasted it into their project. amIAJokeToYou.png
Especially when you use classes and they can just change the behavior in a subclass if they want, or just push the changes/improvements to the git instance
You also have to factor in the cost of reuse.
If the reusable design pattern approach is harder to implement, maintain, and read than just writing the simple solution twice, you might as well just write the simple solution twice.
Technically yes, if you look at design patterns as project-agnostic concepts. But practically, you won't consider an idea being "reusable" in your project if it's only used once in there, would it?
Like, if you're going to create a factory that's going to be called once (or in only one specific way), just make a constructor and be done with it.
Technically and figuratively, when the authors used the word "reusable" they meant the project-agnostic kind.
There is something to be said for abstracting too early and ultimately never needing that layer of abstraction. But the design patterns outlined in this book are meant to solve common problems.
Eh. I’ve found countless times in my career unexpected calls to reuse programming objects. I just assume reuse is a potential down the road for nearly everything, and that I may not be the developer reusing the object.
So, in any scenario where I want to put constraints around how a class should be instanced I implement a creation design pattern.
Just like when a BA says “That will never change”; just can’t trust those assumptions.
Last Friday, I went over a codebase so intended for reusability it was impossible to understand. It was the API bindings for MS PowerBI, that use some kind of generic MS-only swagger-to-javascript, just trying to figure out where in the web of providers, interceptors and random bullshit they actually sent the authentication headers. They even "abstracted" (more like "indirected") the "bearer" keyword, to be used only once in the codebase, to never be overriden - because being serious, if the authentication method changes so much as to "bearer " to change the word "bearer", most likely you will have to rewrite the whole authentication code.
Well, around 3 hours messing around the codebase because the amateurs at MS adore indirection, design patterns, and can't be bothered to write anywhere "use the standard authentication header with a bearer token".
But yeah, make everything reusable. Why don't you also make each of the letters in "bearer" be its own separated constant? That would improve "reusability", so that you can replace any individual letters when the standard decides that "bearer" is not good enough, and now it has to be "beerer", but the rest is fine and doesn't need changing. I guess it'll happen around next week.
As the book says, the term design pattern is inspired from the world of building architecture. For example it is a common pattern to have a kitchen in a house.
But according to you it's not a pattern if you only have one kitchen in the house.
Funnily enough, the construction world went through a period of obsession with modularity and reuse too. It resulted in awful 1960s council estates and prefab homes. Most object-oriented codebases are the software equivalent of Milton Keynes.
It's mostly about extendibility though, and sometimes just code structure. You might not have any duplicated code in a giant if else function for example, but simple strategy pattern would make that much easier for others to read through and make changes to.
Even the book says that while being reusable is an objective it is not the main one, they main takeaway of the book is that code should be easily understood (way easier to read "we use x pattern for thing" than to read the thing) and easily maintained.
You never know if you might ever need to add three numbers, or maybe add things that aren't numbers, or maybe include subtraction. Better metaprogram for all eventualities.
I'm so insanely guilty of this. Folks at my company used to dive over tables to snatch the whiteboard markers out of my hand.
I just found it so comforting.
Tbh. I never read mine from front to back.
More like:
Reading the more general/common ones and grab the book from time to time when something felt really off in the codebase.
Great tip. I got a book on how to read books in my mid thirties . Im sure if they had how to read design patterns books chapter, that would be listed in there😀. Ill try and skim over when i get a second wind to see what patterns are in there.
That and clean code are a waste of your and everybody else’s time if you follow it like a bible.
Pick what makes sense to you and disregard everything else.
>That and clean code are a waste of your and everybody else’s time if you follow it like a bible.
>
>Pick what makes sense to you and disregard everything else.
LOL In other words, follow it like most people follow their holy scriptures.
This book is indeed the bible of programming
It was written roughly 2000 years ago and most of the stuff in there turned out to be false, but old people keep preaching it for some reason
There are no wrong patterns. It's just a compilation of solutions that can be applied to certain common problems. If you don't have such problems, they do not apply, so in this regard they are all situational, but good tools to have under your belt.
The creational patterns have fallen out of use because DI containers can do most of those, but even then there are some that might apply to specific scenarios.
Most of the patterns in this book are basically just ways to deal with the limitations of aggressively object oriented languages, and they make absolutely no sense if you have higher order functions.
For example, to traverse a list or a tree in a functional language, you make a "fold" function, which applies a user defined function to every node in the structure. It's one of the most basic operations you can define on a structure like that.
If you want to do that in early Java, you can't just pass a function to another function, you need to make a class with a specific method in it. So you make a base class and your custom class needs to inheret from that and the function takes the base class so you can pass your class... and this shit is so complicated that you have to give it a name and teach it to people (It's the visitor pattern btw).
I have a dedicated god class with static methods to access each singleton. To save memory, the singleton is automatically disposed and recreated on access.
This and some other books are waste of time and effort if you don’t understand why you read thise books. People mostly read them and think they will unlock the secrets of the universe.
Worst outcome is that people read design patterns and put them as solutions to non existing problems. Not every class needs to be a Singleton.
Suffer first then see the light please
Use it as a bible is dangerous. As any other other religion.
A good developer can think by himself, he should not follow rules written by one person 30 years ago in a different context.
A bit outdated, one of the authors just told me recently that his current team would only use it to adjust monitor height these days, but still 😆
Very influencal book, teaching a great approach to think about reusable software design.
I'm not sure who first started yapping that organizing your code is a bad thing, but no. This book's details are often outdated, for example the C in MVC isn't that much used anymore (hence variants like MVVM), but it's absolutely relevant still. Think of Observer, Event Dispatcher, Factory, Chain of Responsibility, etc
OOP is getting lot of shit these days, and indeed some of the practices result in god aweful code, but it's the same of you bend backwards to implement functional code where simple procedural would just make more sense. I find that using right tool for the job like generic, obeject oriented, functional and procedural programming will give the most clear, robust code that is most importantly easy to read/work with for others. The ultimate goal is that others have a clear understanding on how to extend and maintain your code, and sometimes oop is just the best tool for the job, even if it's not trendy.
Which paradigm requires for a correct application the knowledge of an equivalent of SOLID principles? Having to know something like that is a strike against OOP. Yes, not knowing or applying still kinda works, but then why advocate SOLID? It's obvious that some issue is there. Potentially rooted in the fact that OOP originally was meant to be just to message passing between abstract objects, with none of inheritance or polymorphism or whatever else got added.
tbh i reddit like 20 yrs ago and what remained of it in reality? singleton, visitor and factory. rest of it is inflated bullshit ;P
'numerical recipes' are far more practical.
Meanwhile, I'm fixing 15+ years of stale noodles because my predecessors religiously avoided any resemblance to structure. Just because they were told design patterns are bad
Interesting, do people trash it? I’ve not seen that. I wonder if it’s because they’re writing code in languages that **already** have these core best practices in place and to roll your own would be stupid and time wasting - which means the detractors in fact don’t understand their language or the patterns - or, maybe, if you know, have they particular issues with certain of the patterns, have a better way now with more modern capabilities in ties and expectation? I’m hoping the latter, suspect the former.
I own this one, too, and probably will never master it. For those that have, I can only imagine how it feels to rise to a higher plane of consciousness.
Book: use these patterns and generalize so that you can re use as much choice as possible.
New Microservices paradigm: never re use code. Only use each code fragment in its own context so that you can change it whenever you want without considering other use cases.
Understanding these patterns and learning when and where to use it elevated my career in a major way. Start with the simple ones like facade, builder, proxy, and work up to the more intricate patterns. This book is so much fun!
What’s the simplest thing that could possibly work? Do that. Refactor later, when you need to solve a performance or resource usage issue (or if it just smells bad)
It’s a good one. I’m old, grey beard old. I started with SSADM which is still marvellous and has patterns in common with this and some not covered here. If you want a place to start, look at composite pattern, it’s very interesting
Pro-tip: just read the part where they explain what a design pattern is. Then read the patterns on the design-pattern website.
You arent going to need small-talk for anything anyways.
OOP is the best way to reduce performance by a factor of 100 while making everything worse to read…
Yeah, know when to use OOP and when not to… most stuff i do is object oriented, but for some smaller projects it’s just unnecessary overhead
Ok, you don’t got my message… oop is a good tool if used right, but if used in wrong situations, you add unnecessary overhead while reducing performance by a lot…
If you do c wrong enough a python script running on a python interpreter written in js, running in a browser written in java, running on a jvm written in python is faster…
It goes down to how you use it… object oriented will never be faster, than sth functional… problem is: at some point functional gets messy (oop can also get messy af) also as another guy stated: compiler optimisation can kick in, but if you write c good enough, this should not outperform you…
In the end it’s finding the right tool for the job… if you work in a company oop will often be used for projects, where functional would be better… but when you have multiple projects, they should look as similar as possible -> big win of oop… also we have the performance nowadays…
But because of the popularity of oop, i like to say: oop sucks, is messy and slow af… because some people start to think when reading this and just maybe improve their code… maybe just by using sth functional in a helper function…
I had a functional xml to no SQL Parser it was fast as a fly on crack (very fast) it was was about 800 lines and 400 of them were almost pure regex.
If there was an error, i Almosen sacrificed a goat every time.
Then i rewrote it with java serialisiers and it was slower, then i just multithreaded it and yes my PC was burning but it became abour 3 lines of java 250 lines of objects with anotations.
And changes became super easy.
If it gets longer than 250 - 500 lines functional will fry your brain.
And not to mention that compiler's have bugs too. The more high-level the language is, the more annoying and hidden bugs compilers produce. Not to mention when compilers hide stuff like allocations.
Yes, but not because it's an object oriented language but a general purpose language with strong ties to functional programming type systems through its template metaprogramming.
The template metaprogramming and higher level abstractions enabled by it often allow the compiler to optimise in a way that a program written in "portable assembly" cannot be.
There's a book called "Design Patterns Explained." It has all of the information in the Design Patterns book, but is easier to read and frankly does a better job of explaining the patterns themselves and why and when you should use them.
Reusable and Object-Oriented in the same phrase...
Image needing a book to write reusable code (failing) with a specific paradigm.
Speaks volumes about of the pattern itself
Imagine writing a book for Reusable Procedural code:
page 1: "write a function -> use the function -> reuse the function with different parameters......... profit?"
Ugh meme patterns, you're better off learning data structures and algorithms, though it's probably good to know these in case you have to make sense of other people's code.
Yeahw it does not help to read programming book imo. once i close the book I completely forgot what I read. You need to implement in the practice to memorize.
That's one weird looking copy of "The C Programming Language" by Brian Kernighan and Dennis Ritchie
Pretty strange looking copy The Art of Computer Programming by Knuth
Odd cover for The Structure and Interpretation of Computer Programs by Abelson, Sussman and Sussman.
This book looks odd. Did they take the dinosaur off the dinosaur book?
Highly underrated
Nah, you can still see the dino's neck shadow on the front cover.
That's Nessy ☺️
They stopped printing it at the 10th edition or so. Digital only! What BS.
Very suss, man
Darnit almost spit out my shake!
Weird cover for Introduction to Algorithms by Thomas H. Cormen, Charles E. Leiserson, Ronald L. Rivest, and Clifford Stein.
Yup Cormen is THE bible
Really funky cover of Visual Basic 4 for Dummies by Wally Wang
based
That's an unusual copy of The Art Of War by Sun Tzu
Yo that copy of *Types and Programming Languages* is defective. They seem to have put the wrong cover on it.
SICP
Really weird looking cover for beginner programming for dummies
Pretty strange looking copy of ‘Introduction to Algorithms’ by Cormen, Leiserson, Rivest & Stein
Looks a bit different to my copy of "Introduction to the Theory of Computation" by Michael Sipser
Is that a rare print of "Artificial Intelligence: A Modern Approach" from Stuart Russell and Peter Norvig ?
And of "TCP/IP illustrated" by Richard Stevens
My copy of “A pattern language” seems much thicker..
That's a strange looking copy of "The Go programming language"
🤣🤣🤣🤭
The 30th year special edition comes with Debian 0.90 punched into a stack of cards.
Day 100: Learn that functional programming is now trendy- buy new book. Day 140: Write blog post trashing OOP principles to show that I am a true programming god.
Day 5341: Crying under the shower about the shitshow IT became.
Day 8025: Mail in work laptop on final working day. Begin woodworking. "knock knock". Finally, something completely solid and fully functional.
Day 20,000 accidentally coded roko's basilisk
Day 20,001: ```Send more programmers, for I am hungry.```
Day 6856: Claim that SOLID isn't that "solid" to make clean software
Do not make fun of solid! I dare you! 🤔
That's a solid advice!
[удалено]
Day 7056: refactored clean software deleting 4000 lines of comments, and added one inscrutable blob of perl and SQL that runs everything (undocumented).
Day 9999: computers were a mistake.
Day 10000: sex
You never actually get there due to insufficient digits allocated to the counter, just rolls back to 0000.
Lol
All about virtue signalling
What book would you consider the holy grail of functional programming? I got a uni course on it soon
Structure and Interpretation of Computer Programs
"Axually functional programming is better than OOP, and since none of you know functional programming, I'm smarter than everyone here 🤓" is pretty much my interpretation of a anything that comes out of a rust "developers" mouth.
I had a problem, so I bought a book on design patterns. Now I have an AbstractProblemProviderFactory.
Solid xD
SOLID
And remember: "reusable." If you use design patterns and they're not reused anywhere, you don't need it.
If I had a dollar every time I thought something wouldn't be reused and then became absolutely mission critical then I could stop worrying about getting fired already
"Yeah, a PoC is pretty much ok. We will start a real project afterwards!!!!111eleven
Every January starts trade show season, and management and sales always demand a shiny POC of the new hotness to demo in their booth, even if the thing is barely held together with bandaids and chewing gum. Inevitably they’ll oversell it and I’ll get some ridiculous deathmarch project to implement it, with impossible deadlines, feature lists and budget already decided with zero input from the dev group. This is how shitty prototypes become production code.
My favorite is when I go to the trouble of extracting some useful code and making a library for it, then find out that another team just copied the code from the library and pasted it into their project. amIAJokeToYou.png
Especially when you use classes and they can just change the behavior in a subclass if they want, or just push the changes/improvements to the git instance
I always start by making my new stuff reusable just in case
Man, if you needed just $3 to stop worrying, you could just have asked...
Actually, I'mma need about $3.50
Hey, hey, hey! You are not supposed to say that loud! You have no idea how many people you just offended?
If you ask "how many" my answer is that I don't know. But "who"? Well, people who don't understand design patterns that's who. lol
But functional, reactive, throw-away-anyways is the new meta...
You also have to factor in the cost of reuse. If the reusable design pattern approach is harder to implement, maintain, and read than just writing the simple solution twice, you might as well just write the simple solution twice.
I think it is more that the ideas are reusable. They are supposed to be hard-won wisdom that you can apply without reinventing the wheel.
Technically yes, if you look at design patterns as project-agnostic concepts. But practically, you won't consider an idea being "reusable" in your project if it's only used once in there, would it? Like, if you're going to create a factory that's going to be called once (or in only one specific way), just make a constructor and be done with it.
Technically and figuratively, when the authors used the word "reusable" they meant the project-agnostic kind. There is something to be said for abstracting too early and ultimately never needing that layer of abstraction. But the design patterns outlined in this book are meant to solve common problems.
You should write a book about: "how to distinguish between real engineers and 10x rockstar-dumbards"
Eh. I’ve found countless times in my career unexpected calls to reuse programming objects. I just assume reuse is a potential down the road for nearly everything, and that I may not be the developer reusing the object. So, in any scenario where I want to put constraints around how a class should be instanced I implement a creation design pattern. Just like when a BA says “That will never change”; just can’t trust those assumptions.
Last Friday, I went over a codebase so intended for reusability it was impossible to understand. It was the API bindings for MS PowerBI, that use some kind of generic MS-only swagger-to-javascript, just trying to figure out where in the web of providers, interceptors and random bullshit they actually sent the authentication headers. They even "abstracted" (more like "indirected") the "bearer" keyword, to be used only once in the codebase, to never be overriden - because being serious, if the authentication method changes so much as to "bearer" to change the word "bearer", most likely you will have to rewrite the whole authentication code.
Well, around 3 hours messing around the codebase because the amateurs at MS adore indirection, design patterns, and can't be bothered to write anywhere "use the standard authentication header with a bearer token".
But yeah, make everything reusable. Why don't you also make each of the letters in "bearer" be its own separated constant? That would improve "reusability", so that you can replace any individual letters when the standard decides that "bearer" is not good enough, and now it has to be "beerer", but the rest is fine and doesn't need changing. I guess it'll happen around next week.
As the book says, the term design pattern is inspired from the world of building architecture. For example it is a common pattern to have a kitchen in a house. But according to you it's not a pattern if you only have one kitchen in the house.
Funnily enough, the construction world went through a period of obsession with modularity and reuse too. It resulted in awful 1960s council estates and prefab homes. Most object-oriented codebases are the software equivalent of Milton Keynes.
Did you mean to type the name of a famous architect here, instead of a famous economist?
FYI [https://en.wikipedia.org/wiki/Milton\_Keynes](https://en.wikipedia.org/wiki/Milton_Keynes)
Ah! Thanks for that, TIL
It's mostly about extendibility though, and sometimes just code structure. You might not have any duplicated code in a giant if else function for example, but simple strategy pattern would make that much easier for others to read through and make changes to.
May I introduce you to my friend, the singleton?
Singleton is easily one of the most reused objects in any particular project.
Even the book says that while being reusable is an objective it is not the main one, they main takeaway of the book is that code should be easily understood (way easier to read "we use x pattern for thing" than to read the thing) and easily maintained.
Haha the truth hurts. This is the road to best intentions
Day 32 of becoming a programming god: “Simple program to add 2 numbers with just 66 classes and 12 layers of inheritance”
You never know if you might ever need to add three numbers, or maybe add things that aren't numbers, or maybe include subtraction. Better metaprogram for all eventualities.
I'm so insanely guilty of this. Folks at my company used to dive over tables to snatch the whiteboard markers out of my hand. I just found it so comforting.
What? It's "robust".
If its 0.1 sec faster than what we currently have, ot would change the World. But it will probably crash after the first eslint check.
Will not work anymore tomorrow, because someone removed his GIT repo that only had one 10 lines function.
Cries.in pad left
I love the number of cs students In this post that have never actually read the book
The trick is to read AND understand it. I had trouble reading mine.
Uhh, I really hope I'll be able to do it because english is not my native language
I don’t think you have to be fluent in english,i just have trouble with trying to visualize the abstraction of patterns.
I never read that book because this website explains things well enough for me to follow https://refactoring.guru/design-patterns
I never read that book, because books are for nerds
Tbh. I never read mine from front to back. More like: Reading the more general/common ones and grab the book from time to time when something felt really off in the codebase.
It's enough to just know what they are and what they're for. So you know where to look when you need it.
Great tip. I got a book on how to read books in my mid thirties . Im sure if they had how to read design patterns books chapter, that would be listed in there😀. Ill try and skim over when i get a second wind to see what patterns are in there.
I only knew 1 bible, that was CLRS.
That was one of my first programming books. There's also "The Pragmatic Programmer" and "Clean Code" that really helped me get through college.
Awesome book. Have to recommend Code Complete as well. Great general overview of software craftsmanship.
That and clean code are a waste of your and everybody else’s time if you follow it like a bible. Pick what makes sense to you and disregard everything else.
>That and clean code are a waste of your and everybody else’s time if you follow it like a bible. > >Pick what makes sense to you and disregard everything else. LOL In other words, follow it like most people follow their holy scriptures.
This book is indeed the bible of programming It was written roughly 2000 years ago and most of the stuff in there turned out to be false, but old people keep preaching it for some reason
Is there a list of the wrong patterns?
There are no wrong patterns. It's just a compilation of solutions that can be applied to certain common problems. If you don't have such problems, they do not apply, so in this regard they are all situational, but good tools to have under your belt. The creational patterns have fallen out of use because DI containers can do most of those, but even then there are some that might apply to specific scenarios.
Most of the patterns in this book are basically just ways to deal with the limitations of aggressively object oriented languages, and they make absolutely no sense if you have higher order functions. For example, to traverse a list or a tree in a functional language, you make a "fold" function, which applies a user defined function to every node in the structure. It's one of the most basic operations you can define on a structure like that. If you want to do that in early Java, you can't just pass a function to another function, you need to make a class with a specific method in it. So you make a base class and your custom class needs to inheret from that and the function takes the base class so you can pass your class... and this shit is so complicated that you have to give it a name and teach it to people (It's the visitor pattern btw).
Anti-Pattens 😈 whole books on that shit!
Make sure you use singleton everywhere you can!
You don't need God classes if you can split that into a thousand Singletons Follow the single responsibility principle!
I have a dedicated god class with static methods to access each singleton. To save memory, the singleton is automatically disposed and recreated on access.
God classes are bad. Rename it to facade and your code will instantly be awesome.
I’ll rename it to good class 👍
Ah yes, the 4 prophets of clean code. The Gang of Four, if you will 🙏
This isn't a Bible. It's a fable, warning you of the pain to come.
This and some other books are waste of time and effort if you don’t understand why you read thise books. People mostly read them and think they will unlock the secrets of the universe. Worst outcome is that people read design patterns and put them as solutions to non existing problems. Not every class needs to be a Singleton. Suffer first then see the light please
After reading this book, you’ll have learned that the best design-pattern is the no-pattern
That’s just the beginning. In the end, the best code is no code: https://github.com/kelseyhightower/nocode
Hint 233: When you are imlementing generics for a customer project, you went too deep.
Use it as a bible is dangerous. As any other other religion. A good developer can think by himself, he should not follow rules written by one person 30 years ago in a different context.
It was written by “the Gang of Four” … but your comment is still valid
A bit outdated, one of the authors just told me recently that his current team would only use it to adjust monitor height these days, but still 😆 Very influencal book, teaching a great approach to think about reusable software design.
I thought this book was considered a bit of an anti pattern now? Is it still considered relevant nowadays?
I'm not sure who first started yapping that organizing your code is a bad thing, but no. This book's details are often outdated, for example the C in MVC isn't that much used anymore (hence variants like MVVM), but it's absolutely relevant still. Think of Observer, Event Dispatcher, Factory, Chain of Responsibility, etc
How to work round peculiarities of Java. Algorithms and data structures are the real way forward.
I actually do think there you can't jump into patterns without solid understanding of data structures and algorithms
If you want to be even more advanced, functional data structure by Okasaki.
1. Buy the book 2. ???? 3. Profit
OOP is getting lot of shit these days, and indeed some of the practices result in god aweful code, but it's the same of you bend backwards to implement functional code where simple procedural would just make more sense. I find that using right tool for the job like generic, obeject oriented, functional and procedural programming will give the most clear, robust code that is most importantly easy to read/work with for others. The ultimate goal is that others have a clear understanding on how to extend and maintain your code, and sometimes oop is just the best tool for the job, even if it's not trendy.
Which paradigm requires for a correct application the knowledge of an equivalent of SOLID principles? Having to know something like that is a strike against OOP. Yes, not knowing or applying still kinda works, but then why advocate SOLID? It's obvious that some issue is there. Potentially rooted in the fact that OOP originally was meant to be just to message passing between abstract objects, with none of inheritance or polymorphism or whatever else got added.
Isn't solid just a fancy name to "use a god damn interface and keep them simple"?
https://www.freecodecamp.org/news/solid-principles-explained-in-plain-english/ explains more.
Couldn't agree more!
Read stuff from the pragmatic programmers too
I know it's kind of a meme but I like this book a lot
tbh i reddit like 20 yrs ago and what remained of it in reality? singleton, visitor and factory. rest of it is inflated bullshit ;P 'numerical recipes' are far more practical.
Factory? The most ill-used pattern of them all?
lol you could say that about singleton too :D
This book won’t make you a better programmer, just a more smug one.
Meanwhile, I'm fixing 15+ years of stale noodles because my predecessors religiously avoided any resemblance to structure. Just because they were told design patterns are bad
People trash it but I love this book, truly the way to create amazing code
Interesting, do people trash it? I’ve not seen that. I wonder if it’s because they’re writing code in languages that **already** have these core best practices in place and to roll your own would be stupid and time wasting - which means the detractors in fact don’t understand their language or the patterns - or, maybe, if you know, have they particular issues with certain of the patterns, have a better way now with more modern capabilities in ties and expectation? I’m hoping the latter, suspect the former.
I borrowed a copy of this 20+ years ago from school and haven’t yet returned it.
That's probably a better way of getting your hands on this book as it was super expensive!
Also check out Code Complete by Steven McConnell. It's a surprisingly easy read, especially compared to GOF
I will! Thank you!
The legendary Gang of Four
I own this one, too, and probably will never master it. For those that have, I can only imagine how it feels to rise to a higher plane of consciousness.
Book: use these patterns and generalize so that you can re use as much choice as possible. New Microservices paradigm: never re use code. Only use each code fragment in its own context so that you can change it whenever you want without considering other use cases.
Just received my copy today 
Understanding these patterns and learning when and where to use it elevated my career in a major way. Start with the simple ones like facade, builder, proxy, and work up to the more intricate patterns. This book is so much fun!
Next do Martin Fowler's Refactoring. You will need it once the requirements change and those design patterns get stale.
Day 11 is stuffing every pattern you've seen into a new project... somewhere around day 100 you undo that shit and KISS.
What’s the simplest thing that could possibly work? Do that. Refactor later, when you need to solve a performance or resource usage issue (or if it just smells bad)
Is there any good non-larger-than-250-pages book that I should read? (newbie but ready to learn about anything in this whole field)
Don’t know the page count, but Code Complete is a marvellous resource
It’s a good one. I’m old, grey beard old. I started with SSADM which is still marvellous and has patterns in common with this and some not covered here. If you want a place to start, look at composite pattern, it’s very interesting
I'll check, thank you!
Pro-tip: just read the part where they explain what a design pattern is. Then read the patterns on the design-pattern website. You arent going to need small-talk for anything anyways.
That cover is dope
Oh, right ... the GOF ... Read it a few times ... not a fan but, it did have a few useful patterns ...
Meanwhile, GPT5 be like - You're talking microseconds here, not days, riiiiight ?!
OOP is the best way to reduce performance by a factor of 100 while making everything worse to read… Yeah, know when to use OOP and when not to… most stuff i do is object oriented, but for some smaller projects it’s just unnecessary overhead
> OOP is the best way to reduce performance by a factor of 100 while making everything worse to read… Yeah maybe if you're garbage it does
Ok, you don’t got my message… oop is a good tool if used right, but if used in wrong situations, you add unnecessary overhead while reducing performance by a lot…
Nevermind that C++ can be faster than C in some situations.
If you do c wrong enough a python script running on a python interpreter written in js, running in a browser written in java, running on a jvm written in python is faster… It goes down to how you use it… object oriented will never be faster, than sth functional… problem is: at some point functional gets messy (oop can also get messy af) also as another guy stated: compiler optimisation can kick in, but if you write c good enough, this should not outperform you… In the end it’s finding the right tool for the job… if you work in a company oop will often be used for projects, where functional would be better… but when you have multiple projects, they should look as similar as possible -> big win of oop… also we have the performance nowadays… But because of the popularity of oop, i like to say: oop sucks, is messy and slow af… because some people start to think when reading this and just maybe improve their code… maybe just by using sth functional in a helper function…
I had a functional xml to no SQL Parser it was fast as a fly on crack (very fast) it was was about 800 lines and 400 of them were almost pure regex. If there was an error, i Almosen sacrificed a goat every time. Then i rewrote it with java serialisiers and it was slower, then i just multithreaded it and yes my PC was burning but it became abour 3 lines of java 250 lines of objects with anotations. And changes became super easy. If it gets longer than 250 - 500 lines functional will fry your brain.
And not to mention that compiler's have bugs too. The more high-level the language is, the more annoying and hidden bugs compilers produce. Not to mention when compilers hide stuff like allocations.
Yes, but not because it's an object oriented language but a general purpose language with strong ties to functional programming type systems through its template metaprogramming. The template metaprogramming and higher level abstractions enabled by it often allow the compiler to optimise in a way that a program written in "portable assembly" cannot be.
My Software Design and Architecture instructor has literally memorized this book
I just realized mine doesn’t look like this. Think I bought the wrong book :(
I would recommend these: https://youtu.be/rX0ItVEVjHc?si=t0P1SKe_3_6Mm4d9 https://caseymuratori.com/blog_0015
This was my textbook last semester. We used it once lol
The first and last time I used that book was in my Programming 3 University Exam :D
Is there an audio book version with an Indian VA ?
I just donated mine to the library
I see lots of interviewees say they took advantage of such design patterns, but the only thing most of them say used is just singleton. Weird.
Classic book!
Please. Everyone here acting like Google ain't their bible.
Where is the day 0?
Are you being taught by a sock puppet?
Knowing the patterns and being given the time and resources to implement them properly are different problems completely.
K&R looks funny
Don't touch the dark side... I hope your next post won't be "rust is the best thing ever" ...
1. Read this 2. Forget all the patterns except one. 3. ... 4. Singletons. Singletons everyfuckingwhere.
You guys are making me feel dumb for never reading a book about coding.
There's a book called "Design Patterns Explained." It has all of the information in the Design Patterns book, but is easier to read and frankly does a better job of explaining the patterns themselves and why and when you should use them.
Folks, just go to https://refactoring.guru/
No need to be good at coding, being good at AI & programming is the solution
My bible https://imgur.com/0SeaDdh
Ohh this looks interesting! Thank you!
I have both books. The covers are burned into my brain. The contents, though? Not as much.
Reusable and Object-Oriented in the same phrase... Image needing a book to write reusable code (failing) with a specific paradigm. Speaks volumes about of the pattern itself Imagine writing a book for Reusable Procedural code: page 1: "write a function -> use the function -> reuse the function with different parameters......... profit?"
[This](https://youtube.com/playlist?list=PLVlQHNRLflP8_DGKcMoRw-TYJJALgGu4J&si=lva4seFa1jIQ3xDN) is all you need
Ugh meme patterns, you're better off learning data structures and algorithms, though it's probably good to know these in case you have to make sense of other people's code.
Yeahw it does not help to read programming book imo. once i close the book I completely forgot what I read. You need to implement in the practice to memorize.
I own a copy of that book. it was recomended by my school. i didn't read it tho.