有些工具很棒,有些设计很酷,有些知识很有用。
会用,熟悉,亦或者别人问起来也能说出个一二三四来,正儿八经测试或许还能拿高分。但是没用
果然,课上学的不是自己的,自己能用也不算会,只有踩过坑趟过雷才别有风味(用词大雾(๑•̀ㅂ•́)و✧
哦多么痛的领悟(捂脸
-
萌新的时候曾经有想法,想实现根据收到的命令(字符串)调用相应方法。
因为命令很多,不想用if else if ...
,为此折腾了很久,最后赶时间用了switch
(这里还踩了个坑,涉及到Enum
)。
为此遗憾了很久。
后来学反射,卧槽nice啊,hhhh "select * from xxx where id =" + id +" and name = '" + name + "'"
,
最开始也没什么工具,发现load(String queryStr, Object params...)
的实现感觉特别牛b
像这种("select * from xxx where id = ?1 and name = ?2", id, name)
感觉就简洁了很多。
但用的别人封装好的东西,也只告诉了一个用法,没有具体实现。
想自己拿去用,轮到自己去尝试的时候碰了许多壁,后来也就没有再折腾了。- 传的参数的个数为什么可以是0,1,2…?
- 传的参数是什么类型呢?我去,我得把这些都考虑一遍,该写多少个方法,会不会有漏。。。?
- 为什么是
?1
和?2
,而不是?
呢?,我想直接split(“\\?”),参数的顺序让用的时候传的时候注意一点好了,至于重复,同一个参数用几遍就传几遍好了。。。 - 。。。 果然,我还是太拿衣服
- 关键词
可变长参数
、instance of
、正则表达式
- 这么多
xml
简直不能忍!- 哇注解真是个好东西。
- 每来个请求,就开个线程处理
Socket
,没有消息就会一直阻塞。- 对于频繁地请求短连接来说,每次频繁地创建、结束
Socket
,不如一直保持着不断掉; - 对于长连接来说,消息和消息中间的那段等待过程占着茅坑实在是浪费资源
- 所以,非阻塞地实现设计是件非常棒的事情,虽然不可避免的引入了缓存,同时还要额外添加一个请求处理对应机制
- 当然,假设每次请求都是数据始终在传输地不间断连接,这种设计也不见得会有啥优势😳
- 对于频繁地请求短连接来说,每次频繁地创建、结束
- 又得到了一串字符串,匹配,处理,难道又要
if else if ...
- 匹配方法+处理方法定义一个
interface
,一个具体方法实现对应一个实现类,再加一个代理,实现对外的方法。 - 即 遍历实现类集合的匹配方法,匹配成功则调用对应的实现类的具体处理。
- 实现类集合如何获得?类如何实例化? ==> 可以扫描指定路径 + 注解配合获取类,然后通过反射手段获取实例。
- 如何扩展 ==> 新增匹配+处理,在指定路径实现接口,并在实现类上加注解即可
- 想是这么想,做也是这么做的,就是不知道效果如何…
- 匹配方法+处理方法定义一个