苛评VCL: 失望的TMenu

TMenu是什么？他是VCL中封装的TMainMenu和TPopupMenu的基类。与其说对TMenu失望，其实是对VCL中对TMainMenu和TPopupMenu的失望。

为什么呢？这基本上还得归咎于微软自己。微软在推出Windows的同时，却坚决的在推Office系列产品。而且Office的更新速度和Windows几乎一样快。更重要的是，Office系列产品的界面风格，特别是菜单，和标准Windows的完全不同。

当微软的Office推广地非常好的时候，我们都在渴望也能设计出一样的界面。对于只是外表改变的需求来讲，很自然地可以考虑重新覆盖TMenuItem的Draw方法。

可是，当你真的想这么干的时候，你会发现两件事，一件让你高兴，一件让你失望。先说高兴的事吧：

负责Draw工作的两个方法：AdvancedDrawItem和MeasureItem都是声明的Virtual类型的函数。也就是说，我们完全可以通过覆盖这些方法的方式去实现。而且，显然的，TMenuItem的设计者，显然已经考虑到这样的扩展了。

而且，通过观察AdvancedDrawItem的实现，你更可以发现你需要修改的代码点。

if(ParentMenu<>nil)and(ParentMenu.OwnerDrawor(ImageList<>nil))and
(Assigned(FOnAdvancedDrawItem)orAssigned(FOnDrawItem))then
begin
DrawItem(ACanvas,ARect,Selected);
ifAssigned(FOnAdvancedDrawItem)then
FOnAdvancedDrawItem(Self,ACanvas,ARect,State);
endelse
if(ParentMenu<>nil)and(notParentMenu.IsRightToLeft)then
NormalDraw
else
BiDiDraw;

请注意看NormalDraw和BiDiDraw。那么我们的OfficeDraw只要并列选择就可以了。当然了，如果要完全放弃原来的画法，那就更容易了。

遗憾的是，我们必须听另一个让人失望的事。那就是，Menus单元中，所有创建TMenuItem的地方，都是直接调用TMenuItem.Create的方式。如果你想派生一个TOfficeMenuItem类，你无法找到能创建你的类的地方。

这种情况，一般的设计就是，在TMenu类中有一个虚拟方法，返回一个类型为TMenuItem的实例。至于用哪个具体的类型，可以有TMenu的派生类来决定。比如，你自定一个TOfficeMenu，当创建TMenuItem的实例的时候，使用TOfficeMenuItem创建。简单一点就是下面的代码：

function CreateMenuItem: TMenuItem; override;

而实现的时候，简单用下面的代码实现：

Result := TOfficeMenuItem.Create;

每当我不得不面对这个现实的时候，我就开始考虑是不是有办法绕过去。有一种办法，是实现TMenuItem的OnDrawItem事件。还有一种办法，就是直接使用HOOK的方式替换TMenuItem类。

我能想到的上面两个方法，都只算是在特定应用中解决问题的办法。作为热衷组件化设计的我来讲，显然更愿意自己实现一个TOfficeMenu和TOfficeMenuItem。并且不是仅仅通过修改事件，而是完全通过面向对象的多态性来完成这个功能。

失望TMenu是因为其扩展性方面的欠考虑，因为此，导致VCL中默认就代用两种方式。而第三方蓬勃发展的如TBX系列和Raze系列界面控件，也都证明了其设计方面的欠缺。

其实我们也可正好可以思考一下，设计，应该考虑好开闭原则。特别是“对未来的派生是开放的”这一点。怎么样的设计都可以完成目前的功能。可是能不能考虑到以后的扩展，那就是设计的好坏了。