因为以前和学生的接触,感觉很多是混文凭的,不要说什么面向对象,就是能写一段完整的代码都成问题,所以在开始的时候也没有想过他们能正确地使用类,更加不用谈什么设计模式了。主要跟他们谈了一下业务需求以及在项目开发中必须注意的东西,至于如果实现没有作要求,一是想给他们一个实践的机会,另外担心给他们的规则太多,反倒作的不伦不类的。
但是随后的基础发现有几个人还是很有思想的。并且很认真地设计架构。于是要他们讲了他们的设计思想。
(等下继续,现在处理一下工作......)
(前两天在做机构管理的模块,领导们要求反映机构的变动历史。于是使用了两个表,主表记录机构状态,历史表记录每一次变动的结果。本来主表可以不当前信息的,但是最开始的设计没有考虑历史情况的记录,所以在很多地方都直接从主表取数据,考虑到兼容性,还是继续在主表保存了一些信息,这样和历史表的记录有些冗余,同时牵涉到了同步这两个表的冗余信息。所以在程序中多了一些控制代码,不过幸好量不大。)
可以说他们的设计也是很有道理的。他们为每一个操作定义一个常量,然后使用一个统一的类来处理这些操作命令,类似Windos的消息处理机制。这个类根据不同的消息来实例化对应的业务类以及方法。之所以否决了他们这个设计,处于以下的原因。
不符合现在的框架。以前已经说过了,这个项目的开发已经使用的是Jsp+javabean的模式。之所以选择这样的框架也是出于快速开发的原因。因为当时我需要在半个月时间内一个人完成一个可以被认可的东西来。情急之下就选择这样的框架模式。当然我很明白的根他么说,这个框架结构不很规范。但是做项目就是这样子,你必须根据实际情况来选择。在项目中要放弃将什么东西都作完美的幻想。在有限的资源和时间内完成客户的需求才是根本原则。
不符合他们的现在的开发模式。因为工程实习的要求,以及主管他们的老师要求,他们实际上每个人都在从需求到设计到实现的作。所以他们是相对独立的进行开发。而开发之前没有做好足够的准备定义好所有的操作以及定义好多所有的实现类。按照他们的设想,那么一个业务功能的实现将要同时设计到三个人:一个业务类开发人员、一个负责操作代码表管理人员以及一个业务类的使用人员。很明显这需要他们很好的协调,保证这个流程的顺利推进。如果他们有一个成熟的主程序来协调,他们或者可以这么做。
在和他们交流过程中还发现了他们两个问题。忽视了设计的存在,他们似乎忘记了在开发之前,所有的东西应该已经设计好了,所以他们要使用操作常量的原因是担心在开发过程中类的路径或者函数的名字发生了改变。而提出使用操作常量;另没有分清楚什么是页面设计,在他们的概念中只要在JSP方面工作就是页面设计,就是说在JSP上的java语法部分也被划分到页面设计中去了。