阅读更多
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);
应该在保证从代码上能看出业务过程的基础上,尽量使接口通用。