|
锁定老帖子 主题：如何合理使用java中的静态成员
该帖已经被评为新手帖
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2007-03-30
使用静态成员变量和静态方法的缺陷是显而易见的。对于其依赖的bean，你根本没有办法进行依赖注入，只能自己去lookup，，这当然就违反了基本的解藕原则，这就是为什么尽量避免使用静态方法的根本原因。
|
| 返回顶楼 | |
|
发表时间：2007-03-30
也就是说，由于静态方法阻碍了面向接口编程以及违反了基本的解藕原则，在编程的过程中需要尽量避免使用，这是构建的时候需要遵守的一个原则。但另一方面，由于静态成员变量和静态方法在多个实例中保持单一性的特点，在打造通用工具类或是创建一些公用配置的时候是可以考虑的。
那看来将DAO方法声明为静态并不明智了！ |
| 返回顶楼 | |
|
发表时间：2007-03-30
SunMicro 写道 也就是说，由于静态方法阻碍了面向接口编程以及违反了基本的解藕原则，在编程的过程中需要尽量避免使用，这是构建的时候需要遵守的一个原则。但另一方面，由于静态成员变量和静态方法在多个实例中保持单一性的特点，在打造通用工具类或是创建一些公用配置的时候是可以考虑的。
那看来将DAO方法声明为静态并不明智了！ 构造全局唯一实例的办法有很多种，例如在web应用中，可以保存在ServletContext中，或者放在应用服务器的JNDI中，或者使用spring的时候，构造一个spring的singleton bean等等。 只有那些不依赖其他bean的，纯工具性类才可以考虑使用静态方法调用。 |
| 返回顶楼 | |
|
发表时间：2007-03-30
除了依赖注入之外，静态方法也不支持接口和多态，所以在业务层也不易采用
|
| 返回顶楼 | |
|
发表时间：2007-03-30
robbin 写道 SunMicro 写道 也就是说，由于静态方法阻碍了面向接口编程以及违反了基本的解藕原则，在编程的过程中需要尽量避免使用，这是构建的时候需要遵守的一个原则。但另一方面，由于静态成员变量和静态方法在多个实例中保持单一性的特点，在打造通用工具类或是创建一些公用配置的时候是可以考虑的。
那看来将DAO方法声明为静态并不明智了！ 构造全局唯一实例的办法有很多种，例如在web应用中，可以保存在ServletContext中，或者放在应用服务器的JNDI中，或者使用spring的时候，构造一个spring的singleton bean等等。 只有那些不依赖其他bean的，纯工具性类才可以考虑使用静态方法调用。 的确如此，看来除了纯工具类，以后不用考虑静态方法了 |
| 返回顶楼 | |
|
发表时间：2007-03-30
cozone_柯中 写道 robbin 写道 SunMicro 写道 也就是说，由于静态方法阻碍了面向接口编程以及违反了基本的解藕原则，在编程的过程中需要尽量避免使用，这是构建的时候需要遵守的一个原则。但另一方面，由于静态成员变量和静态方法在多个实例中保持单一性的特点，在打造通用工具类或是创建一些公用配置的时候是可以考虑的。
那看来将DAO方法声明为静态并不明智了！ 构造全局唯一实例的办法有很多种，例如在web应用中，可以保存在ServletContext中，或者放在应用服务器的JNDI中，或者使用spring的时候，构造一个spring的singleton bean等等。 只有那些不依赖其他bean的，纯工具性类才可以考虑使用静态方法调用。 的确如此，看来除了纯工具类，以后不用考虑静态方法了 如果在c/s模式中使用spring，spring的bean工厂的引用保存在哪里呢，应该还是做一个hardcode的单例模式来保存这个引用比较好吧，这时候static的方法又有用了，呵呵 |
| 返回顶楼 | |
