静态工厂和动态的构造函数

实际上这是一个工程设计的问题.工程开始和学术研究是不同的,这一点大家都清楚.工程最重要的是考虑经济的问题,也就是任何手段都是以其经济效益为选择标准的最重要部分.
我喜欢动态的结构,但是动态结构往往会带来开发过程的复杂和维护的复杂.而如果你把所有的东西都想做到动态的时候,配置本身就成为一种复杂的编程而不是一种设置.所以首先我们就应该权衡一下究竟什么需要我们去做动态的调整.也就是说如果你几乎不会去跑步,那么就不要去考虑将来是不是要穿跑鞋的问题.这一点我绝对是以XP的法则为指导思想的.程序员往往都喜欢复杂的解决,而简单的方式让他们觉得泄气.这往往会带来很多的不必要的麻烦.
其实很多时候使用静态工厂并不是大逆不道,即使需要在将来修改,你一样可以动用重构这个工具.
就如同分层,我们知道分层原则上说会带来结构的清晰,但是这绝对是要有代价的.你使用MVC一样会有代价,我就喜欢用VB这样的东西,简单而简单,只是设置设置属性,只是写最少的代码,就可以有一个可以工作的程序.虽然这样子好像很业余,但是这个世界上大多数软件都是这样开发出来的.而当需求复杂起来或者结构中的臭味让我不能再忍受的时候,我会去做重构,把层次划分出来.就如同我会在我觉得必要的时候把静态工厂修改为动态的构造函数一样,我不觉得这个问题是一个大麻烦.
首先我追求的就是可以工作的程序,结构的优雅只能在这个基础之上才有意义.所以ajoo其实也是在沉迷于fancy words.
我这个人比较笨,年纪这么大也没有学聪明,所以我只能坚持先可以工作,然后再说别的.但是我知道至少这个世界上和我一样笨的人还有很多,我们只能采取先工作,再重构的这个笨办法.并且我也知道很多人和我一样不喜欢写code,因此我们都尽量避免复杂实现.而如今软件的复杂以及超出我们的想象,我自然不想再添加新的复杂在其中.
落实到具体的实现来说,程序的底层工具,也就是我们使用的jdo/Hibernate/spring这些东西我们很少会去动.注意我说的是很少,而不是绝对,有些时候做针对性的定制是必须的.但是这样的机会少而又少.而业务框架实现的时候也应该尽量的稳定,需要修改的只是业务中的逻辑部分.比如你的客户这个类应该尽量保持接口的稳定,而修改的只是客户订货的方法逻辑这些部分.而这些逻辑几乎一定会被修改,将其作为一种动态的可以在发布以后可以动态修改的部分是绝对必要的.而每一个客户都有购买物品的实际时间,这个部分不管你如何修改只是将其修改为不同的显示方式,而这样一来修改的可能性就小得多(你只有有限的几种选择,再加上时区的因素),这个部分你做成为动态的设置就没有多大的必要,你只是需要做有些的设置参数传递就可以了,你完全没有必要去设计一个将来可以使用火星或者木星以至于其他别的星球的时间概念的复杂的动态实现.
不管怎么说静态工厂和动态的构造函数都是可以工作的实现,我们所要做的就是权衡.