论接口的封装能力

简介: 论接口的封装能力

刚入职行业不到一年的菜鸟的心得体会,真实感受,不喜勿喷。

       为什么想到封装呢?还不是因为踩过坑,最近越来越感觉,直接用一些开源库很不方便,而且用起来总是忘塞。

       1.在工程开发过程中,我们不可避免的会用到其他人封住好的库。当然,作为程序员的基础素养之一,我们也得会封住一些好用的库,不仅仅是为了更好的迭代工程,更为了更好的使用一些开源库。

       2.说到开源库,最近蛮烦恼塞。因为刚入职从事程序员行业,这段时间一直在接触开源库还有一些开源框架。(我感觉看多了,开始习惯看源码了,之前都直接看博客。额,看不可的效果不可描述,总感觉很多时候看不明白,所以塞,不如看源码里的例子,遇到具体的点没明白的再去百度或者请教前辈。)

       3.最最重要的一点就是很多开源库为了支持更多的功能,在使用过程中会比较繁琐,并且很多时候我们只想使用一部分功能,通常我们会选择提前做一层封装。(自己封装的塞,肯定用得爽,虽然封住过程有点痛苦塞,长痛不如短痛塞)

封住一定要很规范

       个人觉得如果业务很简单,其实好用就行了,封装最初的目的也是为了好用。如果比较复杂的设计,比如好几个库杂糅在一起,而且之后会有功能扩展的需求,那么这个时候就得先考虑下,如何设计会比较好了。

       对于第一种情况,就不过多的描述了,很简单的。通常可以用C方式,也可以采用C++类的方式(看情况决定,为了自己方便)。

详细说下第二种情况

接口设计注意事项:

1.避免过度封装,过度封装会导致调bug很难理清楚逻辑,而且很不好维护

2.接口名称,通常使用驼峰规则就行,做到见名思意

3.参数尽量提炼,不要搞一堆没必要的参数,用起来很麻烦。无非必要,就不要

4.注释清晰,明了。不写注释是王八

接口设计的最佳效果

1.隔离用户操作与底层逻辑

(说人话,无非就是我给你这个接口就可以让你实现这个功能,不需要你去了解里面怎么玩的,想那么多干嘛,那是我封住接口的人需要考虑的塞)

接口封装的两种方法

1.PIMP(Pointer to Implementation)在接口类成员中包含一个指向实现类的指针,这样就可以最大限度的做到接口和实现进行分离的原则。

说白了,就是A实现了某种方法(类A不对外使用),而在A-inerface中声明一个A *pA,并且这套接口的方法内部就是调用了A的方法,有时候可能会做一些扩展,比如一个基础事件的集合,也就是有很多这样的事件

示例:

class A_interface

{

public:

       A_interface& operator+(const A_interface& com );

       A_interface& operator-(const A_interface& com );

       A_interface& operator*(const A_interface& com );

       A_interface& operator/(const A_interface& com );

private:

       A *p_A;

}

class A{

public:

       A& operator+(const A& com );

       A& operator-(const A& com );

       A& operator*(const A& com );

       A& operator/(const A& com );

private:

       double real_;

       double imaginary_;

};

===> 不可多说,这个方法反正我基本不用塞,自己体会塞

2.Object-Interface方法,采用c++继承多态,实现类继承接口类,功能接口定义成虚函数。

这个纯虚函数给你朋友用,其他部分搞成.so或者.dll (.lib\.a)

如果不满足塞,再来个管理类。说白了就一个工厂类塞,如果你觉得好玩,可以搞个反射塞。

//纯虚函数,接口成员函数

class Complex{

public:

   static std::unique_ptr<Complex> Create();    // 用来做工厂方法    

   virtual Complex& operator+(const Complex& com ) = 0;

   virtual Complex& operator-(const Complex& com )  = 0;

   virtual Complex& operator*(const Complex& com )  = 0;

   virtual Complex& operator/(const Complex& com )  = 0;

};

//Complex类功能的内部实现类

class ComplexImpl : public Complex{

public:

   virtual Complex& operator+(const Complex& com ) override;

   virtual Complex& operator-(const Complex& com ) override;

   virtual Complex& operator*(const Complex& com ) override;

   virtual Complex& operator/(const Complex& com ) override;

private:

   double real_;

   double imaginary_;

}

>>>将要暴露出去的接口都设置为纯虚函数,然后通过工厂模式Create获取不同基类的指针

std::unique_ptr<Complex> Complex::Create()

{

   return std::make_unique<ComplexImpl>();

}

>>>如此,我们完成将Complex类的实现细节全部封装隐藏起来了

>>>如果对于用户来说,是有必要获取实体的数据部分时,只需要添加响应的set和get方法

Object_interface抽象基类示例代码:

1.首先,声明一个接口 ---> 一般设置为纯虚函数

// circle.h

// 圆的接口类

class Circle {

public:

  virtual ~Circle() {};

  virtual double area() = 0;     // 接口方法:面积

};

2.通过继承的方式实现这个接口

// circle_impl.h

#include "circle.h"

 

// 圆的具体实现类

class CircleImpl : public Circle {

private:

   double radius;

public:

   CircleImpl(double radius);

