Aspect-Oriented Software Development with Use Cases读后感

我理解是这样的。
用演进的观点来看，不要一下子就进入最终实现的场景，实际上跨越多层本身就是一个扩展用例。
为了更好的理解，首先设计一个minimal use case design，这是和平台
无关的设计，忽略掉了很多细节和方面，突出核心的解决方案，然后可以通过扩展的方式添加表示，持久化，分布式等。

另外，不要把用例阶段的Aspect，看作最终实现的Apect。Aspect从需求到最终的
实现是分层次的。

切点是指系统中所有对象在某一时刻的状态还是指一个对象在不同时刻的状态？
怎么把AOP应用到OO中能否举个简单直观的例子

都不是。
网上搜索一下，大把的例子。

对好的构架的要求之一是关注点得到分离，使用面向方面能更有效的实现。
作者将他们分为下面几种情况：
1.将功能需求分离；
用例本身是基于涉众关注点来划分的，同级用例意味着用例间不会相互影响；包含用例封装多个用例的公用部分，以避免重复。
扩展用例实现可选的功能，从而不会影响基本用例的必需部分。
2.将非功能需求同功能需求分离；
非功能需求通常指系统的质量特性。例如：安全、性能、可靠性等。这意味着需要用认证、授权和加密等机制实现安全，缓存、负载均衡来实现性能。
这些基础机制常常需要在很多类中添加些行为；也就是说改变这些基础机制会影响到很多的类，所以也希望能够分离。
3.分离平台的特殊实现和细节
通常不希望同某种技术绑定得太紧，以便该技术升级或平台转换时对系统的影响最小。
4.分离测试同被测试的系统
作为测试实现的一部分，需要控制程序执行流程，跟踪执行路径，记录执行情况等。这些在最终发布版本中需要移出，所以我们也期望能够分离出来。

就我的实践表明，在发布版本中的某些日志对于定位系统异常相当有用（比如执行的SQL语句），所以会在发布版本中得到保留。

ElementStructure