CSDN博客

img cphj

非议MFC(二)逻辑上的不完备

发表于2003/2/18 8:49:00  1029人阅读

                          非议MFC(二)逻辑上的不完备

关键字:C++,MFC,RECT,CRect,POINT,CPoint,逻辑

说明:程序片断仅包括理解所必需的代码,其余省略。

1.设计缺失
file://in <WINDEF.H>
typedef struct tagRECT
{
      LONG left;
      LONG top;
      LONG right;
      LONG bottom;
} RECT, *PRECT, NEAR *NPRECT, FAR *LPRECT;
file://in <AFXWIN.H>
class CRect : public tagRECT
{
      void SwapLeftRight();                  file://[1]

      BOOL IsRectEmpty() const;
      BOOL IsRectNull() const;
      void SetRectEmpty();                  file://[2]

      CRect(int l, int t, int r, int b);
      CRect(POINT topLeft, POINT bottomRight);
      CRect(POINT point, SIZE size);            file://[3]
      void SetRect(int x1, int y1, int x2, int y2);
      void SetRect(POINT topLeft, POINT bottomRight);
};
[1]为什么有SwapLeftRight(),却不提供对应的SwapTopBottom()?
[2]同理,为什么不提供SetRectNull()呢?
[3]既然三种方法都可以构造CRect对象,期望SetRect(POINT point, SIZE size)不是很合理吗?
补上这些缺失的函数不过是举手之劳,“不因善小而不为”这句话不应该只挂在嘴上!

2.前后不一致
file://in <AFXWIN.H>
class CPoint : public tagPOINT
{
      CRect operator+(const RECT* lpRect) const;      file://[1]
};
typedef const RECT* LPCRECT;
class CRect : public tagRECT
{
      CRect operator+(LPCRECT lpRect) const;            file://[2]

      void operator+=(LPCRECT lpRect);            file://[3]
      void operator&=(const RECT& rect);            file://[4]
};
由于LPCRECT的类型定义放在中间,[1][2]的形参采取了形式不同但意义相同的声明方式。
[3][4]是相似的运算符重载,却使用了不同的形参传递方式。
每个人可以有自己的代码风格,但在同一个文件中,或者至少在同一个类中,总应该使用统一的风格吧!

3.妨碍语法完整性
file://in <AFXWIN.H>
class CRect : public tagRECT
{
      void operator=(const RECT& srcRect);
};
众所周知,在C和C++中,任何一个表达式的本身都是有值的,例如:a=100就是一个表达式,它的值是100。有了这个逻辑前提,链式表达式才能合理存在。在b=a=100;中,准确地说,是把a=100这个表达式的值100赋值给b。
而CRect类中,赋值运算符的返回类型被错误地设定成void,于是CRect对象之间的赋值表达式没有了值,链式表达式也失效了。
这个运算符的正确返回类型应该是CRect &。
难道MFC的开发人员不看《Effective C++》?

4.数学运算的对称破缺
file://in <WINDEF.H>
typedef struct tagPOINT
{
    LONG x;
    LONG y;
} POINT, *PPOINT, NEAR *NPPOINT, FAR *LPPOINT;
file://in <AFXWIN.H>
class CPoint : public tagPOINT
{
      CPoint operator+(POINT point) const;
};
给出如下测试代码:
POINT pt;
CPoint pnt;
CPoint result;
result=pnt+pnt;            file://ok
result=pt+pt;            file://error
result=pnt+pt;            file://ok
result=pt+pnt;            file://error
pnt+pnt自然没问题,pt+pt报错也勉强可以理解,但是pnt+pt可以,pt+pnt偏偏就不行。直觉上,加法应该满足交换率,但是MFC“一鸣惊人”地打破了我们的思维惯性。
实际上,如果把运算符函数声明为:
      friend const CPoint operator+(const POINT & pntL,const POINT & pntR);
前述的四个语句就都可以通过了。
也许有人会说:“friend关键字是非面向对象的,最好不要使用。”那么,我要说:首先,C++不是Java,它的主要设计原则是满足大型系统的效率、弹性和可维护性,面向对象中好的方法要采纳,非面向对象中好的方法也要采纳。其次,MFC在其他地方就使用了friend。
如果认为pnt和pt之间不允许相加,那也应该把运算符函数声明为更安全的形式:
      const CPoint operator+(const CPoint & pntR) const;
这样就只允许pnt和pnt相加了。
要行都行,要不行都不行,不要歧视!


请参考下一篇《非议MFC(三)库代码的质量问题》

0 0

相关博文

我的热门文章

img
取 消
img