欢迎来到天天文库
浏览记录
ID:52519885
大小:470.37 KB
页数:16页
时间:2020-03-28
《软件架构师-拥抱着变化而设计(内部培训讲义片段).pdf》由会员上传分享,免费在线阅读,更多相关内容在教育资源-天天文库。
1、1.3拥抱着变化而设计防止软件退化最重要的工作就是要有良好的设计,那么什么是好的设计?所谓“合适的就是最好的”,那么什么是“合适”?合适,就需要对客户需求作更深入的分析,通过挖掘潜在的需求,找到设计中的关键点,特别是对于面向对象的分析和设计(OOAD)来说尤其重要。一、面向对象分析与设计的本质1,结构化设计思维及其缺陷软件设计思维的早期是以结构化为核心的。结构化思维最本质的东西就是功能分解:这是一种处理复杂问题的自然方法,其原因在于解决更小的问题,比解决整个问题更简单,它通常形成的结构,是让一个“主”程序(模块)负责控制子
2、程序(模块),但这样一来,就造成了如下缺点:主模块所承受的责任太多、太集中,承受的压力相当大;经常会产生非常复杂的代码,而且互相间的耦合很严重。正是由于这样的特征,结构化应对变化的能力很差。但是在现实世界中,变化总是无法避免的,例如,要为已有的主题增加新的变体,需要新的业务方法等。如果将实现业务各步骤的所有逻辑代码,按照自然方式放在一个模块中的话,那么这些业务任何实质性的变化,都会造成对这些模块进行大面积修改。2,需求总是会发生变化1)需求变更不可避免问问软件开发人员,对于从用户那里获取的需求,他们认为有哪些说法正确的
3、?我相信经常得到的回答是这样的:需求是不完整的。需求经常是错误的。需求(和用户)容易让人误解。需求并不会告诉你全部情况。只有一种问答是听不到的:“我们的需求不仅完整、清晰、易于理解,而且还说明了我们今后五年需要的所有功能!”即使前期我们确实耗费了极大的努力来收集需求,这样的需求还是会发生变化。2)需求变化的原因需求变更的根源,除了需求获取和分析的能力之外,关键之处还有如下几个简单原因:用户对自己需求的看法,会因为后期获取信息越来越多,特别是在开发过程中与开发人员的讨论,以及看到软件新的可能性而发生变化。开发人员
4、自己对用户问题领域的看法,会在开发这个领域的软件过程中,因为对它更加熟悉而发生变化。最重要的原因:我们是人,只要有可能,我们总是希望做到最好,或者得到更好的东西。在多年编写软件的经历中,我认为应该教会我们最主要的一点就是:需求总在变化。大多数开发人员都认为需求变化是一件坏事。但是很少有人去认真设计可以很好处理需求变更的结构,这就使问题变得越来越严重。现实情况确实是需求总是在变化,但这并不意味着我们可以不去收集好的需求。良好的需求可以保证不至于由于当初需求的缺失而发生不应有的变化。但是,我们也不应该不正视那些自然而然会发生
5、的事情。与其抱怨需求总是变化,还不如适应这种变化,这就是“拥抱着变化而设计”。3,赋予职责:易于应对变化的结构从设计的角度,能适应需求变化的设计原理是什么呢?1)需要判断需求会在哪里变化关键之处在于:我可能无法知道什么将会变化,但是我能够猜到在哪里会变化。如果我们在分析中就能注意到这一点,就可以利用面向对象设计的巨大优点,封装这些变化区域,从而更容易地将代码与变化产生的影响隔离开来。2)分离职责就是分离变化为了理解这一点,我们可以从其它的领域来获取思想。当我们在管理一个项目,要为团队分配任务的时候可以有两种做法:第一种方
6、法:你是全权负责的领导,直接给每个人都提供详细的指示。在这个情况下,你必须密切关注大量细节,团队所有人必须按你的指示行事,而且团队除你之外没有其他人负责。在项目非常庞大并存在变化的时候,你会不会疯掉?这就是垂直管理模型,也是结构化的特征。第二种方法:你只给出通用的提示,给每个人分配职责,然后期待每个人会自己弄清怎样完成任务。你只是负责各个职责之间的协调,团队中每个人都知道这个职责的目标,并按照他们自己熟悉的方式行事。在项目非常庞大并存在变化的时候,你是什么样的感觉?这就是水平管理模型,也是面向对象的特征。这其中最大的区别
7、就是责任的转移。在第一种情况下,你要对一切负责;而在第二种情况下,人们对自己的行为负责。这两种情况下,要实现的目的相同,但组织方式差异很大。当情况发生变化的时候,在第一种方法中,大量的指示修改可能会耗用你大量的精力而望而却步。在第二种方法中,你首先定义好相互间的接口,然后与担负相关职责的人交流,请他们再通过互相交流来自主找到解决方案,这往往更能应对变化。3)面向对象的三个视角既然软件是一种思维,那么我们的软件设计思维中又从中吸取到什么营养呢?面向对象的思想正是在这种对于实践的思考中发展起来的,它的核心就是赋予职责,我们可以
8、站在三个视角来看待职责问题:“概念”的视角:呈现所研究领域中的各种概念,回答软件要负责什么的问题。“规约”的视角:关注软件的接口,而不是实现,回答怎么使用软件的问题。“实现”的视角:构建合理的结构,回答软件怎样履行自己职责的问题。由于“实现”被隐蔽在“规约”之后,当履行职责的方式发生变化时,并不会
此文档下载收益归作者所有