[软件架构之美05架构解剖欣赏.pptVIP

  1. 1、本文档共84页,可阅读全部内容。
  2. 2、原创力文档(book118)网站文档一经付费(服务费),不意味着购买了该文档的版权,仅供个人/单位学习、研究之用,不得用于商业用途,未经授权,严禁复制、发行、汇编、翻译或者网络传播等,侵权必究。
  3. 3、本站所有内容均由合作方或网友上传,本站不对文档的完整性、权威性及其观点立场正确性做任何保证或承诺!文档内容仅供研究参考,付费前请自行鉴别。如您付费,意味着您自己接受本站规则且自行承担风险,本站不退款、不进行额外附加服务;查看《如何避免下载的几个坑》。如果您已付费下载过本站文档,您可以点击 这里二次下载
  4. 4、如文档侵犯商业秘密、侵犯著作权、侵犯人身权等,请点击“版权申诉”(推荐),也可以打举报电话:400-050-0827(电话支持时间:9:00-18:30)。
  5. 5、该文档为VIP文档,如果想要下载,成为VIP会员后,下载免费。
  6. 6、成为VIP后,下载本文档将扣除1次下载权益。下载后,不支持退款、换文档。如有疑问请联系我们
  7. 7、成为VIP后,您将拥有八大权益,权益包括:VIP文档下载权益、阅读免打扰、文档格式转换、高级专利检索、专属身份标志、高级客服、多端互通、版权登记。
  8. 8、VIP文档为合作方或网友上传,每下载1次, 网站将根据用户上传文档的质量评分、类型等,对文档贡献者给予高额补贴、流量扶持。如果你也想贡献VIP文档。上传文档
查看更多
[软件架构之美05架构解剖欣赏

架构示意图 代码质量三要素:可读、可维护、高效率 1.可读性 规范而且好看 2.可维护性 可读性支撑了可维护性,但进一步要求代码易于维护、易于变更 3.高效率 在关键应用场景中,我们要关注代码效率 1.类组织元素声明 2.必要的属性及变量 2-1:去掉没必要的属性变量。 2-2:仔细定义并明确属性变量的含义、作用、取值范围及属性变量间的关系。 2-3:明确属性变量与操作此属性变量的方法的关系,如访问、修改及创建等。 2-4:当向属性变量赋值时,要十分小心,防止赋与不合理的值或越界等现象发生。 2-5:防止局部变量与属性变量同名。 2-6:给所有变量赋初始值 2-7:合理地设计数据类型,尽量减少没有必要的数据类型默认转换与强制转换。 3.必要的方法 3-1:方法访问权限声明,要有明确的权限控制。 3-2:方法声明的完整性,对返回类型、参数、例外都要有明确的说明。 3-3:明确方法功能,精确地实现方法设计 3-4:明确规定对接口方法参数的合法性检查应由方法的调用者负责还是由接口方法本身 负责,缺省是由方法调用者负责。 3-5:防止将方法的参数作为工作变量。 3-6:方法的规模尽量限制在200行以内 3-7:避免方法中不必要语句,防止程序中的垃圾代码。 3-8:避免重复代码:如果多段代码重复做同一件事情,那么在方法的划分上可能存在问题。 3-9:功能不明确的较小的方法,特别是仅有一个上级方法调用它时,应考虑把它合并到上 级方法中,而不必单独存在 3-10:设计高扇入、合理扇出(小于7)的方法。 3-11:减少递归算法:减少方法本身或方法间的递归调用。 4.必要的注释 5.排版规范 6.代码可读性 6-1:避免使用默认优先级:注意运算符的优先级,并用括号明确表达式的操作顺序。 6-2:避免使用不易理解的数字:用有意义的常量标识符来替代。 6-3:源程序中关系较为紧密的代码应尽可能相邻。 6-4:不要使用难懂的技巧性很高的语句,除非很有必要时。 7.关注程序效率 7-1:编程时要经常注意代码的时间效率和空间效率。 7-2:在保证软件系统的正确性、稳定性、可读性及可测性的前提下,提高代码效率。 7-3:提高空间效率的建议:不要保存无谓的数据在内存中,内存清理或磁盘io都是很耗费效率的。 7-4:关于循环的效率,不要在循环中做无谓的事情 7-5:精细化算法处理:仔细分析有关算法,并进行优化,;但不应花过多的时间拼命地提高“调用不很频繁”的方法代码效率。 7-6:不要一味追求紧凑的代码,可读性、可维护性比紧凑的代码重要。 架构示意图 1.OO理论的由来 客观世界是由事实组成的 事实是由相互作用的对象组成的 2.OO关系---继承 3.OO关系—关联 4.OO关系—依赖 5.OO关系-实现 架构示意图 1.设计模式的概念 设计模式的基本概念 针对设计中特定的问题模型,提供一种或多种固定的结构模型。 设计模式本身反应了一种重用的思想,那就是解决方案级别的重用。 设计模式的实现手段包括:重用、接口与实现分离、结构分解。 2.设计模式概览 3.Singleton(创建) 意图 一个类只有一个实例,其状态在全局保持一致,系统可以全局访问这一个实例。 解决方案 效果 保证单一对象实例的状态一致性 有效节省内存空间 全局唯一的访问控制点 4.(Abstract )Factory(创建) 意图 接口定义与实现分离,一个接口存在多种类型的实现,系统在运行时根据具体的环境条件创建具体的实现类的实例。 解决方案(见右图) 效果 接口与实现分离后,支持了系统级的多态性,系统扩展性增强。 5.Builder(创建) 意图 将复杂对象的创建和表示分离,使得很容易创建不同的表示。 解决方案(见右图) 效果 使得对象的创建过程透明,便于修改成其它对象。 6.Adapter(Wrapper)(创建) 意图 一个类想使用两外一个类提供的服务,但是接口不匹配。 一个类仅仅想实现某个接口的部分服务。 解决方案(见右图) 效果 使得不兼容的接口类可以为另外一个类提供服务。 7.Composite(结构) 8.Fa?ade(结构) 意图 为系统一组接口提供一个一致的界面。 解决方案(见右图) 效果 屏蔽系统内部结构,使得外部系统松耦合。 9.Proxy(结构) 意图 Client在调用Server的service时,要求访问是受控的。 解决方案(见右图) 效果 使得对某个接口的访问是受控的。。 10.Command(行为) 意图 客户端在某种情况下,知道要调用某个服务,但是又不能直接访问。 解决方案(见右图) 效果 使得客户端与其调用服务之间实现松耦合。 11.Observer(行为) 意图 一个对象的状态发生改变时,有多个相关对象处理该事件

文档评论(0)

tiantiande + 关注
实名认证
文档贡献者

该用户很懒,什么也没介绍

1亿VIP精品文档

相关文档