浅谈C++开发中数据结构和算法的分离

开发 后端 算法
本文介绍的是在C++开发中,数据结构和算法的分离,希望对你有帮助,一起来看。

相信每一个在windows下编过程序的人都或多或少地用过位图,大多数人是从网上下载一些成熟完善的DIB类库来使用(例如CxImage、CDIB),少数人有一套自己封装好的DIB类库,方便以后的扩充和使用。(近几年GDI+异军突起,在某些处理方面,如:缩放、旋转、渐变填充等它提供无与伦比的速度和质量,但,如果你想做一个完善的图像处理程序,直接使用它会给架构设计带来困难,你可以用adapter模式封装它后再使用)。

这时候,如果你需要一些图像处理操作你会怎么办呢?很多没有OO经验的C++程序员(例如一年前的我)可能会这样做:在类中直接添加方法。

  1. int FClamp0255 (int nValue) {return max (0, min (0xFF, nValue));} // 饱和到0--255  
  2. class FCObjImage  
  3. {  
  4.  public :  
  5. Invert () ;  
  6. AdjustRGB (int R, int G, int B) ;  
  7. } ;  
  8. void FCObjImage::Invert ()  
  9. {  
  10.  if ((GetHandle() == NULL) || (ColorBits() < 24))  
  11. return ;  
  12.  int nSpan = ColorBits() / 8 ; // 每象素字节数3, 4  
  13.  for (int y=0 ; y < Height() ; y++)  
  14.  {  
  15. BYTE * pPixel = GetBits (y) ;  
  16. for (int x=0 ; x < Width() ; x++, pPixel += nSpan)  
  17. {  
  18.  pPixel[0] = ~pPixel[0] ;  
  19.  pPixel[1] = ~pPixel[1] ;  
  20.  pPixel[2] = ~pPixel[2] ;  
  21. }  
  22.  }  
  23. }  
  24. void FCObjImage::AdjustRGB (int R, int G, int B)  
  25. {  
  26.  if ((GetHandle() == NULL) || (ColorBits() < 24))  
  27. return ;  
  28.  int nSpan = ColorBits() / 8 ; // 每象素字节数3, 4  
  29.  for (int y=0 ; y < Height() ; y++)  
  30.  {  
  31. BYTE * pPixel = GetBits (y) ;  
  32. for (int x=0 ; x < Width() ; x++, pPixel += nSpan)  
  33. {  
  34.  pPixel[0] = FClamp0255 (pPixel[0] + B) ;  
  35.  pPixel[1] = FClamp0255 (pPixel[1] + G) ;  
  36.  pPixel[2] = FClamp0255 (pPixel[2] + R) ;  
  37. }  
  38. }  
  39. }  

这里举了两个例子(分别实现反色,调节RGB值功能),现实中会有大量的此类操作:亮度、对比度、饱和度......现在回想一下,你添加这些方法的步骤是什么,Ooooooooo,RCP(我同事的发明,全称:rapid copy paste^-^),第一步一定是从上面复制一块代码下来,然后改掉其中的接口和处理部分。虽然这里的示范代码很短小,不会连同bug一起复制,但,定时炸弹却又多了一个。有天,你的boss告诉你:我不能忍受长时间的等待,请给我加个进度条.....。你也许会加个全局变量,也许会给每个函数加个参数,但不变的是:你必须修改所有这些处理函数的代码,内心的咒骂并不会使你少改其中的任何一个。而此时,bug已经在旁边伺机而动了...然而苦日子远没熬到头,一个月后,你心血来潮的老板会让你在其中加上区域处理的功能,再一个月后......

