自定义博客皮肤VIP专享

*博客头图:

格式为PNG、JPG,宽度*高度大于1920*100像素,不超过2MB,主视觉建议放在右侧,请参照线上博客头图

请上传大于1920*100像素的图片!

博客底图:

图片格式为PNG、JPG,不超过1MB,可上下左右平铺至整个背景

栏目图:

图片格式为PNG、JPG,图片宽度*高度为300*38像素,不超过0.5MB

主标题颜色:

RGB颜色,例如:#AFAFAF

Hover:

RGB颜色,例如:#AFAFAF

副标题颜色:

RGB颜色,例如:#AFAFAF

自定义博客皮肤

-+
  • 博客(69)
  • 收藏
  • 关注

原创 《数据访问对象模式(极简c++)》

在业务中如果品类过多,在调整品类信息或者增加种类时,自然而然想到将品类维护到一个map或者vector中。每次使用全部,或者按需取。: 将数据存取操作从业务逻辑中分离出来,使得数据操作和业务逻辑各自独立,易于维护和扩展。

2024-04-17 12:31:58 671

原创 《组合实体模式(极简c++)》

组合实体模式的本质思想是将一组相关对象封装到单个对象中,并提供统一的接口来访问和操作这些对象,以简化复杂性并提高系统的可维护性。,在业务中自然而然就会想到的设计模式。如果没想到,说明在对应的场景没啥用。

2024-04-16 22:07:06 473 1

原创 《业务代表模式(极简c++)》

和策略模式没有本质的区别,都是隔离调用者和多个可能被调用者的方式。只是被调用者是算法模块,还是业务模块。:通过引入一个代表对象,将客户端与具体业务逻辑解耦,实现业务访问的统一管理。

2024-04-14 21:43:18 493 1

原创 - 工程实践 -《分布式系统可用性保证方法和实践》

可用性是指一个系统在用户需要时能够正常提供服务的能力。需要注意,从用户的角度来看,可用性针对的功能,而不是某个系统。另外用户群体不一样,则可用性则一样。如GPT的聊天功能,“可用”意味着能秒级响应人类的输入,而对银行的大额转账功能,“可用”意味者秒级接受用户请求,小时级甚至天级完成实际转账。总的来说,前置手段,无论哪种方式,一定是两个目的之一提前暴露可能的问题、通过抽象标准流程减少操作问题。而实践中,我们更多的精力是,结合业务,在可用性概率和成本之间做取舍。总的来说,

2024-04-13 16:19:46 1403

原创 《MVC模式(极简c++)》

Controller接受输入之后,更新Model,组织View。将本地缓存数据和展示数据解耦合,让不同组织之间合作效率更高。:MVC模式,最开始是做桌面应用GUI的。后来也被广泛应用在前后端结合的服务中,将前端和后端解耦,对团队效率提升极大。

2024-04-12 12:30:42 419

原创 《访问者模式(极简c++)》

对大部分情况下,直接修改类中的操作接口就行,如果有类似操作,一般直接抽象一个操作类,和现有类组合就行。这样代码逻辑也会更易读。数据类型A基本不变。但是对应的具体操作O会变化,把这些操作O抽象成一个类B。在类A要操作O的时候,传入类B,以触发动作。

2024-04-11 13:23:09 629

原创 《模版模式(极简c++)》

在模版模式中,将逻辑的结构定义在一个父类中,而将具体的步骤实现延迟到子类中。这样可以在不改变算法整体结构的情况下,让子类自由地实现某些步骤,从而实现算法的定制化。在一个部门多个服务,且有相同部分可以抽象时,使用一个基类来约束大家的业务行为,不仅降低新人培养成本,也让不同人切换维护的服务成本更低。模式说明、本质思想、实践建议、代码示例。

2024-04-09 12:55:37 771

原创 《策略模式(极简c++)》

如果算法模块是一个团队开发的,让算法团队提供统一接口,以减少服务端和策略部分耦合。如果算法模块是多个团队开发,应该是服务端同学根据多个算法模块的语意,使用策略模式,让算法模块易于使用。:策略模式通过将算法封装成独立的策略类,使得这些算法可以相互替换,客户端可以根据需求选择不同的策略。模式说明、本质思想、实践建议、代码示例。

2024-04-08 13:00:37 561

原创 《空对象模式(极简c++)》

