67,541
社区成员
发帖
与我相关
我的任务
分享新手来求教之四_一些设计上的疑惑
由于经验很少，所以每每遇到程序设计时总是很伤头脑，而最终也往往只能整出个差劲的设计来。
问题1：我设计的常用模块（比如控制台打印、字符集转换过滤、格式化日期、日志文件读写、properties文件读写、javaMail、jsonString读取、excel读取、验证码生成）等等模块经常用私有化构造方法+全部静态化方法来设计这些工具类，这样使用起来就是类名+方法名来使用，请问这种设计方法有何利弊？（tij里曾说过:当你的程序充斥着过多的static时，或许你该想想换个设计了，且实际调用起来越看越像面向过程，虽然用起来时确实方便，不用新建实例）
问题2：我的设计中经常用到抽象类，但却极少用到接口，这正常么？（我的理解是：接口就是抽象类更纯粹的一种表现，但意义是一样的，就是规范了一系列对象的所有动作，使使用这些服务的调用端可以和实际的实现相分离。）
问题3：我为程序中的业务模型层、dao层分别建立了一个工厂，这个工厂以业务模型的名称或代号为参数，以switch\catch的方式去判断并返回所求的实例，但总觉得switch\catch相当臃肿，也觉得，工厂模式除了将对象的创建工作集中到了一处进行统一管理的同时，工厂自己也是够复杂的，尤其是什么工厂方法模式和抽象工厂模式。
-------------------------------------------------------------------------------------------------------------
希望各位前辈能发表下对我这些看法、想法和设计思想的建议和批判，由于程序规模一直不大，且一直没有涉及到过多的修改和扩展，所以无法体会到当前设计是否足够方便扩展和修改。
问题1：我设计的常用模块（比如控制台打印、字符集转换过滤、格式化日期、日志文件读写、properties文件读写、javaMail、jsonString读取、excel读取、验证码生成）等等模块经常用私有化构造方法+全部静态化方法来设计这些工具类，这样使用起来就是类名+方法名来使用，请问这种设计方法有何利弊？（tij里曾说过:当你的程序充斥着过多的static时，或许你该想想换个设计了，且实际调用起来越看越像面向过程，虽然用起来时确实方便，不用新建实例）
问题2：我的设计中经常用到抽象类，但却极少用到接口，这正常么？（我的理解是：接口就是抽象类更纯粹的一种表现，但意义是一样的，就是规范了一系列对象的所有动作，使使用这些服务的调用端可以和实际的实现相分离。）
问题3：我为程序中的业务模型层、dao层分别建立了一个工厂，这个工厂以业务模型的名称或代号为参数，以switch\catch的方式去判断并返回所求的实例，但总觉得switch\catch相当臃肿，也觉得，工厂模式除了将对象的创建工作集中到了一处进行统一管理的同时，工厂自己也是够复杂的，尤其是什么工厂方法模式和抽象工厂模式。
-------------------------------------------------------------------------------------------------------------
希望各位前辈能发表下对我这些看法、想法和设计思想的建议和批判，由于程序规模一直不大，且一直没有涉及到过多的修改和扩展，所以无法体会到当前设计是否足够方便扩展和修改。
...全文
请发表友善的回复…
发表回复
frejus 2009-07-22
- 打赏
- 举报
来看看
yahahaya 2009-07-22
- 打赏
- 举报
感谢大家的分享
yahahaya 2009-07-22
- 打赏
- 举报
我回继续加油的 楼上各位太强了 呵呵
dinghun8leech 2009-07-22
- 打赏
- 举报
十分感谢楼上诸位前辈的指引，这贴我将花几天时间来重读和深入了解思考其中提到的一些问题。
tre1212 2009-07-22
- 打赏
- 举报
up
ForUForM 2009-07-22
- 打赏
- 举报
来接一个，顶上了
lpnn163com 2009-07-21
- 打赏
- 举报
关于抽象类和接口，偶举个例子，门有木门和铁门，这个可以用抽象类和具体类来实现，但是现在要加上报警的功能就要用到接口了， java的jdk设计很多都是这种思想，有空可以看看它的类图
Techxiao 2009-07-21
- 打赏
- 举报
学习了
licao88 2009-07-21
- 打赏
- 举报
受益匪浅，感谢前辈们了
stszd604 2009-07-21
- 打赏
- 举报
学习一下
ryandong 2009-07-21
- 打赏
- 举报
路过，学习学习
wangxianshou 2009-07-21
- 打赏
- 举报
理论贴子，好好学习下，自己太空洞了，惭愧
loveguaixiaobai 2009-07-21
- 打赏
- 举报
学习ing
jinxfei 2009-07-21
- 打赏
- 举报
问题1：我设计的常用模块（比如控制台打印、字符集转换过滤、格式化日期、日志文件读写、properties文件读写、javaMail、jsonString读取、excel读取、验证码生成）等等模块经常用私有化构造方法+全部静态化方法来设计这些工具类，这样使用起来就是类名+方法名来使用，请问这种设计方法有何利弊？（tij里曾说过:当你的程序充斥着过多的static时，或许你该想想换个设计了，且实际调用起来越看越像面向过程，虽然用起来时确实方便，不用新建实例）
部分静态方法还是可以的，比如：格式化日期、properties文件读写，控制台打印，字符集转换过滤等等。
不过大量使用静态方法确实是设计不够优化的表现，尤其是新手，经常会碰到一段代码不知道怎么才能大家共享调用，于是就静态之。
这个说到底还是要深入理解OO，理解扩展性、耦合性等非功能因素。
举例来说：字符集转换，
你可以写静态方法，Util.convertCharSet(String content,String from,String to);
也可以：
CharSetConverter cc=new CharSetConverter(from, to);
cc.convert(content);
如果你有大量的字符串需要转换的时候，显然后者的代码更加容易理解，因为不是每次都要带着from,to两个参数，
你可以说不要这两个参数（从哪种字符集转到另外一种字符集），那你的代码就是固定功能，没有扩展性的。
总体来讲，如果你确定这些东西都是工具，不涉及业务逻辑，用静态方法，我觉得没什么，方便很重要。
问题2：我的设计中经常用到抽象类，但却极少用到接口，这正常么？（我的理解是：接口就是抽象类更纯粹的一种表现，但意义是一样的，就是规范了一系列对象的所有动作，使使用这些服务的调用端可以和实际的实现相分离。）
正是接口的更纯粹抽象使得接口与抽象类不一样，而且，在模块之间，或者你对外提供API的时候，开放接口和开放抽象类是完全不同的。
作为你的API的使用者，如果你要别人提供的数据继承自你的抽象类，会有很大的制约性（因为人家可能已经继承自他自己的某个类了）。
所以，面向接口编程，就是为了完全的将合作双方隔离。
问题3：我为程序中的业务模型层、dao层分别建立了一个工厂，这个工厂以业务模型的名称或代号为参数，以switch\catch的方式去判断并返回所求的实例，但总觉得switch\catch相当臃肿，也觉得，工厂模式除了将对象的创建工作集中到了一处进行统一管理的同时，工厂自己也是够复杂的，尤其是什么工厂方法模式和抽象工厂模式。
工厂模式，可以使用反射机制来消除if switch。
当然，前提是你的类命名有一定的规范（与编号之间）。
部分静态方法还是可以的，比如：格式化日期、properties文件读写，控制台打印，字符集转换过滤等等。
不过大量使用静态方法确实是设计不够优化的表现，尤其是新手，经常会碰到一段代码不知道怎么才能大家共享调用，于是就静态之。
这个说到底还是要深入理解OO，理解扩展性、耦合性等非功能因素。
举例来说：字符集转换，
你可以写静态方法，Util.convertCharSet(String content,String from,String to);
也可以：
CharSetConverter cc=new CharSetConverter(from, to);
cc.convert(content);
如果你有大量的字符串需要转换的时候，显然后者的代码更加容易理解，因为不是每次都要带着from,to两个参数，
你可以说不要这两个参数（从哪种字符集转到另外一种字符集），那你的代码就是固定功能，没有扩展性的。
总体来讲，如果你确定这些东西都是工具，不涉及业务逻辑，用静态方法，我觉得没什么，方便很重要。
问题2：我的设计中经常用到抽象类，但却极少用到接口，这正常么？（我的理解是：接口就是抽象类更纯粹的一种表现，但意义是一样的，就是规范了一系列对象的所有动作，使使用这些服务的调用端可以和实际的实现相分离。）
正是接口的更纯粹抽象使得接口与抽象类不一样，而且，在模块之间，或者你对外提供API的时候，开放接口和开放抽象类是完全不同的。
作为你的API的使用者，如果你要别人提供的数据继承自你的抽象类，会有很大的制约性（因为人家可能已经继承自他自己的某个类了）。
所以，面向接口编程，就是为了完全的将合作双方隔离。
问题3：我为程序中的业务模型层、dao层分别建立了一个工厂，这个工厂以业务模型的名称或代号为参数，以switch\catch的方式去判断并返回所求的实例，但总觉得switch\catch相当臃肿，也觉得，工厂模式除了将对象的创建工作集中到了一处进行统一管理的同时，工厂自己也是够复杂的，尤其是什么工厂方法模式和抽象工厂模式。
工厂模式，可以使用反射机制来消除if switch。
当然，前提是你的类命名有一定的规范（与编号之间）。
ET_bug 2009-07-21
- 打赏
- 举报
路过，学习一下
sunnysin 2009-07-21
- 打赏
- 举报
静态如果可以用那就用，面向对象未必好，面向过程始终都占有一席之地。
模式不是一层不变，以人为本，应需而变。死忠对象，无异蠢才。
苍茫宇宙，皇者回归。技术之巅，谁与争锋。
模式不是一层不变，以人为本，应需而变。死忠对象，无异蠢才。
苍茫宇宙，皇者回归。技术之巅，谁与争锋。
sunnysin 2009-07-21
- 打赏
- 举报
接口就是借口吧，未必好哦。推荐使用混入模式，groovy编程。
yyyapple 2009-07-21
- 打赏
- 举报
去看看《代码大全》
sky663 2009-07-21
- 打赏
- 举报
一、 楼上的有人讲过，Static 的东西是程式一启动就会生成一个实例在内存中，如果静态的东西太多，会占用一些内存资源。除此之外，还有一个问题要注意，静态变量的值问题。
三、你的意思是一个工厂，根据一个代号什么的，取出相应的实例。
这样做是对的，但是看起来很庞大。我想这是因为你的实例化对象的方法的问题，一般工厂都会用反射来实例化对象，所有的实例，都只传入名称及参数就可以了。应该不会用到Switch。
三、你的意思是一个工厂，根据一个代号什么的，取出相应的实例。
这样做是对的，但是看起来很庞大。我想这是因为你的实例化对象的方法的问题，一般工厂都会用反射来实例化对象，所有的实例，都只传入名称及参数就可以了。应该不会用到Switch。
dinghun8leech 2009-07-20
- 打赏
- 举报
21楼的意见也很好，十分感谢。
加载更多回复（37）
