Architecture

   在工作日，数据接收者如果没拿到想要的数据，就会报个异常   但在工作日，它不应该报异常的 所以，要么    1. 将工作日、非工作日 的区分应用到程序逻辑中，使系统在非工作日不去获取数据    2. 不做这种区分，仍然报出异常，但要确保这种异常不会对系统的其他方面产生影响，并且用户也要人为地注意：这是个伪异常

    我们在做比较时，潜意识里可能倾向于把一切比较关系 都化成 大小关系， 比如 长短 就是长度大/长度小，额度高低 就是 金额大/金额小， 出生日期远近就是 年月日大/年月日小—–等等！日期远代表的年月日小，日期近代表年月日大，别搞反了！

标题可能不好理解，先举一个例子。 在一个会议室预订系统里，有这样一条业务规则：     当收到一个订单时，         if            当天是星期三        then            立即借出        else            交给管理员手动审批 我们把这个规则直接实现在业务方法里，即            class   预订服务{        void  处理订单(){                   if(当天是星期三)                       借出();                   else                       交给管理员手动审批;        }        void 借出(){            //to do        }     } 假设系统运行一段时间后，这个业务规则突然被取消了，那就得让开发人员修改这部分代码 又假设业务规则不变，按照这个规则，一个订单被批准。但是由于紧急情况，管理员不得不否决了该订单。可是申请者不知趣，又重新提交该订单、结果订单又被批准，管理员又得强行否决…… 所以我们换一个办法。建立一个机器人类，名叫“机器人管理员”。它定时地扫描订单队列，一旦发现有了新订单就立即按照上面所说的业务规则进行处理。 如 class 机器人管理员 extends 管理员 implements Runnable{     void …

将被动的业务规则从流程中剥离，建模成主动的机器人 Read More »

如题 如题 如题

1.每个步骤都有可能发生异常，发生了异常怎么办？ 2.异常可分为系统异常和业务上的“非理想状况”。比如一个网上购物网站，连不上支付网关是系统异常，用户余额不足不能支付则属于业务异常。 3.对于批量数据接口异常，要区分以下几种情况：    a.未返回数据    b.返回了批量数据，但只是返回了一个空的容器（如空文件，空的java.util.List）    c.返回了批量数据，但容器里记录的是报错信息    d.返回了批量数据，但容器里记录的信息不是我们想要的信息    e.返回了批量数据，且容器里有我们想要的数据，但是其中某些数据是正常的，某些是错误的 100.异常除了改变程序流程，异常信息本身该怎么记录？ 不同级别的异常应有不同的记录方式

    从汉语语法或者英语语法上说，“烹调工作”都是一个名词。但从语义上说，它其实代表着一个动作(cook)，因此它是一个“动明词”。 既然它是一个动作，那么在建模时就应该把它拆散，因为拆散了可以减少两部分的耦合，提高某个部分的可重用性         Cooking =  " Do something"  according to a " recipe" 在系统设计时    1. Cooking 和 Recipe 应该独立建模    2. Cooking中有时间、地点、厨师等属性    3. Recipe中则有原料、佐料、步骤等属性    4. Cooking 和 Recipe 是 多对一 关联关系，即同一个菜谱可以被多次使用。 如果我们一开始没有把它拆散，只做一个Cooking类，把原料、佐料也当作它的属性，那么 Recipe 就没办法重用。

给一个很能吃的人 上三份饺子，三份粥，三只烤乳猪，他会怎么选择？ 1. 轮换式：吃盘饺子，喝碗粥，吃只猪 –> 吃个饺子，喝碗粥，吃只猪 –> 吃个饺子，喝碗粥，吃只猪 2. 流水线式：   吃三盘饺子 –> 吃三碗粥 –> 吃三只猪 如果我们定义： 一盘饺子 +一碗 粥 + 一只烤猪 = 一份套餐 那么，如果食客选择第一种吃法，那它就吃了三份套餐，从任务定义的角度，我们的设计可以更简洁 如果他选择第二种吃法，设计上不那么简明了，但效率可能会好很多。因为吃第一盘饺子的器皿可以马上用来吃第二盘、第三盘，吃粥的碗也是一样，整顿饭一共要“端碗/盘”三次。而对第一种吃法而言，他吃完第一盘饺子后，要换用粥碗去吃第一碗粥，然后用换另一种食器去吃猪，接着又换回盘来吃饺子…… 整顿饭它要“端碗/盘”九次 或许你认为我在说废话，根本没啥实际。但如果把上面的 吃东西 替换为 下载东西， 把 端/放碗 换成 建立/释放 网络连接， 你可能就不会这样想了

1.数据类型，字符串还是数字，还是日期 2.是否可能为空 3.如果为空，是""，还是NULL 4.如果是字符串，最大多少字节 5.如果是数字类型，是整数还是浮点数 6.如果是数字类型，是正数还是负数 7.如果是浮点数，精度是多少 8.如果是一些代号，那么可枚举的范围是什么？空用什么表示？代号大写还是小写 9.如果是货币，是什么币种，是以元为单位还是以万元为单位 10.如果是日期，格式是什么

要约定：空格是“\0”，还是“\20”，还是其他

    一个列表可能是       1.一个集合，元素不会重复       2.一个数组，元素可能重复       3.一个字典，名不会重复，但值会重复