空对象模式的本质思想是在缺少有效对象时,提供一个默认的“空”对象,使得客户端代码无需特殊处理空值情况,从而简化代码逻辑。,这里省去的代码检查空值以及简化的代码结构,很可能会在未来隐藏关键问题。极大地增加了运维成本。本章简要说明空对象模式。模式说明、本质思想、实践建议、代码示例。

2024-04-07 12:36:37 758

原创 《状态模式(极简c++)》

在实际开发中,状态一般用一个变量表示就够了,很少会抽象成一个类。如果,状态需要多个变量表示,且此类状态有固定的方法,则可以使用状态模式。这里封装的是当前状态,以及状态附属的行为。另外,不管是“状态类”作为参数传给“上下文类”执行,还是“上下文类”传给”状态类“执行,没有本质的区别。: 状态模式的本质是将对象的状态抽象为一个独立的类,使得对象在不同状态下有不同的行为,并且能够动态地切换状态。

2024-04-06 09:33:55 992

原创 《观察者模式(极简c++)》

观察者模式的本质是将对象之间的依赖关系从硬编码的方式转变为松耦合的方式,使得对象之间能够动态地交互。:一种软件内部模块之间的异步通知方式之一。十分好用,在软件系统中十分常见。

2024-04-05 22:15:06 699

原创 《备忘录模式(极简c++)》

建立一个M类,可以由A类生产。A类也可以由M类还原。类似于,word写文章时,会自动保存中间状态,而这些中间状态,也可以完全恢复当时的文章。:在低频且重要的逻辑中使用,因为此模式不仅费内存,也费CPU。

2024-04-04 20:51:35 886

原创 《中介模式(极简c++)》

对象和对象之间的交互逻辑有共性,且对象之间接口需要解耦时使用。和代理模式类似,也是在隔离组织的时候引入,如一个组织开发sdk,另一个组织开发服务时。代理模式隔离的是,访问者和被访问的资料,中介模式隔离的是沟通者和沟通者。不论哪种模式,只有当两边在不同的组织或者被不同的人维护时,才有必要使用,否则降低了开发、维护效率,也降低了代码运行效率。:通过引入一个中介者对象,将系统中的对象解耦,使它们不再直接相互交互,而是通过中介者进行协调,从而降低系统的复杂性。

2024-04-03 14:44:04 439

原创 《迭代器模式(极简c++)》

c++以及大部分语言中,都有自己封装好的第三方迭代器。如std::vector,业务代码一般不需要单独封装,而是把基类指针放到容器中,就可以实现去除实现细节的遍历。:将对容器的遍历操作封装到迭代器对象中,使得遍历操作可以独立于容器实现。这样,容器可以改变其内部结构而不影响遍历操作。

2024-04-03 14:19:42 944

原创 《解释器模式(极简c++)》

解释器模式通过将语言的文法表示为类的层次结构,然后建立解释器来解释这些类,从而实现对语言的解释和执行。:除了正则表达式,文本相关的解析等特别灵活、规则链复杂的场景。95%以上的业务用不到。

2024-04-02 21:55:38 630

原创 《命令模式(极简c++)》

把调用的语义封装在一个具体的命令对象中,再创建一个执行调用命令的方法,这样对于所有传入的命令,都可以复用“调用命令的方法”。比如“一只鸟飞起来,然后吃东西”,会有一个有一个调用命令的方法,做的事情是“先执行A,再执行B”,然后传入命令A为“燕子飞起来”,传入“燕子吃东西”。核心收益是,命令调用者的逻辑就可以复用了。:在命令调用顺序固定,且使用高频时,把这部分逻辑抽象出命令模式。降低命令流程和命令本身的耦合。注意这块不适合放在业务占用cpu极高的代码部分,它对性能有少量影响。

2024-04-01 13:17:29 786

原创 《C++工程方向面试记录》

本硕中部985,工作2-3年,本硕均非计算机专业。毕业后一直在某研究所工作。项目经历主要面向国家项目,即项目为处理数据量不大,更偏向于模块多,链路长。此系列,是本人免费提供的,大厂面试模拟,经本人同意后发出。

2024-03-31 19:41:16 857

原创 - 工程实践 - 《高并发系统正确性保障 - 锁的范式》

