如此使用单例模式!

最近拿到一个项目,大致扫了一下,发现大多数的代码都是如下的结构:


public class User {
private String userName;

public String getUserName() {
return userName;
}

public void setUserName(String userName) {
this.userName = userName;
}
}

public class UserRule {
private static UserRule instance = null;

public static UserRule getInstance() {
if (instance == null) {
instance = new UserRule();
}
return instance;
}

public User AddUser(String userName) {
// add a new user operations
}
}


先不说问题,来看看这样做的一些可取之处:
1、设计简单。系统的设计在这样的结构下其实就是贫血类的设计,剩下的就是在Rule类中增加相应的方法。
2、各个模块的开发可以同时进行。各人根据要求定义好模块相应的类,剩下的就是缺啥补啥了。

然后说问题:
1、首先该单例实现就有问题了,这样的实现并不能保证线程安全。不过好在其实这个UserRule本身也没有字段之类的东西,不单例其实也没多大影响。所以我想这个单例丢在这里估计只是为了写代码的时候方便点。
2、这种做法应对需求变化的结果就是不断的在UserRule中添加新的满足需求的方法,最后天知道这个方法到底干嘛的。
3、我想这样的系统应该性能上很差了,可奇怪客户用到现在居然没一点性能上的反馈。不过性能这块只是我的一个感觉,还没有对这样的系统做一个压力测试,无法提供实际情况。

不知道还有没有其他的缺点,欢迎各位来分析分析。
  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值