Using empty macros for explicit intent/instruction

[JayhawkZombie]

I've come to a point where, in some code, we have public class methods in core internal code that we want to express that is public for the core to use but should not be accessed outside the core code. There are other class methods that we want to express as API, or express that they should be used to interact with the core classes.
I know the methods could be private or protected, but we don't want to have to make forward declarations to make those visible to other core classes.

Another reason is that some classes have virtual methods that we want to enforce an override for, but the class being derived from must also be able to be instantiated (like having a Button class, for example, and there are some methods that a derived class creating specialized functionality class must override, but the base button class is still functional enough to use on its own). C++ doesn't let me specify this, so I was thinking about doing something like. There may or may not be a Microsoft specific thing I could do, but I'd really rather avoid that.

//somewhere in a globally visible file
#define CORE_METHOD_OVERRIDE_REQUIRED
#define CORE_METHOD_OVERRIDE
#define CORE_METHOD_INTERNAL
#define CORE_METHOD_API
...
//some class definition that isn't an abstract class
CORE_METHOD_OVERRIDE_REQUIRED
  virtual void NotAbstractClass::SomeMethod();

//Some method that our core uses, but probably shouldn't use
//to interface with the class from outside that
CORE_METHOD_INTERNAL
  void NotAbstractClass::SomeOtherMethod();

//Some method that our core uses, but *should* be used 
//by non-core classes to interface with the class
CORE_METHOD_API
  void NotAbstractClass::PureEvil();

//somewhere in derived class
CORE_METHOD_OVERRIDE
  void SpecializedClass::SomeMethod() override;

This makes it sound like the classes are all dependent. They aren't. Most are unaware of others, unless they contain a member that is of another class.
It's not some horrible spaghetti mess.

I'll admit that CORE_METHOD_OVERRIDE probably isn't necessary. But I feel like doing something like CORE_METHOD_OVERRIDE_REQUIRED is very explicit in expressing that requirement, even though the class isn't abstract itself. I can't generate a compiler warning since the class isn't abstract, so this was the best way (besides a comment) that I could think of.

To me, if I were reading that, I would know what methods I am expected to override, which I should expect to be able to use from outside, and what ones I can use internally, and which ones the class writer is telling me I just shouldn't use.

There are also tools that can parse our headers and methods that are marked as internal are ignored.

[JLBorges]

> I've come to a point where, in some code, we have public class methods in core internal code
> that we want to express that is public for the core to use but should not be accessed outside the
> core code. There are other class methods that we want to express as API, or express that they
> should be used to interact with the core classes.

It is usually a mistake to try and address the needs of different audiences from withing the same component. Consider using the Bridge pattern to bridge the two hierarchies.

It is also a mistake to think of an 'interface' as a property associated solely with the object (class) that implements the interface. Anyone who has a pet dog would understand this. The pet dog is an object, at least in the world of object-oriented programming; so what should its interface be? Depends on who is looking at this object; my pet dog exposes one interface to me, and a completely different interface to a stranger.