However, if the reason is only hypothetical, don't add the pattern. If you have a practical need to support change in a design today, go ahead and employ a pattern to handle that change. Developers naturally love to create beautiful architectures that are ready to take on change from all directions. In other words, when a simpler solution without the pattern would be better.ĭesign patterns are powerful, and it's easy to see all kinds of ways they can be used in your current designs. So when do you remove a pattern? When your system has become complex and the flexibility you planned for isn't needed. You'd think it was blasphemy! Nah, we're all adults here, we can take it. No one ever talks about when to remove a pattern. That said, sometimes the best way to keep your design simple and flexible is to use a pattern. Other developers will appreciate and admire the simplicity of your design. Your goal should be simplicity, not "how can I apply a pattern to this problem." Don't feel like you aren't a sophisticated developer if you don't use a pattern to solve a problem. Here are some quotes from pages 594 and 595 of this 629 page book:įirst of all, when you design, solve things in the simplest way possible. I'm beginning to wonder if the book Head First Design Patterns would be better titled Ass Backwards Design Patterns.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |