OOP vs macro problem

Question

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 meth         


        

Answer 1

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:

Answer 2

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]

Answer 3

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... :)

Answer 4

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?

Answer 5

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.

Answer 6

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.