最近心得随笔

1.结构不会消失
  型也不会消失，要么是显示的，要么是硬编码的在代码里的。

2.代码质量标准
  基本：可以清楚完备的考虑。
        容易修改。需要遵守针对接口编程的基本思想，规避内容耦合。
        举例：
        混杂的dto作为方法参数，想针对参数打一下debug，都出现困难。不确定dto那些属    性有用。

3.web mvc action 尽量减少非界面相关逻辑。
  控制是界面对模型的控制，不是业务逻辑控制。
  action 是界面和模型的适配器。
 
  适配器的加深认识参见《j2ee核心设计模式》中对Dao的描述。

4.ProcessTaskGroup.hbm.xml 报错找不到，但ProcessTaskGroup.hbm.xml文件存在，那估计文件的位置是错的。

5.view-model 间存在中间的临时模型。
一种情况，临时模型是编辑数据模型，是软件模型的局部复制。
另一种情况，web界面上控件本身的数据模型。


6.对于Service重用一方面指同一方法能够被重复利用。同时也指，当界面发生变化时，原来实现的Service功能可以被重用。

7.硬编码总是存在的，要么硬编码型，要么硬编码值。

8.交互式设计本身难度不大，一般的人是可以完成一部分的。最大的问题是方向正确。比如：需要用tree的地方误用了表格。应该布局在一个界面的内容被拆分成了多个界面等。可能，不会设计的人是没有方向的，抓到一个思路就会走下去，从而浪费大量时间。因此，已有的想法，不要指望能被自动找到，需要方向性的交流。
另外，细节处的处理，就没办法了。只能采用复查的办法保证质量。比如：一个选择对话框，应该放确定和取消按钮的地方，设计的人放个保存，且不放取消按钮，问曰：上边有个差可以关窗口。这样的问题，只能靠复查了。

9.单例通常的调用形式是  xxx.getIntance().xxx(), 这样对方法的调用，对返回值的类型没有强制的依赖。
这个意义不大。主要还是单例就是可以直接使用的，没有必要增加中间变量，增加一个中间环节。

10. 时序图刻画的是关键设计要点。准确的说，它解决的是运行过程中的职责分配问题。而不是无关的细节。比如：当出现多层的内部方法嵌套时，可能就是描述了无关职责的细节。

11.as400 cl 缩写 http://m.03964.com/read/f500eaaa2250dc69b4d31696.html

12.mvc 是一总特殊的对象关系，view使用model的数据，进行单向耦合。而一般意义的OO数据是分布在各个对象中的，数据的使用关系是网状的，对象间如何耦合需要在设计理论下进行设计。

13. 所需即所配。

14. 时序图是可执行的。

15. 程序类客户数据，也是客户数据。它具有和程序粘连的特性，这导致了无法通用的程序。

16. 程序客户数据化和可选的功能是有明显差别的，前者主程序不依赖与具体程序数据。后者，主程程序是知道程序数据的。

17. 时序图体现的是具体代码的上一层“接口层”的运行过程。这一层直接反应了业务逻辑。
    有人不会分层思考（更基础的是不懂针对接口编程，因此代码分层无从谈起。比如：方法内map的key的字符串拼接形式，定义为参数，在调用时传递）自然不喜欢用时序图。因为时序图强迫程序员在类的接口层思考。
    时序图的这种分层能力以及在这基础上与业务对应的能力，是了不起的。

18. hibernate 值对象对应字段不能like

19. 方法名称的表示，既可以是直接代表业务的，也可以是功能加上参数完成了业务的。
    degradeWarningInfoLevelTo1(wiid);
    setWarningInfoLevel(wiid,1);
   
    应该在保证从代码上能看出业务过程的基础上，尽量使接口通用。