> only add design patterns if there is a clear and present need. I know what you mean, don't copy the designs explained in design patterns books unless it make

> only add design patterns if there is a clear and present need. I know what you mean, don't copy the designs explained in design patterns books unless it makes sense. But to be clear on the wording, you don't really "add design patterns" ever. Your code is your design, designed by you. If there are recurring "patterns" in your code-solutions and recurring in the sense that others use them too and have documented them, then you can "see patterns" in your code. In other words you can recognize some patterns, some recurring structures in your code. Design Patterns are abstract entities you can not move them around. You can only describe them. Therefore people have tried to write books about them. You can only add code to your source-files, not "patterns". Can you see recurring patterns in your code? Maybe. If you think those recurring patterns are good enough to communicate to others then you may want to write a book or even just an email or HN post about them. The problem I see with the existing design patterns books is that a pattern describes a great solution in a specific context. But contexts vary wildly. Part of the context is the programming language used. They too vary wildly. So I think the basic idea of Design Patterns is great, but in practice their benefit may be limited depending on the generality/applicability and quality of the patterns described, in them books.