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

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*
}

And, do the same thing for implementation of LListBox and so on

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

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.

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

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

回答1:

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.

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.

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:

• duplicated macro calls. Looks like you're going to need to copy the line "WindowsCommonImpl" into each class declaration - assuming the macro expands to some inline functions. If they're only declarations and the implementations go in a separate macro, you'll need to do this in every .cpp file too - and change the class name passed into the macro every time.
• longer recompile time. For your solution, if you change something in the LWindow implementation, you probably only need to recompile LWindow.cpp. If you change something in the macro, everything that includes the macro header file needs to be recompiled, which is probably your whole project.
• harder to debug. If the error has to do with the logic within the macro, the debugger will probably break to the caller, where you don't see the error right away. You may not even think to check the macro definition because you thought you knew exactly what it did.

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

回答2:

Does'nt answer your question directly may be, but can't help from telling you to Read up on the Bridge Design pattern in GOF. It's meant exactly for that.

Decouple an abstraction from its implementation so that the two can vary independently.

From what I can understand, you are already on the right path, other than the MACRO stuff.

My reaction was to pass an LWindow*(Implementation object) to the base LWindow class so it can do this:

回答3:

LListBox and LComboBox should receive an instance of WindowsCommonImpl.

In the first solution, inheritance is used so that LListBox and LComboBox can use some common methods. However, inheritance is not meant for this.

回答4:

I would agree with you. Solution with WindowsCommonImpl macro is really bad. It is error-prone, hard to extend and very hard to debug. MFC is a good example of how you should not design your windows library. If it looks like MFC, you are really on a wrong way.

So, your solution obviously better than macro-based one. Anyway, I wouldn't agree it is good enough. The most significant drawback to me is that you mix interface and implementation. Most practical value of separating interface and implementation is ability to easily write mock objects for testing purposes.

Anyway, it seems the problem you are trying to solve is how to combine interface inheritance with implementation inheritance in C++. I would suggest using template class for window implementation.

// Window interface
class LWindow
{
};

// ListBox interface (inherits Window interface)
class LListBox : public LWindow
{
};    

// Window implementation template
template<class Interface>
class WindowImpl : public Interface
{
};

// Window implementation
typedef WindowImpl<LWindow> Window;

// ListBox implementation
// (inherits both Window implementation and Window interface)
class ListBox : public WindowImpl<LListBox>
{
};

As I remember WTL windows library is based on the similar pattern of combining interfaces and implementations. I hope it helps.

回答5:

Oh man this is confusing.

OK, so L*** is a hierarchy of interfaces, that's fine. Now what are you using the p_Impl for, if you have an interface, why would you include implementation in it?

The macro stuff is of course ugly, plus it's usually impossible to do. The whole point is that you will have different implementations, if you don't, then why create several classes in the first place?

回答6:

OP seems confused. Here' what to do, it is very complex but it works.

Rule 1: Design the abstractions. If you have an "is-A" relation you must use public virtual inheritance.

struct Window { .. };
struct ListBox : virtual Window { .. };

Rule 2: Make implementations, if you're implementing an abstraction you must use virtual inheritance. You are free to use inheritance to save on duplication.

class WindowImpl : virtual Window { .. };
class BasicListBoxImpl : virtual ListBox, public WindowImpl { .. };
class FancyListBoxImpl : public BasicListBoxImpl { };

Therefore you should read "virtual" to mean "isa" and other inheritance is just saving on rewriting methods.

Rule3: Try to make sure there is only one useful function in a concrete type: the constructor. This is sometimes hard, you may need some default and some set methods to fiddle things. Once the object is set up cast away the implementation. Ideally you'd do this on construction:

ListBox *p = new FancyListBoxImpl (.....);

Notes: you are not going to call any abstract methods directly on or in an implementation so private inheritance of abstract base is just fine. Your task is exclusively to define these methods, not to use them: that's for the clients of the abstractions only. Implementations of virtual methods from the bases also might just as well be private for the same reason. Inheritance for reuse will probably be public since you might want to use these methods in the derived class or from outside of it after construction to configure your object before casting away the implementation details.

Rule 4: There is a standard implementation for many abstractions, known as delegation which is one you were talking about:

struct Abstract { virtual void method()=0; };

struct AbstractImpl_Delegate: virtual Abstract { 
  Abstract *p;
  AbstractImpl_Delegate (Abstract *q) : p(q) {}
  void method () { p->method(); }
};

This is a cute implementation since it doesn't require you to know anything about the abstraction or how to implement it... :)

回答7:

I found that

Using the preprocessor #define directive to define constants is not as precise.

[src]

Macros are apparently not as precise, I did not even know that... The classic hidden dangers of the preprocessor like:

#define PI_PLUS_ONE (3.14 + 1)`

By doing so, you avoid the possibility that an order of operations issue will destroy the meaning of your constant:

x = PI_PLUS_ONE * 5;`

Without parentheses, the above would be converted to

x = 3.14 + 1 * 5;

[src]