基于C++的纯面向对象的通用高性能大并发TCP-SERVER/CLIENT开发框架实践系列之前言篇-阿里云开发者社区

开发者社区> 开发与运维> 正文
登录阅读全文

基于C++的纯面向对象的通用高性能大并发TCP-SERVER/CLIENT开发框架实践系列之前言篇

简介:   基于C++的纯面向对象的通用高性能大并发TCP-SERVER/CLIENT开发框架实践系列之前言篇 yijian 2008-12-21 technologier@126.com 1. 回首 工作几年了,没什么沉淀,不是忙工作就是忙着休息,大四和工作的第一年还偶尔在一些技术论坛写写文章,但是这都是N年前的事了,以前经常动手编写小程序的习惯也在三四前中断了。
 

基于C++的纯面向对象的通用高性能大并发TCP-SERVER/CLIENT开发框架实践系列之前言篇<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />

yijian 2008-12-21 technologier@126.com

1. 回首

工作几年了,没什么沉淀,不是忙工作就是忙着休息,大四和工作的第一年还偶尔在一些技术论坛写写文章,但是这都是N年前的事了,以前经常动手编写小程序的习惯也在三四前中断了。如今已经是三十而立之人,面对两手空白的现状,难免会有些失落和遗憾。激情好象离我有点儿远了,但随着工作的时间越久,感觉自己有很多的东西需要表达出来,一是为自己做做总结,二是希望一些经验可以和大家一块探讨。对说得不对的地方,请大家多拍拍砖头以协助改正。

2. 关于标题

文章的标题非常长,但也代表了本系列文章的目的:一是要实现一个基于TCP的Server和Client框架;二是框架要求通用;三是要求框架性能高、能够满足大并发环境;三是框架的实现采用C++;四是要采用纯面对象开发,而不仅是一个类的包装。

3. 面向对象

本人是面向对象技术的爱好者,平常和人在这方面交流不多,希望借这个机会结交更多的面向对象爱好者,以提升这方面的能力。

接触面向对象已有几载,虽仍在不断学习当中,但心中有一些感想希望可以和大家一块讨论。采用面向对象的分析和设计,能给我一处非常愉快的感觉。在我看来,面向对象设计就如同摆积木游戏,甚至可以拿来和管理一个公司做对比,其中甚有非常多的相同之处,通过这样的对比,更能快速理解面向对象方法的思想。

4. 设计模式和面向对象

设计模式和面向对象关系密切,各种模式离不开面向对象的特性。很多初接触者都对设计模式抱以非常大的兴趣和热情,但常感觉设计模式较难消化,甚至出现为模式而设计的情况。

模式是经验,面向对象是思想和基本概念,如果对面向对象理解不够,那学习起设计模式估计会遇到较大的阻力。个人感觉,学习设计模式和面向对象方法不如从面向对象的五大基本原则下手,这样能事半功倍,达到磨刀不误砍柴的效果。

5. 三大基本特性

透切理解面向对象三大基本特性是理解面向对象五大基本原则的基础,这三大特性是:

5.1. 封装

这是面向对象第一大特性。不能说用一个类将所有成员包裹起来了就将封装,private/protected/public这三大可见性非常重要,也就是我们不但要封装好,而且要尽可能地使用可见范围小,很多公司都有授权最小化原则,是同一个道理。

5.2. 继承

继承最重要的一个目的是代码重用。

5.3. 多态

在C++中多态分静态和动态两种:静态是指模板,它是编译期的多态;而动态是指虚拟,它是运行期的多态。使用好这个特性对改善性能的结构意义非常重大,同时它也是三大基本特性中最难把握控制好的一个。

6. 五大基本原则

6.1. 单一职责原则SRP(Single Responsibility Principle)

是指一个类的功能要单一,不能包罗万象。如同一个人一样,分配的工作不能太多,否则一天到晚虽然忙忙碌碌的,但效率却高不起来。

6.2. 开放封闭原则OCP(Open-Close Principle)

一个模块在扩展性方面应该是开放的而在更改性方面应该是封闭的。比如:一个网络模块,原来只服务端功能,而现在要加入客户端功能,那么应当在不用修改服务端功能代码的前提下,就能够增加客户端功能的实现代码,这要求在设计之初,就应当将服务端和客户端分开,公共部分抽象出来。

6.3. 替换原则(the Liskov Substitution Principle LSP)

子类应当可以替换父类并出现在父类能够出现的任何地方。比如:公司搞年度晚会,所有员工可以参加抽奖,那么不管是老员工还是新员工,也不管是总部员工还是外派员工,都应当可以参加抽奖,否则这公司就不和谐了。

6.4. 依赖原则(the Dependency Inversion Principle DIP)

具体依赖抽象,上层依赖下层。假设B是较A低的模块,但B需要使用到A的功能,这个时候,B不应当直接使用A中的具体类:

 

而应当由B定义一抽象接口,并由A来实现这个抽象接口,B只使用这个抽象接口:

 

这样就达到了依赖倒置的目的,B也解除了对A的依赖,反过来是A依赖于B定义的抽象接口。

通过上层模块难以避免依赖下层模块,假如B也直接依赖A的实现,那么就可能造成循环依赖。一个常见的问题就是编译A模块时需要直接包含到B模块的cpp文件,而编译B时同样要直接包含到A的cpp文件。

6.5. 接口分离原则(the Interface Segregation Principle ISP)

模块间要通过抽象接口隔离开,而不是通过具体的类强耦合起来。

7. 系列结构

本系列将由四大部分组成:第一部分是前言篇,第二部分是基础篇,第三部分是服务端篇,第四部分是客户端篇。

7.1. 前言篇

概况性地介绍本系统,及写作出发点和目的,以及系列的内容。

7.2. 基础篇

服务端和客户端框架更底层的通用类设计。由于这部分类间的关系简单,打算描述简单些以节省时间,并不提供实例。

7.3. 服务端篇

专注于服务端的介绍,将包括较为详细的类图和时序图,及部分伪代码,并尽可能地提供一个实例,打算以一个HttpServer为实例,静态页面性能要求高于ngix/lighttp/apache等。

7.4. 客户端篇

专注于客户端的介绍,将包括较为详细的类图和时序图,及部分伪代码,并尽可能地提供一个实例。

8. 写作计划

最近工作是我有生以来最忙的一段时间,连续几个周五晚上都在加班,估计要持续到明年三四月份。所以,只能在周未的时候偷点时间来写,目标是在春节期间完成。

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享:
开发与运维
使用钉钉扫一扫加入圈子
+ 订阅

集结各类场景实战经验,助你开发运维畅行无忧

其他文章