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

非议MFC（二）逻辑上的不完备 (转)[@more@]

  非议MFC（二）逻辑上的不完备

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

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

1.设计缺失
file://in
typedef struct tagRECT
{
  LONG left;
  LONG top;
  LONG right;
  LONG bottom;
} RECT, *PRECT, NEAR *NPRECT, FAR *LPRECT;
file://in
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
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
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
typedef struct tagPOINT
{
  LONG x;
  LONG y;
} POINT, *PPOINT, NEAR *NPPOINT, FAR *LPPOINT;
file://in
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（三）库代码的质量问题》

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/10752043/viewspace-993251/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/10752043/viewspace-993251/