部分读书笔记

2013-04-19 13:39
抱着《UML和模式应用》这本书看了大半年，这本书的内容有很多，但总体思想依然是：
软件系统的可维护、可扩展
高效率、持续、迭代交付可复用的软件产品
前期、需求分析、分析设计、编码开发的主要步骤，作者对整个过程提出了最佳实践
迭代开发、需求进化、架构进化，这是一个快速迭代进化的过程
最多的名词
松耦合、模块化、组件化、分层、分职责、领域模型、概念模型、设计模型、测试驱动、模型视图分离、逻辑架构、包、静态建模、动态建模、对象设计技能、高内聚低耦合、应用逻辑层、领域层
好了，上述的基本上都是重要的概念，这些概念都是用来辅助提高软件系统的质量，从一定程度上来说这些概念就是目标、是长远规划，那么如何完成呢？
GRASP的9个模式
创建者、控制器、纯虚构、信息专家、高内聚、间接性、低耦合、多态性、防止变异
1、创建者
该模式指导我们分配那些与创建对象有关的职责，寻找在任何情况下都与被创建对象具有连接的创建者。保持低耦合。当创建逻辑非常复杂的情况就要考虑到创建职责委托给具体工厂、抽象工厂。
2、信息专家
在对象设计中，当定义好对象之间的交互后，我们就可以对软件类的职责分配做出选择。把职责分配给信息专家，它具有实现这个职责所必需的信息。信息专家经常用于职责分配，这是对象设计中不断使用的基本指导原则。专家并不意味着模糊或奇特的想法，它表达了一种“直觉”，即对象完成与其所具有的信息相关的职责。“把职责与数据置与一处，知其责，行其事”。
3、低耦合
考虑怎样降低依赖性，减少变化带来的影响，提高重用性？耦合是对某元素与其它元素之间的连接、感知和依赖程度的度量。分配职责，使耦合性尽可能低。高耦合对于稳定和普遍使用的元素而言并不是问题，例如，j2ee应用能安全地将自己与Java库耦合，因为Java库是稳定、普遍使用的。高耦合本身并不是问题所在，问题是与某些方面不稳定的元素之间的高耦合。
4、控制器
控制器是UI层之上的第一个对象，它负责接收和处理系统操作消息。控制器应当把需要完成的工作委派给其它对象。控制器只是协调或控制这些活动，本身并不完成大量工作。
存在边界、控制和实体类的概念，边界对象是接口的抽象，实体对象是与应用无关的领域软件对象，控制对象是此控制器模式描述的用例处理者。控制器模式的重要结果是，UI对象和UI层不应具有实现系统事件的职责。系统操作应当在对象的应用逻辑层或领域层进行处理，而不是在系统的UI层处理。
设计不良的控制器类内聚很低，即没有重点，并且要处理过多领域的职责，这种控制器叫做臃肿的控制器。解决控制器的臃肿有两个办法：
1、增加控制器，系统不是只能有一个控制器，应使用用例控制器，而不是外观控制器。
2、设计控制器，使它把完成每个系统操作的职责委派给其它对象。
又强调了一遍，控制器模式的重要推论是，UI对象和UI层不应具有处理系统事件的职责。
将系统操作的职责分配给领域对象控制器，能够更加容易地复用程序逻辑，这些程序逻辑能支持未来应用中相关的业务过程。这也使移出当前的UI层并使用其它UI架构和技术更容易，也能够用一种离线的“批处理”模式来运行系统。
上面讲的这一点，实在是深有感触，利用分层架构，在领域层引入控制器模式解耦UI层与领域层，这样做的好处：
1、实现业务逻辑处理可插拔
2、脱离UI层可更容易的来做单元测试，并且是批处理自动化方式来做。
3、UI层不紧紧局限在浏览器，直接拉近了UI层与业务需求变化的响应能力。
5、高内聚
如何保持对象是有重点的、可理解的、可管理的，并且能够支持低耦合？
从对象设计的角度上说，内聚是对元素职责的相关性和集中度的度量。如果元素具有高度相关的职责，而且没有过多的工作，那么该元素具有高内聚性。
如何达到高内聚？
分配职责可保持较高的内聚性。
内聚性较低的类要做许多互不相关的工作，或需要完成大量的工作。
内聚性的类通常表示大粒度的抽象，或承担了本应委托给其它对象的职责。
6、其它
另一个经典：模块化设计
与耦合和内聚关系紧密的另一原则是模块化设计，模块化是将系统分解成一组内聚的、松散耦合的模块的特性。我们通过创建具有高内聚的方法和类来促进模块化设计方法。在基本的对象级别上，我们为每个方法设计清晰和单独的目标，并且把一组相关关注置于一个类中，以此来实现模块化。
内聚和耦合：阴和阳
不良内聚通常会导致不良耦合，反之亦然。内聚和耦合是互相依赖的。
 
领域模型和设计模型中对象类之间的多重性可能有所不同。
错误的原则：就像为人分配职责一样为软件对象分配职责！对象设计要根据信息专家原则将职责分配给众多对象。
命令—查询分离原则，执行动作的方法通常会改变对象状态，而向调用者返回数据的查询没有副作用。