C++ "packages"?

[Chocawok]

Hi I've recently designed and implemented a menu system.

Basically I have several classes:

Menu - this contains MenuItems

MenuItems(base class) - can be either a SubMenu or a Switch (Sub menus
display a new menu, switches allow the user - by pressing the space bar
say - to toggle between the switches "options")

Now, Menus are basically a collection of MenuItems. Ones creates MenuItems
(either Submenus or Switches or some future types) and the does a
Menu.AddItem ( new switch());

Problem: when I came to creating a Menu in my code, I realised I had to not
only include Menu.h, but also submenu.h and switch.h.

Also I have to specifically create Switch/Submenu objects then add them to
the menu (menu.additem).

Now all this is fine, but what i was really going for was a more
"encapsulated" type solution.

Really I want to just include one header "menu.h" and also not have to
create separate objects whose only purpose is to be added to the menu
object.

My main reason to think I have made a design "gaff" is that MenuItems have
no meaning on their own! The only point of their existence is as a part of a
Menu object

Any thoughts on this?

Dean

P.S. thanks for all the response to my previous post(s) about the tightly
coupled graphics objects. I'm realising that 1) i still have a LOT to learn.
2) This is a great place to do it! :-)

[Luke Meyers]

Jim Langston wrote:

Well, this is your interface showing. One way to do it, and not one I'm
suggesting, but one way would be to have your Menu class create the
subclasses itself and add them. I probably wouldn't go this way though.
Agreed.
The only real suggestion I would have would be in have your menu.h include
the submenu.h and switch.h itself. All with include guards of course.

I don't think this is a good idea. As a rule, one should only #include
what one explicitly needs. Excess #includes, especially in headers,
are the source of major build slowdowns far too often. Builds take
longer and happen more often due to tightly interwoven dependencies.
It violates the principle of "you don't pay for what you don't use"
which is core to the language.

Luke

[Ed]

Chocawok skrev:

Hi I've recently designed and implemented a menu system.
Snwip. Now all this is fine, but what i was really going for was a more
"encapsulated" type solution.

I'm a C++ virgin, but I thought C++ had namespaces now with the STL?

I'm sure I've missed the point (like most virgins), but I'm surprised
that these aren't precisely the, "Packages," you were looking for.

..ed

--
www.EdmundKirwan.com - Home of The Fractal Class Composition.

[Daniel T.]

In article <HP*********************@fe2.news.blueyonder.co.uk >,
"Chocawok" <no****@nospam.com> wrote:

Hi I've recently designed and implemented a menu system.

Basically I have several classes:

Menu - this contains MenuItems

MenuItems(base class) - can be either a SubMenu or a Switch (Sub menus
display a new menu, switches allow the user - by pressing the space bar
say - to toggle between the switches "options")

Now, Menus are basically a collection of MenuItems. Ones creates MenuItems
(either Submenus or Switches or some future types) and the does a
Menu.AddItem ( new switch());

Problem: when I came to creating a Menu in my code, I realised I had to not
only include Menu.h, but also submenu.h and switch.h.
You only have to include submenu.h and switch.h if you are actually
making new submenus or switches. This is to be expected and there is
nothing wrong with it.
Also I have to specifically create Switch/Submenu objects then add them to
the menu (menu.additem).
Of course, the Menu itself doesn't know what kind of MenuItems you are
going to need, so you have to make them.
Now all this is fine, but what i was really going for was a more
"encapsulated" type solution.

Really I want to just include one header "menu.h" and also not have to
create separate objects whose only purpose is to be added to the menu
object.

My main reason to think I have made a design "gaff" is that MenuItems have
no meaning on their own! The only point of their existence is as a part of a
Menu object

Give MenuItem objects more purpose. It is common in Menu sub-systems
such as yours for the MenuItem to be able to call some method when
"selected". Obviously, you are going to have to create the MenuItems in
your program in order to make sure they call the right code when
selected.
--
Magic depends on tradition and belief. It does not welcome observation,
nor does it profit by experiment. On the other hand, science is based
on experience; it is open to correction by observation and experiment.

"Luke Meyers" <n.***********@gmail.com> wrote in message
news:11*********************@g14g2000cwa.googlegro ups.com...

I don't think this is a good idea. As a rule, one should only #include
what one explicitly needs. Excess #includes, especially in headers,
are the source of major build slowdowns far too often. Builds take
longer and happen more often due to tightly interwoven dependencies.
It violates the principle of "you don't pay for what you don't use"
which is core to the language.

Thanks. You have just identified yet another reason to
prefer Ada over C++.

Richard Riehle