谈谈架构设计的思维方式
来源:互联网 发布:淘宝如何申请假冒品牌 编辑:程序博客网 时间:2024/05/22 15:20
刘润最近在blog有一篇非常棒的文章(至少我很喜欢):《形象化的能力》。今天我这篇就算是"形象化"(Visualize)能力的应用吧。
任何解决方案都是由问题、以及问题所处的上下文决定的。熟悉设计模式的人可能会立即想到Christopher Alexander在其著作《模式语言》一书中为"模式"下的著名定义:
每个模式都是一个法则,有三部分组成。它表现的是一种特定的上下文、一个问题和一个解决方案之间的关系。
举个例子,把适配器(Adapter)设计模式的思维形象化表达出来。下图以"上下文-问题-解决方案"的形式对Adapter模式进行了归纳:设计所面临的问题来自我们希望使用某接口不兼容的类(或子系统)之时,而问题的上下文是这个接口不兼容的类是我们无法改变或不应改变的;最终通过"将无法修改的类(或子系统)封装成我们所需的接口"这样的设计解决了我们的问题,并且也符合上下文的限制性要求。
其实,生活中的例子更多。问题:需要一台电脑。理想化解决方案:买一台新的。上下文:资金有限。实际解决方案:买个二手的或者租一台。"头痛医头,脚痛医脚"、"囫囵吞枣"等成语典故也是对片面解决方案的讽刺。
更广泛、更实际而言,还有文化这只无形的大手的深刻影响。
无需多说,看下面两则新闻。都是采取了"将照片公开"的"解决方案",反响却很不同,这和文化不无关系:
女子地铁遭遇性骚扰 拍下色狼照片挂网上受质疑
纽约女子遭性骚扰网上公布色狼照片成民权英雄
运用"上下文-问题-解决方案"思维也有助于理解《软件架构为谁而设计》的内容。总之,软件架构设计不能忽略"上下文"。所谓"上下文"就是和我们要解决的问题密切相关的一些条件和因素,既包括有利条件,也包括限制因素。简言之,上下文就是环境。进行设计时,只有充分利用有利条件、合理回避限制因素,最终的解决方案才是真正符合实际的。
对此,温昱的《软件架构设计》一书(已经交稿)有更多论述,毕竟,对需求分类、需求权衡、需求变化的深入研究,是软件架构师的"第一项修炼"。
Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=1411609
- 谈谈架构设计的思维方式
- 谈谈架构设计的思维方式
- 谈谈架构设计的思维方式
- 谈谈架构设计的思维方式
- 谈谈架构设计的思维方式
- 谈谈多线程的思维方式
- 谈谈多线程的思维方式
- 谈谈UI架构设计的演化
- 谈谈UI架构设计的演化
- 转:谈谈UI架构设计的演化
- 谈谈UI架构设计的演化
- [UI架构]谈谈UI架构设计的演化
- 设计与思维方式的改变
- 架构设计和概要设计的思维导图
- 谈谈游戏服务器架构设计
- 谈谈 etcd 架构与设计
- 谈谈我对协议栈设计和架构的理解
- 谈谈UI架构设计的演化mvc-mvp-mvvm
- 子系统不同,架构不同
- 超越设计模式
- 软件架构为谁而设计
- 一图千言的最佳案例:框架vs.架构
- 软件架构的精髓:协作(Booch语)
- 谈谈架构设计的思维方式
- 新书快评:脚本驱动的“故事”
- 《软件架构设计》内容简介
- 温昱眼中的2006中国软件大会
- 小故事:趣话模式
- 1月13日“微软卓越工程师”免费讲座(讲师:温昱)
- 横切竖割话需求
- 6月8日14:00,温昱谈“软件架构设计智慧之旅”
- 《软件架构设计》一书目录