81–90 of 162 posts
Thinking Forth; Software Tools; SICP; Abstraction and Specification in Program Development; Essentials of Programming Languages; Paradigms of AI Programming; I'd like to list something about OO too, but no book I know really measures up to learning from other programmers. But there's Mark S. Miller's thesis Robust Composition. (in roughly chronological order. As you can see from the chronology, it took me a long time…
Earlier quoted context omitted.
Design patterns exist because common solutions to problems exist, not because OO has serious problems. I understand both paradigms and Lisp is hardly free of design patterns. Every time you pass a lambda to a higher order function you're using a strategy pattern. If you only see design patterns as problems with OO, you're missing the point of design patterns. All languages have design patterns. Common design pattern…
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…
DP are oft misused, but I think the main idea is a pattern language - a way to communicate to other developers what the architecture is. This is especially important on larger, more complex projects with more developers and developer turnover. Understanding the architecture of a project is crucial for grokking it, but usually not well documented. Even just "DPs are naming conventions" is helpful in this regard.
I really disagree with the idea that most DPs are particularly clever or helpful - they are just the way you'd end up solving those kinds of problems yourself. If you look at your own pre-DP code, you'll see design patterns. What they give is a standardized terminology ("pattern language").
Sometimes an architecture seems more complex than necessary, but makes sense as you better understand the whole problem. e.g. how curl handles http. e.g. youtube-dl. (for me, when I reverse-engineered mini-versions of them, then studied their source)
tl;dr "DPs are docs"
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?
The Command pattern, in its most basic form, could also be considered as implementing 1st class functions by wrapping them into objects.
So if you're using a functional langage, there's a good chance you're wondering why consider both of the above as "design patterns", as you're seing them as basic things, and the compiler implements them for you.
Clean Code by Robert C. Martin This helped me break my analysis paralysis when it came to figuring out how to organize my code.
The examples are written in Java but it doesn't matter too much as most concepts covered in the book are language agnostic.
Hands-down, Practical Object-Oriented Design in Ruby ( http://www.poodr.com/ ) - some of it I don't agree with but it's all wonderfully put-together: clear and concise, with wonderful examples. Much more about OO design than Ruby, non-Rubyists will get 98% of the value out of it that Rubyists would.
Her books and her talks had the biggest influence on me regarding code design. At least influenced to think a lot more about it.
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.
Code complete is a classic. 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.