Pattern Pathology
来源:互联网 发布:药品数据 编辑:程序博客网 时间:2024/06/13 21:35
Pattern Pathology
Chad LaVigne
Design patterns are one of the most valuable tools available to the software architect. Using patterns allows us to create common solutions that are easier to communicate and understand. They are concepts that are directly associated with good design. This fact can make it very enticing to demonstrate our architectural prowess by throwing a lot of patterns at a project. If you find yourself trying to shoehorn your favorite patterns into a problem space where they don’t apply, you may be a victim of pattern pathology.
Many projects suffer from this condition. These are the projects where you envision the original architect looking up from the last page in his patterns book, rubbing his hands together and saying, “Now, which one will I use first!?”. This mentality is somewhat akin to that of a developer who begins writing a class with the thought “hmmm, what class should I extend?”. Design patterns are excellent tools for mitigating necessary complexity, but like all tools, they can be misused. Design patterns become a problem when we make them the proverbial hammer with which we must strike every nail. Be careful that your appreciation for patterns doesn’t become an infatuation that has you introducing solutions that are more complicated than they need to be.
Stamping patterns all over a project unnecessarily is over-engineering. Design patterns are not magic and using them doesn’t automatically qualify a solution as good design. They are reusable solutions to recurring problems. They have been discovered and documented by others to help us recognize when we’re looking at a wheel that’s already been invented. It’s our job to identify problems solved by these solutions when they arise and apply design patterns appropriately. Don’t let your desire to exhibit design pattern knowledge cloud your pragmatic vision. Keep your sights focused on designing systems that provide effective business solutions and use patterns to solve the problems they address.
Chad LaVigne
Design patterns are one of the most valuable tools available to the software architect. Using patterns allows us to create common solutions that are easier to communicate and understand. They are concepts that are directly associated with good design. This fact can make it very enticing to demonstrate our architectural prowess by throwing a lot of patterns at a project. If you find yourself trying to shoehorn your favorite patterns into a problem space where they don’t apply, you may be a victim of pattern pathology.
Many projects suffer from this condition. These are the projects where you envision the original architect looking up from the last page in his patterns book, rubbing his hands together and saying, “Now, which one will I use first!?”. This mentality is somewhat akin to that of a developer who begins writing a class with the thought “hmmm, what class should I extend?”. Design patterns are excellent tools for mitigating necessary complexity, but like all tools, they can be misused. Design patterns become a problem when we make them the proverbial hammer with which we must strike every nail. Be careful that your appreciation for patterns doesn’t become an infatuation that has you introducing solutions that are more complicated than they need to be.
Stamping patterns all over a project unnecessarily is over-engineering. Design patterns are not magic and using them doesn’t automatically qualify a solution as good design. They are reusable solutions to recurring problems. They have been discovered and documented by others to help us recognize when we’re looking at a wheel that’s already been invented. It’s our job to identify problems solved by these solutions when they arise and apply design patterns appropriately. Don’t let your desire to exhibit design pattern knowledge cloud your pragmatic vision. Keep your sights focused on designing systems that provide effective business solutions and use patterns to solve the problems they address.
- Pattern Pathology
- Pattern Pathology
- In an Age of Images, Teaching Pathology by Hand
- pattern
- pattern
- Pattern
- Pattern
- Pattern
- Pattern
- Pattern
- (?:pattern) (?=pattern) (?!pattern)
- 论文阅读笔记:DeepRadiologyNet: Radiologist Level Pathology Detection in CT Head Images
- 正则表达式之 pattern+?、pattern*?、(?!pattern)、(?:pattern)
- Iterator Pattern & Composite Pattern
- Design pattern----Facade Pattern
- Design pattern----Strategy Pattern
- Design Pattern --------Observer pattern
- Design Pattern --- Factory Pattern
- ActiveSync失败和RTC的关系
- 常规递归和尾递归的性能比较
- 使用OpenCV实现内存中图像数据的RGB-->HSV转换
- XPath 对xml文件操作
- 启动loadrunner的agent时,发现日志中报端口已被占用,启动失败解决办法
- Pattern Pathology
- Beginning Python - Chapter6 : More Abstraction
- iterator/generator 应用举例 Mymap / Myzip
- Python中 内置函数
- sqllite 你懂得 生成db文件
- C读取文件内容
- C#正则表达式整理备忘
- 【smarty项目源码】模拟smarty模版文件的解析过程
- pipe实例