How should I interface different classes?

[AnthonyThoreau]

Can someone tell me some best practices for interfacing classes with each other?

Here's a general example what I mean by this:
There's a parent class called "menu".
It's children all need to share the same style of buttons.
But, it's more likely than not that these buttons will be used for more than just the menus.

Obviously, it would be foolish to put methods and variables that take care of the buttons in the parent menu class, because you'll have to rewrite the same code for every parent class that needs these buttons. There's also way more to UI than buttons and menus. So I really need to make a separate class.

I've become annoyed at this point in the past and ended up writing bad classes that just totally break the abstraction of "what it means to be a button".

How should I get these buttons capable of talking in a generic way to everything else?

A couple of ideas pop into my head at this point are using flags for everything (can get messy), or having some sort of dispatched message system.

So to clarify, my ultimate questions are:
Is it worth building this messaging system?
How efficient can this really be and does it really matter?
When can I get away with just static values acting as flags?
How can I make all this stuff as self-documenting as possible?
Is there some basic knowledge I'm missing here to have to be asking this question?

Read my reply below

[Cubbi]

a parent class called "menu"

Hopefully you're saying by this that there is an abstract class that defines the public interface that various menu classes implement.

I really need to make a separate class

Yes, if you can reason about a 'button' as an individual entity with its own properties and behavior, it's prime candidate for a separate class. Your menu likely has-a button or a few.

Is it worth building this messaging system?

Hard to tell what "this" means here, but in general, it's not worth building a messaging system in your situation. There are multiple messaging systems available. Qt and Boost have signals-and-slots, for example.

[AnthonyThoreau]

Hopefully you're saying by this that there is an abstract class that defines the public interface that various menu classes implement.

Yes, to be clear the base class would have a bunch of virtual public interface methods waiting to be implemented by any derived "menu" class. Also, I can tie my shoes... :-) I probably shouldn't have said "parent", but rather "base" class. That's probably what made you think I was an idiot. Sorry, I wasn't all there when I wrote the original question...

So...
Forget about the questions from the last post.

What I really mean to ask is the following:

Is there any way to reduce the clutter that inevitably occurs with interface methods?

If I want to make a whole group of objects into an even more abstract idea, is there any way to "hide" all the public interface methods that are too specific to the inner workings of that idea?

An example of a "more abstract idea" would be going from having to instantiate individual menus to being able to instantiate a whole menu system. How could I make that happen while hiding all the interface methods for the buttons? Maybe this is my ignorance showing, but is that what a namespace is for?