3 ms·

A lot of times partially good ideas get overblown and create "fad shrapnel" where they explode on the scene and get overused and overhyped by the naïve, Resume

by tabtab 5y ago

A lot of times partially good ideas get overblown and create "fad shrapnel" where they explode on the scene and get overused and overhyped by the naïve, Resume Oriented Programmers[1], or book/article pushers. One of the most frustrating things about Design Patterns is that it's never been clear when to use them and when not to. Making a good choice often requires intimately knowing the domain, and guessing the future well. Most us are lousy at predicting the future. If we were any good at it, we'd be golfing with Warren Buffett instead of figuring out why our Java won't compile on a Monday. Their Visitor Pattern scenario is crying out for a database, by the way. Don't reinvent a database in app code: you get spaghetti objects. Apply YAGNI and KISS, and only add design patterns if there is a clear and present need. [1] Buzzword collectors looking for their next gig and (mis) using your business as their personal college or R&D lab.

galaxyLogic 5y ago
> 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.
Aeolun 5y ago
> Their Visitor Pattern scenario is crying out for a database How so? Where you store your data doesn’t matter to your export logic. Whether it retrieves the original data structure from memory or the database doesn’t make a difference to the visitor.

by tabtab 5y ago

galaxyLogic 5y ago

> 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.

Aeolun 5y ago

> Their Visitor Pattern scenario is crying out for a database How so? Where you store your data doesn’t matter to your export logic. Whether it retrieves the original data structure from memory or the database doesn’t make a difference to the visitor.