jokermanager
- 浏览: 143692 次
- 性别:
- 来自: 广州
-
最新评论
-
randyjiawenjie1：
终于遇到一个人讲清楚了
阻塞I/O，非阻塞I/O -
dxqrr：
学习了。。。。
java中堆和堆栈的区别 -
tanhong：
[color=yellow][/color] ...
“is a”和“has a”的区别 -
uuid198909：
代码看着是比较………………
JDK5新特性--java.util.concurrent Semaphore(8) -
heipark：
兄弟，咱这代码纠结了点....
JDK5新特性--java.util.concurrent Semaphore(8)
文章列表
图
1
：策略模式类图
图
2
：状态模式类图
熟悉
uml
类
图的朋友，可以看出，策略模式的类图和状态模式的类图实现是很相似的，这也是为什么设计模式中，我们把这两种模式比喻成为孪生兄弟，很多时候，我们在运用
上述模式来解决实际问题的时候，也经常混淆他们，其实，个人倒是认为，就算大家用法不同其实也没有必要介意，因为设计模式的应用是紧贴着设计原则来走的，
不论是状态模式，还是策略模式，我们都是紧紧的遵守着开闭原则，里氏代换
- 2008-11-26 17:07
- 浏览 1366
- 评论(1)
下面的情况考虑使用策略模式：
1、一个系统中有许多类，他们的区别仅在于他们的行为，那么使用策略模式可以动态地让一个对象在许多行为中选择一种行为。
2、一个系统需要动态地在几种算法中选择一种，那么这些算法可以包装到一个个具体的算法类里面，而这些算法类都是一个抽象算法类的子类。换言之，这些具体算法类都有统一的接口，由于多态性原则，客户端可以选择使用任何一个具体算法类。并只持有一个数据类型是抽象算法类的对象。
3、一个系统使用的算法不可以让客户端知道，策略模式可以避免让客户端涉及到不必要接触到的复杂的和只与算法有关的数据。
4、如果一个对象有很多的行为，如果不用恰当的模式，这些行为只好 ...
- 2008-11-26 16:04
- 浏览 822
- 评论(0)
用例的粒度
- 博客分类：
- 《UML与模式应用》读书笔记
用例没有粒度，不要把步骤当作用例。尽量不要用
CRUD
为用例，因为它们一般不提供价值，过于在乎细节，是从数据库角度进行考虑的。
多个用例也可能操作同样的数据，一个用例背后可能隐藏多个数据操作。如果确定为
CRUD
，则合并为管理
***
，
可以把
Create
当作主路径，
Read
，
Update
，
Delete
当作其它可选的路径
。不要牵涉界面细节。
- 2008-11-19 16:11
- 浏览 1250
- 评论(0)
1、一组用例实例，每个实例是系统执行的一系列活动，以此产生对特定参与者具有价值的可观察结果。
2、关注系统的用户或参与者来编写需求。
3、关注理解参与者所考虑的有价值结果。
发现用例的过程：
1、选择系统边界。
2、确定主要参与者。
3、确定每个主要参与者的目标。
4、定义满足用户目标的用例，根据目标对用例命名。
- 2008-11-19 10:53
- 浏览 1224
- 评论(0)
1、一组用例实例，每个实例是系统所执行的一系列活动，以此产生对特定参与者具有价值的可观察结果。
2、关注系统的用户或参与者来编写需求，询问其目标和典型情况。
3、关注理解参与者所考虑的有价值结果。
- 2008-07-06 11:20
- 浏览 985
- 评论(0)
1、黑盒用例是最常用的和推荐使用的类型。它不对系统内部的工作、构件或设计进行描述。
2、黑盒用例以职责来描述系统，这是面向对象思想中普遍统一的隐喻主题-软件元素具有职责，并与其他具有职责的元素进行协作。
3、黑盒用例定义系统职责，可以规定系统必须做什么，而不必关心系统如何去做。
4、分析与设计的区别，就在于”什么“和”如何“。
5、在分析中应避免进行”如何“的决策，而是规定系统的外部行为。
6、在设计过程中，创建满足该规则说明的解决方案。
- 2008-07-06 11:12
- 浏览 984
- 评论(0)
准则：编写简洁的用例
- 博客分类：
- 《UML与模式应用》读书笔记
1、应该编写简洁的用例，删除“噪音”词汇。
2、即使是一些细微之处也会积累为繁琐。
- 2008-07-06 11:07
- 浏览 1054
- 评论(0)
1、通过对目标层次的研究，系统分析员会发现与实现机制无关的目标。
2、这种对根源目标的发现过程能够扩展视野，以促成新的和改进的解决方案。
3、摈除用户界面于思考范围之外，集中于意图。
4、以本质风格编写用例，摈除用户界面并且关注参与者的意图。
5、具体风格的用例编写方式，不适合于早期的需求分析工作，应该避免。
- 2008-07-06 11:03
- 浏览 1228
- 评论(0)
1、业务活动与规则对于一个领域来说与其涉及的实体同样重要。
2、领域也会包含各种类别的概念。对知识的消化要能够产生出反映这种理解的模型。
3、超越实体与值之上的变化可能会对知识消化产生剧烈的影响，因为业务规则之间可能存在不一致。
4、领域专家通过与软件专家的密切合作，进行知识消化，才使得规则明晰化。
5、提炼隐藏概念，将业务规则可以放到一个领域对象中。
6、任何业务专家都不可能阅读代码来检对规则。
7、一个非业务人员的技术人员，要将需求文档与代码联系起来是很困难的。
8、可以通过改善设计来更好的捕获知识。
9、规则的实现应该是独立的。
10、一个领域模型和其相 ...
- 2008-07-06 10:05
- 浏览 959
- 评论(0)
1、如果一个数组中的各个元素代表了不同的东西，考虑用Object来代替数组。
2、数组应该只用于容纳一组相似对象。
3、如果一个数组容纳了不同对象，会给array用户带来麻烦。
- 2008-07-05 20:26
- 浏览 1195
- 评论(0)
1、重要的研发成果常常产自类比。通过把你不太理解的东西和你较为理解、十分类似的东西进行比较，你可以对这些不太理解的东西产生更深刻的理解。这种使用隐喻的方法叫做“建模”。
2、软件隐喻不会告诉你到哪里去找 ...
- 2008-07-05 20:14
- 浏览 1406
- 评论(1)
1、高效的建模人员就是知识的消化器。
2、知识消化并不是一个孤立的行动，它由开发团队与领域专家共同合作，由开发人员领导。
3、老式的瀑布方法中，业务专家与分析人员会谈，分析人员提取摘要，进行抽象后将结果转达给程序员，由程序员进行编码。这种方法并不成功，因为没有反馈机制。
4、优秀的程序员会自然地开始进行抽象来开发一个模型。
5、在团队成员一起讨论模型的过程中，他们之间的交互也会发生变化。模型的不断精化使得开发人员不断学习他们所需要的重要业务原理。领域专家通过提炼他们认为必须的知识来精化他们的理解。
6、程序员、分析人员、领域专家都介入其中，模型变得组织有序并且抽象合理，能够反 ...
- 2008-07-05 19:52
- 浏览 890
- 评论(0)
1. 模型与实现相互绑定。未经加工的原型建立了早期必需的联系，在随后的迭代中始终对它进行维护和完善。
2. 基于模型生成了一种语言。随着项目的进行，我们中的每个人都可以自如地使用来自模型的术语，将它们组织成与模型结构一致的句子，不需翻译，也不会引起歧义。
3. 开发了一个包含丰富知识的模型。对象都具有行为和一些强制性的规则。模型并不仅仅是一个数据方案，它是解决一个复杂问题必不可缺的。它捕获了各种类型的知识。
4. 提炼模型。在模型变得更加完善的过程中，一些重要的概念被加入其中。同样重要的是，如果概念被证明没有用处或并不重要，则应该丢弃。如果一个不必要的概念与一个需要的概念结合在一起， ...
- 2008-07-05 19:43
- 浏览 792
- 评论(0)
1、用例、UML图等保证不会是完美的。它们可能会遗漏关键信息或者包含错误陈述。解决方案并不是以瀑布的态度试图近乎完美地记录规格说明并且在开始阶段就完成此项工作。
2、编写用例的折中方案是介于瀑布和即兴编程之间的迭代和进化式开发。
3、以增量式进化、验证用例和其他模型，并且通过及早的编程和测试加以明确。
4、如果在第一次开发迭代之前，小组就视图详尽地编写所有或大部分用例时，此时要意识到你已经走入歧途了。反之，则恭喜你！
- 2008-07-05 19:36
- 浏览 823
- 评论(0)
考
虑以下场景：浏览网页时，浏览器了5个线程下载网页中的图片文件，由于图片大小、网站访问速度等诸多因素的影响，完成图片下载的时间就会有很大的不同。如果先下载完成的图片就会被先显示到界面上，反之，后下载的图片就后显示。
Java的并发库
的CompletionService
可
以满足这种场景要求。该接口有两个重要方法：submit()和take()。submit用于提交一个runnable或者callable，一般会提
交给一个线程池处理；而take就是取出已经执行完毕runnable或者callable实例的Future对象，如果没有满足要求的，就等待了。
CompletionService ...
- 2008-07-04 10:25
- 浏览 1290
- 评论(0)