硬件支持锁,本质就是,在CPU系统中,如何保证一个表示权限的变量,一定时间界限内,只被一个CPU核写入,且下一个CPU在写时,保证已经获取到最新的数值。这里还有一个可以断言的,,注意这里的性能问题不是加锁和释放锁本身耗费资源太多,而是加锁之后业务代码持有时间太长,对其他线程阻塞导致的,以c++互斥锁为例,这个用户态的锁,在现代计算机,平均一次获取仅需要5-15ns。同理,如果信息传递是不需要时间的,且我们认为时间是离散的,那就不再需要锁,比如量子计算机,就是一个不需要锁的计算机,不过这不在我们讨论范围中。

2024-03-30 18:45:52 1448

原创 《责任链模式(极简c++)》

该模式会降低性能,且分离的处理逻辑分支,会降低代码可读性。当遇到逻辑复杂,判断分支繁琐的逻辑,我们要做的是解耦,而不是把代码简单地拆开。:责任链模式的本质思想是将多个处理者组成一条链,依次尝试处理请求,直到找到能够处理该请求的对象为止。

2024-03-29 12:53:35 684

原创 《代理模式(极简c++)》

确保代理和真实对象具有相同的接口,以便可以无缝替换。代理的核心作用是隔离,这里要实践中,:代理模式的核心思想是在访问对象时引入一定程度的间接性,以在访问时进行一些额外的处理。,也就是两个团队维护同一个的系统时,使用代理模式,将极大提高组织开发效率。收益最高的是组织隔离。

2024-03-29 12:35:44 475

原创 《享元模式(极简c++)》

在有大量相似对象时,且相似部分状态不变时使用(如果要变。则需要对象提供的接口全部线程安全,则有性能风险,需要慎重):将对象分为可共享的内部状态和不可变的外部状态,通过共享内部状态来减少对象的数量,以节省内存和提高性能。

2024-03-28 13:09:23 711 1

原创 《外观模式(极简c++)》

【代码】《外观模式(极简c++)》

2024-03-27 19:34:21 756

原创 《装饰器模式(极简c++)》

派生类和装饰类都继承Base,然后装饰器类中放一个Base指针,存派生类。这样装饰器类和派生类可以放一个数组中,调用相同接口,这样部分类的功能看起来像被装饰了。前面是核心思想,基于这个再扩展,很容器基于装饰器加装饰器,或者把有相似接口的装饰器抽象出一个装饰器基类。方案: 装饰类和派生类同根,然后装饰类中放一个派生类,以在接口不动的情况下增加功能。注意组合关系,确保装饰器和被装饰对象之间的接口一致。缺点: 增加了许多小对象,易于出错,不易调试。装饰器的功能应该是可组合的,可叠加的。

2024-03-26 19:27:40 663

原创 《组合模式(极简c++)》

类A中有一个数组,数组里面都是A*(可以实际指向A的派生类),这样可以建一个全是A的树。:在运行时,需要构建一个全是相同基类的树,并要统一处理时使用。本章简要说明组合模式。模式说明、本质思想、实践建议、代码示例。

2024-03-25 17:31:38 478

原创 《面试模拟(免费) - C++工程方向》

此面试可为应聘者提供真实反馈。简历和面试过程不会以任何形式给第三方(包括我当前所在公司)。以个人的名义,提供c++工程方向的大厂面试模拟,

2024-03-24 00:46:40 1077

原创 《过滤器模式(极简c++)》

示例代码// 基类 Birdpublic:// 具体类:鸟类public:} // 飞行鸟public:} // 水中鸟// 具体过滤器:飞行鸟过滤器public:// 过滤器使用示例}else {/*输出:*/return 0;

2024-03-23 21:56:17 580

原创 《桥接模式(极简c++)》

模式说明、本质思想、实践建议、代码示例。本章简要说明桥接模式。

2024-03-22 12:49:37 820

原创 《适配器模式(极简c++)》

适配器模式通过引入一个适配器类来兼容不同接口,使得原本无法一起工作的类能够相互合作。它将一个类的接口转换成客户端所期望的另一个接口,使得原本由于接口不匹配而无法在一起工作的类能够协同工作。:合并多个不同的类,提供同一的调用接口,是在应用维护中使用,以解决设计时未考虑到的共性问题。模式说明、本质思想、实践建议、代码示例。本章简要说明适配器模式。

2024-03-21 12:33:21 658

