只显示主题贴
还爱着咖啡啊，象曾经爱着那个伤透了我的心的女孩一样爱，
虽然最后一次去看它，变的不再认识我了，可是我还是爱着它的，
虽然我决绝的转身而去，可是我还是爱着它的，
心理想着找一个稳定的家再接回咖啡，还是爱着它的，
孤独的夏天，和小咖啡一起相伴，那是我对她爱的象征，没了，再也不能见到了，这样的结局怎么让人接受，还要再一起的，怎么能这样。。。
从转身那刻起，就把不认得我的它如那绝情的女孩一样看待了，我不爱
一年多了，我依然没找一个可以安顿它的合适地方，我不爱
一年多了，我没有去看过它一次，我不爱
梦见自己掉了牙齿，却没想到是咖啡，我不爱
我不配爱咖啡，可是我的泪在流呀，可是。。已经没 ...
- 进入论坛 海阔天空 版
ouspec 写道wolfsquare 写道二楼还是抢手货？
我的二楼还卖不出好价钱呢 ：（
我就喜欢多层的二楼，因为家里有老人，楼层低一点会方便一点。上海春冬天阴冷潮湿，一楼光线又不好，所以二楼对于家里有老人的是不错的选择。
其实二楼光线也不好，不过既然是为老人考虑，就很难两全其美
- 进入论坛 海阔天空 版
1.首先保证各系统自己的帐正确，是平的。
2.两系统间通过多种方式对帐(即时处理，日对帐，月对帐)
鉴于银行业务数据量的特征，估计不会存在大范围内的事务控制。
国内银行我不知道，但是我知道UBS的系统是存在着手工纠正这种机制的。
- 进入论坛 Java 版
ithero 写道我关心的如果采用OSGI体系,那目前的如我的Struts+Spring+Hibernate如何来组织呢?事务控制,权限安全等等..它们之间如何组织调度?
OSGi 需求源自于部署和环境的要求，不是来自于普遍意义上的开发要求（事务..），更和普遍意义上业务需求没有关系(权限,工作流...)。
- 进入论坛 Java 版
1.可配置(可调整，或者说有足够多的参数）
2.方便(参数多了就要提供默认值，简写API声明）
3.可扩展(这里没有3，4年痛苦经验估计很难写得出容易扩展的API)
- 进入论坛 Java 版
楼主说的问题不仅仅是接口的问题，而是如何设计一个合理API的普遍共性要求。这个问题的答案很简单：要不要由使用者说了算，而不是设计者。参考一个系统或者项目和客户的关系。一个设计合理的API是能够提供足够的灵活度，允许使用者能作调整或者扩展来完成目前其不能完成的功能。拿上面的例子来说:
1.把一个字串写入文件
其对应接口或实现 则是:
write(String content){
...
}
考虑到客户不仅仅是需要将字串写到固定的一个文件，那么需要改为:
write(String fileName,String content)
如果需要避免每次都打开文件，那么实际上需求变 ...
- 进入论坛 Java 版
评论排行榜