编写伟大软件的三大步骤:
- 确认你的软件做客户要它做的事。
- 运用基本的OO原则来增加软件的灵活性
- 努力实现可维护,可重用的设计
1.需求:
好的需求确保你的系统如预期那样运作。
确认你的需求涵盖了你的所有用例。
运用你的用例找出客户忘记告诉你的事。
你的用例将揭露任何不完整,遗漏的需求,你可能需要将那些需求加进你的系统中。
你的需求将总是随着时间的改变而改变(及成长)。
2.分析与设计:
设计良好的软件容易改变与扩展。
使用像封装与继承这样的基本OO原则来确保你的软件有灵活性。
如果设计没有灵活性,就改变它!别与坏设计妥协,即使那是你自己的坏设计,要改就是要改。
确认你的每一个类都具有内聚性,每一个类都应该聚焦在把一件事情做得很好上来。
随着软件的设计生命周期的展开要持续努力提高内聚力。
3.如何解决大问题:
聆听客户,找出他们要你构建什么
用客户理解的语言组合功能列表
确认你的功能是客户真正想要的东西
运用用例图创建系统的蓝图。用例是面向细节的,用例图则是比较聚集在整体轮廓上。
领域分析让你检查你的设计,并是以客户所用的语言。领域分析帮你避免构建不属于你的责任范围内的系统部分。
将大系统分解成许多较小的部分(模块)
运用基本的面向对象原则为每一个较小的部分设计程序
4.架构
架构是系统的组织结构,包含分解开来的各个部件、它们的连通性,交互机制以及你在系统设计中使用的指导原则与决策。
如何找出哪些是最重要的功能?架构三问:
- 它是系统本质的一部分吗?(系统的本质是指在最基本的层次上系统是什么)
- 这到底是什么意思?(假如你不确定某项功能究竟是什么,该功能可能就很重要)
- 我到底该如何做?(对于很难实现的地方,通常也是重要的地方)
每当不确定某项功能的意义时,首先得询问客户,该功能的意义为何,然后作共同性分析,最后实现计划。
在架构阶段,你所做的每一件事都应该减少项目的风险。运用共同性分析来构建具有灵活性的软件解法。
5.设计原则
设计原则是能被应用到设计或编写程序代码中的工具或技术,让程序代码更可维护,更具灵活性或者更易扩展。
- 开闭原则(OCP):对扩展开放,对修改关闭。也就是说一个类允许通过扩展而改变,但不是以修改现有程序代码的方式进行(如通过继承机制,组合机制)。其实就是封装与抽象化的结合。
- 不自我重复原则(DRY):通过将共同之物抽取出来并置于单一地方来避免重复的程序代码。越没有重复的代码就越没有维护的梦魇。这关系到让系统中每一个信息与行为的片段保存在单一、合理的地方。需求应该只被实现一次,用例不应该有重叠,你的程序代码不应重复它自己,这些都是这个原则的具体表现。
- 单一职责原则(SRP):系统里的每一个对象应该具有单一职责,所有对象的服务都应该聚焦在实现该职责上。也就是说每一个类应该只有改变的理由。通过The 类名 方法名(+参数) itself.这种方式不断测试某个方法是不是应该属于该类。
- 里氏替换原则(LSP):子类型必须能够替换其基类型。继承必须确保父类型所拥有的特质(属性与方法)对子类型仍然成立,也就是说,当子类型能替换其父类型时,才算真有正确合理的继承关系。
当继承不是好的解决方法时,可以考虑用委托和组合来解决问题。
委托:是将特定工作的责任委派给另一个类或方法。一般用关联关系来实现。假如你想要使用另一个类的功能,但不想改变该功能性,考虑以委托代替继承。
组合:让你使用来自一组其它类的行为,并且可以在运行时切换该行为。使用组合你可以重用来自一个或多个类的行为,特别是来自一个族群的类的行为。你的主要对象完全拥有被组合对象,而且破被组合对象不存在于主要对象之外。
聚合:是当一个类被用作另一个类的一部分时,但仍然可以存在于该类之外。当你想要组合的所有好处,但是也想要在主要对象之外使用破坏草组成对象的行为时,就使用聚合。
6.迭代与测试
伟大软件的编写是迭代进行的,先针对整体轮廓操作,接着迭代应用程序的每个片段,直到完成。
- 功能驱动开发:挑出应用程序的特定功能,并且规划、分析及开发该功能,直到完成。
- 用例驱动开发:挑出通过用例的场景,并且编写程序代码以支持通过该用例的完整场景。
OO原则:继承,多态,抽象化,封装
1.将变化之物封装起来,通过封装变化之物让你的软件更有灵活性,更容易改变。
2.对接口编码,而不是对实现,让你的软件容易扩展。
3.应用程序中的每一个类只有一个改变的理由。
4.类是关于行为与功能的。
行为有变化的时候才考虑创建子类!
大多数的好设计都是通过分析坏设计而来的。不要害怕犯错及改变!
每一次对软件进行改进,试着确认它变得越来越具有内聚性,类的高内聚意味着类之间的低耦合。
你可以将大问题分解成许多功能片段,接着就单独解决每个片段。