软件开发中,比较经典的开发步骤: 一、瀑布模型 1.可行性分析 2.需求分析 3.软件设计 4.编码 5.测试 6.交付产品 7.维护 弊端：瀑布模型存在比较严重的问题需求如果要发生变更只能在极早期越往后走,代价越大 二、迭代+瀑布模型 1.计划驱动----文档为主 2.敏捷开发—客户交流为主 需求分析、软件分析，编程 都有两种方式：面向对象，面向过程 采用面向对象的思维方式进行：分析需求（OOA） 软件设计（OOD） 编程（oop） 软件设计的优良 一、评价的标准 1.有没有覆盖用户所提供的所有的业务功能（覆盖了所有的需求，也不一定就是一个很好的软件） 2.前期设计出来的各种文档或者图纸，可读性高不高，能不能被项目所有的干系人快速的理解。一个可读性非常差的文档，或者设计的图纸，会给我们后期的开发，测试，维护带来巨大的影响 3.软件设计的图纸中，覆盖的类、包、接口。以及后期其他的各种组件，复用性强不强，能不能被本项目或者其他项目重复使用 4.软件开发后期，如果业务需求需要发生变化，业务功能或者性能的拓展性高不高 5.后期软件的维护，或者开发过程中代码的维护能力强不强（员工离职了，其他员工能不能看懂，快速理解软件架构） 归纳总结：软件设计过程中是否能够做到“高类聚，低耦合”（高类聚：一个类只干一件事情，一个方法也只干一件事情。具体来说：就是一个类只关注一个点。 低耦合：就是指类和类之间的关系紧密程度 如果一个类与例外一个类关系非常的紧密，那么当其中的一个类需要发生变化的时候，调用类将也会跟着变化。耦合度决定了应用软件能否灵活支持需求变化的最大因素。紧密关系越紧，变化度越低，变化的代价越大。但是我们又不能说直接取消耦合，所以咱们直接降低耦合度） 耦合度如何降低？需要大家去遵循这个行业里面，由前辈给我们总结出来一些设计原则以及设计模式。 原则 1.单一职责原则： 1）1个类只干一件事，这是软件设计中高内聚的最重要一点，也就是一个类只有一种职责，职责需要类的对象来确定，看你正在关注对象的哪个方向。比如：学校系统中，学生对象来讲只需要关注学习而不需要关注学生的其他家庭因素。只有一种情况能去改变我这个类。也就是在设计类时，类中的每一个属性，和每一个方法都必须根这个类的职责具有直接行为，如果无关，就一定违背了单一原则 2）类的职责单一,也是一种降低耦合度的手段,对象的职责越少,耦合关联度越低,代码越容易复用。当然单一职责,同样适用于方法。当方法违背单一原则时，那么方法的代码将会非常冗长，以及可能 2.开闭原则：软件实体对扩展是开放的，但对修改是关闭的，即在不修改一个软件实体的基础上去扩展其功能 3.里氏替换原则： 1）子类可以出现在父类出现的任何地方，并且对于父类之前定义的规则，不会发生任何改变 2）目的：为了维护现有的继承体系，保证龙生龙、凤生凤，老鼠儿子依旧会大洞。这个原则是开闭原则的一种体现，或者是一种重要的保证，保证儿子在新增新的功能的时候，不能去改写父类已经定义好的方法，从而去维护现有的继承体系。 4.依赖倒转原则：要针对抽象层编程，而不要针对具体类编程 5.接口隔离原则：使用多个专门的接口来取代一个统一的接口 6.组合/聚合复用原则：在系统中应该尽量多使用组合和聚合关联关系，尽量少使用甚至不使用继承关系 7.迪米特法则：一个软件实体对其他实体的引用越少越好，或者说如果两个类不必彼此直接通信，那么这两个类就不应当发生直接的相互作用，而是通过引入一个第三者发生间接交互