回头重新看看代码?没错,除了红色的代码外,其他地方一摸一样,那能不能把这些算法分离抽出来呢?可能我们马上会想到标准库中qsort和windows中常用的回调方法。好,让我们实作一下:

  1. void Pixel_Invert (BYTE * pPixel)  
  2. {  
  3.  pPixel[0] = ~pPixel[0] ;  
  4.  pPixel[1] = ~pPixel[1] ;  
  5.  pPixel[2] = ~pPixel[2] ;  
  6. }  
  7. void FCObjImage::PixelProcess (void(__cdecl*PixelProc)(BYTE * pPixel))  
  8. {  
  9.  if ((GetHandle() == NULL) || (ColorBits() < 24))  
  10. return ;  
  11.  int nSpan = ColorBits() / 8 ; // 每象素字节数3, 4  
  12.  for (int y=0 ; y < Height() ; y++)  
  13.  {  
  14. BYTE * pPixel = GetBits (y) ;  
  15. for (int x=0 ; x < Width() ; x++, pPixel += nSpan)  
  16. {  
  17.  PixelProc (pPixel) ;  
  18. }  
  19.  }  
  20. }  
  21. void FCObjImage::Invert ()  
  22. {  
  23.  PixelProcess (Pixel_Invert) ;   

嗯,看样子不错,算法被剥离到一个单一函数中,我们似乎已经解决问题了。处理Invert它完成的非常好,但处理AdjustRGB时遇到了麻烦,RGB那三个调节参数怎么传进去呢?我们的接口参数只有一个,通过添加全局变量/成员变量?这是一个办法,但随着类方法的增加,程序的可读性和维护性会急剧的下降,反而倒不如改之前的效果好。

那么如何实现高度的抽象和良好的接口呢?我们现场请来OO(object orient),请它来讲一下它的实现。设计如下派生关系:

  1. class FCSinglePixelProcessBase  
  2. {  
  3.  public :  
  4. virtual void ProcessPixel (int x, int y, BYTE * pPixel) PURE ;  
  5. } ;  
  6. class FCPixelInvert : public FCSinglePixelProcessBase  
  7. {  
  8.  public :  
  9. virtual void ProcessPixel (int x, int y, BYTE * pPixel) ;  
  10. } ;   
  11. void FCPixelInvert::ProcessPixel (int x, int y, BYTE * pPixel)  
  12. {  
  13.  pPixel[0] = ~pPixel[0] ; pPixel[1] = ~pPixel[1] ; pPixel[2] = ~pPixel[2] ;  
  14. }   
  15. class FCPixelAdjustRGB : public FCSinglePixelProcessBase  
  16. {  
  17.  public :  
  18. FCPixelAdjustRGB (int DeltaR, int DeltaG, int DeltaB) ;  
  19. virtual void ProcessPixel (int x, int y, BYTE * pPixel) ;  
  20.  protected :  
  21. int m_iDeltaR, m_iDeltaG, m_iDeltaB ;  
  22. } ;   
  23. void FCPixelAdjustRGB::ProcessPixel (int x, int y, BYTE * pPixel)  
  24. {  
  25.  pPixel[0] = FClamp0255 (pPixel[0] + m_iDeltaB) ;  
  26.  pPixel[1] = FClamp0255 (pPixel[1] + m_iDeltaG) ;  
  27.  pPixel[2] = FClamp0255 (pPixel[2] + m_iDeltaR) ;  
  28. }  

然后我们修改image类如下:

  1. #include "PixelProcessor.h"  
  2. class FCObjImage  
  3. {  
  4.  public :  
  5. void PixelHandler (FCSinglePixelProcessBase & PixelProcessor, FCObjProgress * progress = NULL) ;  
  6. } ;  
  7. void FCObjImage::PixelHandler (FCSinglePixelProcessBase & PixelProcessor, FCObjProgress * progress)  
  8. {  
  9.  if (GetHandle() == NULL)  
  10. return ;  
  11.  int nSpan = ColorBits() / 8 ; // 每象素字节数3, 4  
  12.  for (int y=0 ; y < Height() ; y++)  
  13.  {  
  14. BYTE * pPixel = GetBits (y) ;  
  15. for (int x=0 ; x < Width() ; x++, pPixel += nSpan)  
  16. {  
  17.  PixelProcessor.ProcessPixel (x, y, pPixel) ;  
  18. }  
  19. if (progress != NULL)  
  20.  progress->SetProgress (y * 100 / Height()) ;  
  21.  }  
  22. }  
  23. void FCObjImage::Invert (FCObjProgress * progress)  
  24. {  
  25.  PixelHandler (FCPixelInvert(), progress) ;  
  26. }   
  27. void FCObjImage::AdjustRGB (int R, int G, int B, FCObjProgress * progress)  
  28. {  
  29.  PixelHandler (FCPixelAdjustRGB (R,G,B), progress) ;  

(以上只是一个基本框架,你可以很轻易的把区域处理的参数添加进去-通过构造时传递一个RECT参数。)

对象真的是一个很奇妙的东西,它可以对外提供一个简单的接口,而自身又可以封装上很多附加信息。

好,现在让我们来检验一下刚才的成果:添加一个给图像奇数行置黑,给偶数行置白的操作。

  1. class FCPixelTest : public FCSinglePixelProcessBase  
  2. {  
  3.  public :  
  4. virtual void ProcessPixel (int x, int y, BYTE * pPixel) ;  
  5. } ;   
  6. void FCPixelTest::ProcessPixel (int x, int y, BYTE * pPixel)  
  7. {  
  8.  if (y % 2) pPixel[0]=pPixel[1]=pPixel[2] = 0 ;   
  9.  // 奇数行   
  10.  else   
  11. pPixel[0]=pPixel[1]=pPixel[2] = 0xFF ;   
  12. // 偶数行  

然后进行如下调用:

  1. PixelHandler (FCPixelTest(), progress) ; 

多么的和谐美妙,设计算法的人员只需写出自己的算法,而不用去考虑怎么让它支持进度条和区域这些问题。感觉这就象一把设计优良的AK,你可以不断的往里添加子弹(对象)^-^

至此,我们应该已经大功告成了。还有问题吗?

等等,别忙,有些地方不太对,我添加这个算法后,怎么编译这么久啊。

问题就出在那个不起眼的:

  1. #include "PixelProcessor.h" 

image是图像处理的最底层对象,工程中的所有文件都直接或间接地包含它,因此,任何对image.h本身及它所包含的.h的修改都会引起几乎整个工程的build,这当然是无法忍受的,解决的办法是使用“前置声明”,因为在PixelHandler接口中我们只需要它的引用(也即是说:我(接口)并不需要知道传给我的类的内部结构,给我一个32(64)的内存地址就OK了)。

因此我们把

  1. #include "PixelProcessor.h" 

替换成:

  1. class FCSinglePixelProcessBase ; // external class 前置声明 

然后在.cpp文件中再包含PixelProcessor.h,这样,对PixelProcessor.h的改变仅仅会导致.cpp文件的重新编译,大大节约了编译时间。

总结:

1)可能的话,在编程中永远也别去想“拷贝代码”这个字眼。毕竟,OO就是为了抽象和代码重用才诞生的。

2)除非必要,否则类的成员变量和函数的参数尽量用指针或引用代替,这样做可以在.h中尽可能地少包含其他.h文件,而用前置声明来替代,以此来减少编译时间和以后可能会产生的交叉包含。

3)最后说一下效率问题:有些朋友可能会说每个像素都调用虚函数会影响性能,这的确,但实际的损失远没有想象的大。我实测了一下:对1024*768的图片进行反片处理,速度只有5%左右的损失,进行复杂处理(亮度/对比度/gamma)时损失可完全忽略,毕竟多出来的那部分代码只是进出栈和查表,而不是浮点除这样耗时的指令。

责任编辑:于铁 来源: 互联网
相关推荐

2009-08-13 18:34:49

C#数据结构和算法

2009-06-24 09:52:21

哈希表

2009-08-03 17:38:12

排序算法C#数据结构

2023-10-16 22:13:57

HBase开源数据库

2023-12-13 10:01:15

数据结构c++编程

2010-01-27 15:58:35

C++数据结构

2011-04-11 11:23:17

队列数据结构

2012-02-02 10:21:05

单链表nexthead

2022-02-22 15:27:46

数据结构容器算法

2020-08-12 08:30:20

数据结构算法

2021-06-08 06:01:00

C++数据结构向量和数组

2011-04-21 17:32:15

CC++

2019-04-14 22:22:28

Python数据结构算法

2021-01-28 07:33:34

JavaScript链表数据

2011-04-11 12:22:11

数据结构C++

2011-04-11 12:48:36

队列数据结构C++

2024-01-15 06:01:36

C++数组

2021-06-08 10:41:00

Go语言算法

2011-04-11 13:00:08

C++结构体枚举

2011-04-21 16:57:56

staticextern
点赞
收藏

51CTO技术栈公众号