苛评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.OwnerDraw or (ImageList <> nil)) and
(Assigned(FOnAdvancedDrawItem) or Assigned(FOnDrawItem)) then
begin
DrawItem(ACanvas, ARect, Selected);
if Assigned(FOnAdvancedDrawItem) then
FOnAdvancedDrawItem(Self, ACanvas, ARect, State);
end else
if (ParentMenu <> nil) and (not ParentMenu.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系列界面控件,也都证明了其设计方面的欠缺。
其实我们也可正好可以思考一下,设计,应该考虑好开闭原则。特别是“对未来的派生是开放的”这一点。怎么样的设计都可以完成目前的功能。可是能不能考虑到以后的扩展,那就是设计的好坏了。