OOP与宏问题 [英] OOP vs macro problem

问题描述

我今天通过一个同事遇到了这个问题。他有一个像这样的前端系统的设计：

I came across this problem via a colleague today. He had a design for a front end system which goes like this:

class LWindow
{
   //Interface for common methods to Windows
};

class LListBox : public LWindow
{
   //Do not override methods in LWindow.
   //Interface for List specific stuff
}

class LComboBox : public LWindow{} //So on

Window系统应该在多个平台上工作。假设我们目标为Windows和Linux。对于Windows，我们有一个在 LWindow 中的接口的实现。我们有多个实现所有 LListBox es， LComboBox es，等我的反应是传递一个 LWindow * （实现对象）到 LWindow 类，所以它可以这样做：

The Window system should work on multiple platforms. Suppose for the moment we target Windows and Linux. For Windows we have an implementation for the interface in LWindow. And we have multiple implementations for all the LListBoxes, LComboBoxes, etc. My reaction was to pass an LWindow*(Implementation object) to the base LWindow class so it can do this:

void LWindow::Move(int x, int y)
{
   p_Impl->Move(x, y);   //Impl is an LWindow*
}

LListBox 等等

最初给出的解决方案有很大不同。它归结为：

The solution originally given was much different. It boiled down to this:

#define WindowsCommonImpl {//Set of overrides for LWindow methods}

class WinListBox : public LListBox
{
    WindowsCommonImpl     //The overrides for methods in LWindow will get pasted here.
    //LListBox overrides
}

//So on

$ b b

现在，读了所有关于宏的恶意和好的设计实践，我立即反对这个方案。毕竟，它是伪装的代码重复。但我不能说服我的同事。我很惊讶，这是这样的情况。所以，我向你提出这个问题。后一种方法的可能的问题是什么？我想要实际的答案。我需要说服一个非常实用的人（和习惯做这种东西，他提到有很多宏在MFC！）这是坏的（和我自己）。不教他美学。此外，我提出的问题有什么问题吗？如果是这样，我该如何改进呢？谢谢。

Now, having read all about macros being evil and good design practices, I immediately was against this scheme. After all, it is code duplication in disguise. But I couldn't convince my colleague of that. And I was surprised that that was the case. So, I pose this question to you. What are the possible problems of the latter method? I'd like practical answers please. I need to convince someone who is very practical (and used to doing this sort of stuff. He mentioned that there's lots of macros in MFC!) that this is bad (and myself). Not teach him aesthetics. Further, is there anything wrong with what I proposed? If so, how do I improve it? Thanks.

编辑：请给我一些理由，以便我能感觉良好支持oop：（

Please give me some reasons so I can feel good about myself supporting oop :(

请问是否需要任何澄清，我想知道参数和vs OOP对宏：）

Going for bounty. Please ask if you need any clarifications. I want to know arguments for and vs OOP against the macro :)

推荐答案

你的同事可能在想MFC消息映射宏;这些在每个MFC派生类的重要的地方使用，所以我可以看到你的同事从哪里来。但是这些不是用于实现接口，而是用于与其他Windows操作系统交互的细节。

Your colleague is probably thinking of the MFC message map macros; these are used in important-looking places in every MFC derived class, so I can see where your colleague is coming from. However these are not for implementing interfaces, but rather for details with interacting with the rest of the Windows OS.

具体来说，这些宏实现了Windows消息泵系统的一部分，其中表示对MFC类做出请求的消息被定向到正确的处理函数到处理程序的消息）。如果你有权访问visual studio，你会看到这些宏将消息映射条目包装在一个有点复杂的结构数组（调用操作系统代码知道如何读取），并提供访问此映射的函数。

Specifically, these macros implement part of Windows' message pump system, where "messages" representing requests for MFC classes to do stuff gets directed to the correct handler functions (e.g. mapping the messages to the handlers). If you have access to visual studio, you'll see that these macros wrap the message map entries in a somewhat-complicated array of structs (that the calling OS code knows how to read), and provide functions to access this map.

作为MFC用户，宏系统使我们看起来很干净。但这主要是因为底层的Windows API是明确指定的，并且不会改变太多，并且大多数宏代码是由IDE生成的，以避免打印错误。如果你需要实现涉及到杂乱的声明，那么宏可能是有意义的，但到目前为止似乎并不是这样。

As MFC users, the macro system makes this look clean to us. But this works mostly because underlying Windows API is well-specified and won't change much, and most of the macro code is generated by the IDE to avoid typos. If you need to implement something that involves messy declarations then macros might make sense, but so far this doesn't seem to be the case.

实际的问题，你的同事可能感兴趣的是：

Practical concerns that your colleague may be interested in:

• 重复的宏调用。看起来你需要将行WindowsCommonImpl复制到每个类声明 - 假设宏扩展到一些内联函数。如果他们只是声明和实现在一个单独的宏，你需要在每个.cpp文件中这样做 - 并更改每次传递到宏的类名。


• 更长的重新编译时间。对于你的解决方案，如果你改变一些在LWindow实现，你可能只需要重新编译LWindow.cpp。如果您更改宏中的某些内容，则包含宏头文件的所有内容都需要重新编译，这可能是您的整个项目。


• 更难调试。如果错误与宏内的逻辑有关，调试器可能会断开到调用者，在那里你不会立即看到错误。你甚至可能不想检查宏定义，因为你以为你知道它是做什么的。

所以基本上你的LWindow解决方案是一个更好的解决方案，以尽量减少头痛的路。

So basically your LWindow solution is a better solution, to minimize headaches down the road.

这篇关于OOP与宏问题的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！