原创 《原型模式(极简c++)》

难以维护,且只能在小范围使用,另外指向派生类的基类的深拷贝效率低,所以使用频率极低。如果实在需要,在基类中维护一个基础类型,转换时,通过基础类型判断,转换成派生类再拷贝。:通过基类虚函数,规范指向派生类的基类的拷贝行为。模式说明、本质思想、实践建议、代码示例。本章简要说明原型模式。

2024-03-20 19:03:54 544 1

原创 《单例模式(极简c++)》

本文章属于专栏继续上一篇。本章简要说明单例模式。本文分为模式说明、本质思想、实践建议、代码示例四个部分。模式说明本质思想。

2024-03-19 13:15:36 900

原创 《建造者模式(极简c++)》

直到设计、开发时发现,对象的构建过程比较复杂,且在较多场景需要构造,且构造过程不同。个人更偏爱工厂模式来做创建,将类的创建过程封装到一个函数,如果有不同的构建需求,通过输入参数走不同的构建逻辑,如果类的构建十分负责,如构建一个“人”,则通过组合的方式,构建多个类(如手脚头等),挂在“人”下面。: “类构建过程”和“类的属性、结构、行为”分离。将对象的构建过程拆分成多个步骤,并定义一个抽象接口以及具体的实现类来完成每个步骤。这里的本质是大部分场景,“未来降低的维护成本”低于“当前增加的维护成本”

2024-03-18 13:09:22 738

原创 《工厂模式(极简c++)》

本章简要说明工厂模式如何实践。并给出我认为的最佳实践代码。

2024-03-16 14:00:44 974

原创 《设计原则》

个人说明:原则是为了目标设定的,设计目标是:对过去的系统稳定,对未来的系统扩展成本低。不管什么原则,都是为了这两个核心目的而服务的。其中开闭原则是为了系统稳定,其他原则的核心思想都是,在扩展时,尽量改动少的逻辑,降低开发成本。原则不是盲目使用和万能的,当某些场景,使用该原则违背了目的,我们需要修改甚至放弃它。记住目的,远比记住原则重要。

2024-03-15 23:14:11 644

原创 - 概述 - 《设计模式(极简c++版)》

此书从1994年出版至今已有30年,虽然大部分依然十分有效,但是难免部分内容已经不适合现代的开发习惯,或者几乎不在实际生产中使用。中说的一样,我会把更多的精力放在那些使用频率高的场景中。用20%的精力学习80%的常用场景,然后在实际生产中,根据业务和团队特点,针对性学习,可以做到事半功倍。本系列,主要结合个人经验,对《设计模式:可复用面向对象软件的基础》书中经典设计模式,用极简的语言说明核心作用和使用场景,并用c++实现。最后,本系列的文章,是我在工作之余,从个人历史的笔记、总结、分享中提炼出来。

2024-03-13 12:46:37 1368 2

原创 《Effective Modern C++》- 极精简版 36-42条

本文列出《Effective Modern C++》的36-42条的个人理解的极精简版本。Item39、对于单次通信考虑使用void的futures。

2024-03-12 07:34:41 509

原创 《Effective Modern C++》- 极精简版 30-35条

本文列出《Effective Modern C++》的30-35条的个人理解的极精简版本。

2024-03-11 13:17:05 535

原创 《Effective Modern C++》- 极精简版 22-29条

本文列出《Effective Modern C++》的22-29条的个人理解的极精简版本。

2024-03-10 15:33:21 1099

原创 《Effective Modern C++》- 极精简版 15-21条

这条是一个通用的思想,无论是语法还是业务的规则模糊或者复杂时,把使用者的期望明确地持续展示,减少维护成本,和出错概率。本文列出《Effective Modern C++》的15-21条的个人理解的极精简版本。

2024-03-09 22:01:33 1157

原创 《Effective Modern C++》- 极精简版 5-14条

本文列出《Effective Modern C++》的5-14条的个人理解的极精简版本。

2024-03-08 13:04:42 1067

原创 《Effective Modern C++》- 极精简版 1-4条

本文列出《Effective Modern C++》的1-5条的个人理解的极精简版本。

2024-03-07 13:16:52 1406

空空如也

空空如也

TA创建的收藏夹 TA关注的收藏夹

TA关注的人

提示
确定要删除当前文章?
取消 删除