放假总是悠闲的,找不到事做就看看书吧。
那些在任何情况下都是 e 迷离的事物,其美丽是就其本性而言的。美丽的终结也是就其本性而言的,赞美并不是其本性的一部分。
就第一篇写的记录开始学习。
推迟考虑数据库
我们构建一个应用程序,最先考虑到的应该是数据库,往往是先设计数据库然后再来设计,对于该类问题同样,他可以使用某些关系型数据库,并且从需求中可以清楚地知道表和字段的可能样子。可以容易设计出一个可用的数据库模式,然后再构建一些查询。不过,在这种方法产生的应用程序中,数据库就成了关注的中心。
我们换个思路,把数据库看成我们实现的细节!尽可能地推迟考虑数据库。按照抽象的定义,我们应该把本质的部分放大,无关紧要部分的去掉,在项目的当前阶段数据库就是无关紧要的,他不过是一项用来存储和访问数据的技术而已。
用例
那我们如何分析呢?在一开始的 xp 编程中,提到一个非常重要的概念——用户素材。用例就是用稍多一点的细节描述的用户素材,在进行分析的时候,我们关注用户素材和验收测试。不陷入过多的细节。
搜寻
来看看这章做了哪些事
-
将用户描述转化为了具有细节的用例,而不是过于简单用户素材。
-
对用例进行一个一个的分析,弄清楚系统怎样去响应这些操作。
-
前半部分通过对六个用例的分析,初步确定
COMMAND 模式
以及可能的 静态模型。 -
通过一个用例以及他的变体,改变初步确定的设计模式,由
COMMAND 模式
改为STRATEGY 模式
,同时加上了NULL OBJECT
模式设计出修订后的系统类图。 -
通过协同图明确了可能出现的用例变体/情景。
-
寻找描述中的抽象。
-
通过抽象发现从属关系,移除
NULL OBJECT
模式。
设计
在设计中,不包含任何对数据库的内容
-
首先将用户素材 n 加沙改一些适当的细节描述成为用例
-
通过对用例的分析,获取到有用的信息以及设计的洞察力
-
设计不是一成不变的,它可以随着迭代的进行不断修改,最终迭代完成后确定下来
-
遵循面向对象设计的五大原则
-
寻找出有用的抽象
-
设计模式不是用的越多越好
总结
这章节似乎是一个小型会议一般,在商讨第一次迭代的点滴与内容,值得注意的是,多次强调妖抵制住数据库的诱惑。i 回想一下,我们似乎总是在面向数据库编程,这并不是一个好习惯。同时也多次提到了五大原则,在设计时,五大原则是能够架构一个友好的软件架构的重要因素。这次的目的只是为了发起一种思考,但是依旧都是可变的,只是一个快速设计的一个会话展现。
欢迎来到这里!
我们正在构建一个小众社区,大家在这里相互信任,以平等 • 自由 • 奔放的价值观进行分享交流。最终,希望大家能够找到与自己志同道合的伙伴,共同成长。
注册 关于