   double area() override;

};

// circle_impl.cpp

#include <cmath>

#include "circle_impl.h"

 

inline double pi() {

   return std::atan(1) * 4;

};

 

CircleImpl::CircleImpl(double _radius) : radius(_radius) {

};

 

double CircleImpl::area() {

   return pi() * radius * radius;

};

3.最后,通过管理类创建接口派生类的实例,或者销毁接口派生类的实例

// circle_manager.h

#include "circle.h"

 

// 圆的创建工厂类

class CircleManager {

public:

   static Circle* create(double radius);     // 创建circle实例

   static void destroy(Circle* circlePtr);   // 销毁circle实例

};

// circle_manager.cpp

#include "circle_manager.h"

#include "circle_impl.h"

 

Circle* CircleManager::create(double radius) {

   Circle* circlePtr = new CircleImpl(radius);

 

   return circlePtr;

};

 

void CircleManager::destroy(Circle* circlePtr) {

   delete circlePtr;

};

// 使用示例

// main.cpp

#include <iostream>

#include "circle_manager.h"

#include "circle.h"

 

int main()

{

   Circle* circlePtr = CircleManager::create(3);

   cout << circlePtr->area() <<endl;

   CircleManager::destroy(circlePtr);

   

   system("pause");

 

   return 0;

}

 

相关文章
|
消息中间件 关系型数据库 MySQL
Flink SQL Client实战CDC数据入湖
本文介绍Flink SQL Client实现CDC数据入湖
Flink SQL Client实战CDC数据入湖
|
消息中间件 缓存 监控
GitHub上获赞上万的阿里亿级并发系统设计手册,让你吊打面试官
金九银十已经接近尾声,很多没有在这个时间段找到工作的小伙伴已经开始备战秋招了,在这里给大家分享一份阿里10亿级并发系统设计手册,专门给没有系统设计相关经验的小伙伴应对面试用的,下面将这么手册的内容以截图的形式展示给大家,有需要的小伙伴可以文末获取↓↓↓此份手册又份为六个部分,基础篇、数据库篇、缓存篇、消息队列篇、分布式服务篇、维护篇、实战篇共计328页 目录总览 基础篇 高并发代表着大流量,高并发系统设计的魅力就在于我们能够凭借自己的聪明才智设计巧妙的方案,从而抵抗巨大流量的冲击,带给用户更好的使用体验。这些方案好似能操纵流量,让流量更加平稳得被系统中的服务和组件处理。
GitHub上获赞上万的阿里亿级并发系统设计手册,让你吊打面试官
|
安全 Java Android开发
安卓开发中的新趋势:Kotlin与Jetpack的完美结合
【6月更文挑战第20天】在不断进化的移动应用开发领域,Android平台以其开放性和灵活性赢得了全球开发者的青睐。然而,随着技术的迭代,传统Java语言在Android开发中逐渐显露出局限性。Kotlin,一种现代的静态类型编程语言,以其简洁、安全和高效的特性成为了Android开发中的新宠。同时,Jetpack作为一套支持库、工具和指南,旨在帮助开发者更快地打造优秀的Android应用。本文将探讨Kotlin与Jetpack如何共同推动Android开发进入一个新的时代,以及这对开发者意味着什么。
208 5
|
关系型数据库 数据库 数据安全/隐私保护
使用 Docker 搭建属于自己的个人相册,让美好不会丢失!
使用 Docker 搭建属于自己的个人相册,让美好不会丢失!
|
分布式计算 Hadoop Shell
|
9月前
|
关系型数据库 MySQL
图解MySQL【日志】——磁盘 I/O 次数过高时优化的办法
当 MySQL 磁盘 I/O 次数过高时,可通过调整参数优化。控制刷盘时机以降低频率:组提交参数 `binlog_group_commit_sync_delay` 和 `binlog_group_commit_sync_no_delay_count` 调整等待时间和事务数量;`sync_binlog=N` 设置 write 和 fsync 频率,`innodb_flush_log_at_trx_commit=2` 使提交时只写入 Redo Log 文件,由 OS 择机持久化,但两者在 OS 崩溃时有丢失数据风险。
230 3
|
存储 运维
使用Visual Studio分析.NET Dump
使用Visual Studio分析.NET Dump
242 0
|
计算机视觉 索引
【OpenCV】直方图计算 & 均衡化直方图
【OpenCV】直方图计算 & 均衡化直方图
531 3
|
数据可视化 测试技术 Linux
基于Python后端构建多种不同的系统终端界面研究
【10月更文挑战第10天】本研究探讨了利用 Python 后端技术构建多样化系统终端界面的方法,涵盖命令行界面(CLI)、图形用户界面(GUI)及 Web 界面。通过分析各种界面的特点、适用场景及关键技术,展示了如何使用 Python 标准库和第三方库(如 `argparse`、`click`、`Tkinter` 和 `PyQt`)实现高效、灵活的界面设计。旨在提升用户体验并满足不同应用场景的需求。
210 1
|
传感器 数据采集 安全
物联网的五层架构分析
物联网五层架构,包括感知层、网络层、数据层、应用层和业务层,扮演着关键的角色。
3077 2