访问者模式分析--设计模式
23个设计模式中,大部分多写代码都是可以直接领悟到的。
但是访问者模式不是。一个原因是这个模式的实际应用场景在后端开发流程中特别难遇到(一般用于解决固定问题,游戏开发的复杂逻辑应该能经常遇到),
另外一个原因是这个模式的实现有点绕。
这一篇并不包含实践环节,因为我并没有实际遇到这样的需求,因此本篇只能记录下学习过程了。
23个设计模式中,大部分多写代码都是可以直接领悟到的。
但是访问者模式不是。一个原因是这个模式的实际应用场景在后端开发流程中特别难遇到(一般用于解决固定问题,游戏开发的复杂逻辑应该能经常遇到),
另外一个原因是这个模式的实现有点绕。
这一篇并不包含实践环节,因为我并没有实际遇到这样的需求,因此本篇只能记录下学习过程了。
习惯了golang的net/http/pprof的便利,c++的性能分析就显得繁琐了一点。
不过大致上还是一致的。
1 | centos: |
两个因素想做开源项目:
1 主导开发中间件系统的心愿已经达成,虽然中间磕磕碰碰的踩了很多坑。
但毕竟最终结果是好的。
唯一的遗憾就是没有开源了。
2 之前做了一些小网站,也累积了不少用户,但是对技术的磨练还是太少了。
特别是用户的增长出现瓶颈以后,架构和细节已经没有必要在优化了。这就让人产生了惰性。
认真做一个开源项目,会有bug issue和功能的issue。会有人去推动你不断探究。
我认为这会收获巨大。
具体项目没想好,可能是基础库(偏网络高并发?又一个轮子?),也可能是比较擅长的存储系统。
有些博文会把对象分为类模式和对象模式,在我看来这两种模式是可以相互转化的。类模式主要强调类的继承决定结构或者行为,是通过继承的延迟到子类去实现,来完成模式。而对象模式则主要强调对象的关联来完成模式(关联一个接口用桥接模式完成继承,关联一个对象用适配器模式完成调用)。所以所有的类模式都可以转化为对象模式,而对象模式则不一定可以转化为类模式。
对写golang的同学来说这一点很容易理解,因为golang只有关联没有继承。想要通过继承来延迟到子类去实现,实际上子类是通过关联一个实现了某个接口的对象以及父类,然后把关联的过程封装在创建过程中。这样不同的子类通过动态的组合不同的对象来完成继承。(实际就是桥接模式)
我认为,控制反转和模版模式以及框架的概念是类似的,而控制正转类同于策略模式,库。
反转的是依赖关系,对框架代码来说,实现的就是模版模式。使用框架的代码,其实被反转调用了。而库则是主动去调用的,是一种策略模式。
因为控制反转是一种设计模式,因此所有语言都存在。
例如C,JS是以回调函数实现。而Python作为一种动态语言,这方面的支持更为强大。
对于OOP的静态语言(Cpp,Java,Golang等等)来说,通过继承的实现更为自然(Golang通过桥接模式变相实现)。
最近在做的项目设计到一些金钱交易方面的事情。涉及到一些分布式事务的逻辑。
参考了一些资料,做一些总结。
一部分资源的数据更新以后,怎么保证另外一部分资源的数据也必须更新成功。
1 | Name 媒体广告名称 |
可以根据Channel和Cs分析属于哪一类节目
golang字符处理已经踩过好几个坑了,记录一下
用的mysql版本比较老,不支持emoji,所以需要golang来去除emoji表情
判断思路是普通汉字utf8下都是3字节内,而emoji表情是4字节,如果大于4字节就过滤掉即可
1 | import "unicode/utf8" |
之前用触发器做数据统计
然后还是一不小心踩坑了
触发器新建了一张fileinfo表,file表中增删查改的信息都会以触发器的形式去修改fileinfo表
后来发现由于mysql是行级锁,由于file表的操作QPS会很高,这个行级锁会造成很大的性能损失
所以需要把增删查改写入随机行。