61–70 of 162 posts
Are books still state of the art in 2017? I would assume all the best knowledge could be found online for free by now.
Earlier quoted context omitted.
Are Design Patterns really so out of fashion with the youth of today that nobody here mentions Design Patterns as their answer? Because it is mine, for better or worse. It took me from understanding OO to understanding how to build large systems with OO, writing maintainable code and using proper encapsulation. A much deeper work than Code Complete (though the latter is worth reading too). I have used functional lang…
I don't think design patterns went out of fashion. I think the opposite happened -- they gained such mindshare that they became a solution looking for a problem for many people. That is, they forgot that design patterns are meant to solve problems, and that you should also only solve problems that actually exist. Instead we started getting things that resembled "Hello World Enterprise Edition" [0], which has been dub…
Earlier quoted context omitted.
> Design patterns exist because common solutions to problems exist, not because OO has serious problems Implementation-recipe design patterns only need to exist (or, rather, only need to be part of the active, day-to-day awareness of more than a small number of programmers per language) when the target language does not support implementing the common solutions as reusable code modules because doing so would require…
Can you provide an example of how a language like C++ or Java would require a "design pattern" when another language wouldn't?
Earlier quoted context omitted.
Are Design Patterns really so out of fashion with the youth of today that nobody here mentions Design Patterns as their answer? Because it is mine, for better or worse. It took me from understanding OO to understanding how to build large systems with OO, writing maintainable code and using proper encapsulation. A much deeper work than Code Complete (though the latter is worth reading too). I have used functional lang…
I'm nearing 50 so I'm hardly a youth. http://www.perlmonks.org/?node_id=133399 does a very good job of explaining why Design Patterns is a book to be careful with. By contrast Code Complete won't steer people wrong. See https://steve-yegge.blogspot.com/2006/03/execution-in-kingdo... for a cautionary tale about how a pursuit of OO purity can result in great verbosity, hiding intent behind a barrage of patterns. Result…
Code Complete, Steve McConnell. http://www.stevemcconnell.com/cc.htm One of the best books on programming style and function, backed up with actual research for the recommendations.
Same opinion. I always recommend it to my programming students. Also, The Pragmatic Programmer is good, for topics both about programming and beyond programming per se.
I'm not sure I would recommend it today, but at the time I read it, in the mid 2000s, it did change my view on these "unmaintainable" technology stacks. I later came across the fusebox architecture/pattern, originally from ColdFusion - and realized that many PHP programmers had skipped some history, ending up reinventing code structure, sometimes badly.
Note that fusebox has grown and changed, I'm mostly talking about the fundamental ideas, and I don't think the later "port" to using XML was a very elegant or good idea. For those interested, see:
https://en.wikipedia.org/wiki/Fusebox_(programming)#Fusebox_... and most of the rest of that page.
As a programmer in training who has both Clean Code and Code Complete in a queue on the edge of my desk, I'm following this thread to decide which goes first, or if they both get sold in mint condition.
Clean code will teach you how writing 3 line functions is a best practice. It's an overhyped, overrated book which is more damaging than helpful and one of the very few I couldn't stand to read until the end due to the authors' dogmatic views.
Earlier quoted context omitted.
I'm nearing 50 so I'm hardly a youth. http://www.perlmonks.org/?node_id=133399 does a very good job of explaining why Design Patterns is a book to be careful with. By contrast Code Complete won't steer people wrong. See https://steve-yegge.blogspot.com/2006/03/execution-in-kingdo... for a cautionary tale about how a pursuit of OO purity can result in great verbosity, hiding intent behind a barrage of patterns. Result…
Agree on both those fronts, if you're not careful. Still dp influenced my coding more than any other book to date, which was the original question.
But then again I'm hardly enthusiastic about OO. See http://www.perlmonks.org/?node_id=318257 for more on my perspective.
It came along at just the right moment in my career, when I was struggling to understand how I could build things in a more elegant way. I picked up the book thinking I was going to learn about some esoteric design pattern, and came away with a much better understanding of the languages I was using and all of the other design patterns I thought I had learned about previously. It's clear, concise, and focuses on concepts over specific tools and libraries, but most importantly it's practical - it has real, practical code examples and explains how to actually build an object-oriented system. It's such a stark contrast with most presentations I've seen of the Gang of Four patterns and of SOLID, which usually come with really weak examples that aren't helpful or motivational.
Everything snowballed from there. I started using composition a lot more than inheritance, I started identifying problems with side effects and eliminating them, I started writing real unit tests, I was able to better critique other peoples' code. I felt like I was finally using the tools available to me in the way they were supposed to be used.
What's funny and satisfying to me is following the author's blog and seeing that he has since moved on to focus primarily on F# and functional programming, which I naturally started to do myself after more practice with the concepts in his book. Once you start decoupling things well, and you've built a few systems big enough that you have trouble finding the actual implementation of your IWhatever and an AbstractSingletonProxyFactoryBean actually does solve your problem pretty well even as you realize the insanity of it, the encapsulating borders of classes and the need to assign everything to a noun start to feel more like a hindrance rather than a guide.
That said, I still think that most of the world's code written in object-oriented languages would be better off if everyone using them had brief, practical training to understand the value of specifying the behavior of an object through the interfaces it depends on, giving it other objects that implement those interfaces right when you create it, and doing all that creation up front (or specifying other objects that can defer that creation to later). I still see so much C# code from developers at all levels who clearly create classes only because the language offers it and it seems like the right thing to do, randomly jamming methods and fields into classes with names vaguely related to the domain, calling static methods to access databases and external services, and proudly adding unit tests for their one loose little function that mushes strings together. I push this book as hard as I can on junior devs.