Thread: Vector of Objects and Constructors

First off, a CD is NOT a CD box. A CD box is a collection of CDs; therefore, a CD is not a CD box.
You don't need a set number of tracks or the number of cds. This should be determined by the number of things you add to the collection.
As for how to write the constructor, I'd suggest:

C++11:
MusicCD(int barCode, string const &title, string const &author,
string const &publisher, int price, /*int noCds this belongs to the cd box*/,
/*int noTracks not necessary, you can query this from the vector size */, std::vector<AudioTrack> MyTracks): /* initialize stuff */, d_MyCd(std::move(MyTracks))

Pre-C++11:
MusicCD(int barCode, string const &title, string const &author,
string const &publisher, int price, /*int noCds this belongs to the cd box*/,
/*int noTracks not necessary, you can query this from the vector size */, const std::vector<AudioTrack>& MyTracks): /* initialize stuff */, d_MyCd(MyTracks)

Also, d_MyCd should probably be named d_MyTracks.

Remember: what you want is a collection of audio tracks. What's the way to represent a collection in C++? A vector or an array (the former for dynamic size and the later for fixed size).

Using "using namespace std;" is fine as long as you understand where to use it and its consequences.
Don't use it headers, and if you use it, remember that it can cause collisions, so if you use it, chances are you can't use functions named "move" or variables named "move", for example, because of collisions.
You can avoid all of this by simply using namespace prefixes explicitly. It's up to you.

Now, regarding design. Know that there are usually two ways of designing objects.
One is a set and getter for every "state" you want to expose. For example, you could get and set every cd in a collection. For some things, only get makes sense, like the number of cds in a collection. You want to add a new cd to increase the number of cds in the collection. Simply resizing the collection by increasing its size without adding a new cd is usually a bad idea.
The second way is pretty much to use the constructors as setters (i.e. they take parameters and sets all member variables) and then only expose getters to the data.
There are different advantages and disadvantages to these approaches, but I suggest you don't worry about them for now. Concentrate on deciding what functionality you want each object to have and provide getters and setters instead. That is, if there is a member variable, then provide a setter and getter for it.

So some comments to the specific objects:
Album:
d_noCds in the diagram is unnecessary because the vector remembers its size. So there is no need for you to do that.
.cpp file lacks the code for the constructor.
Optional:
Album could probably benefit from a getter to get its size and a setter to add new cds to the collection.
(Advanced) Expose iterators to iterate over the collection.

Audio track:
Optional:
Print functions are generally not very good on objects since different parts of applications typically wants to "print" objects differently (some might not want to print track number, for example), so these should generally be written by the caller.
(Advanced) Avoid printing to std::cout in objects. Generally, if anything, you want to print to a stream. This gives the caller much more flexibility in where the caller wants the data to go (i.e. to console output, to file, to some stream for later processing, etc).

CD Collection:
Why does the cd collection take albums and cds? And why are the cds products instead of the cd structure?

Music CD:
A music cd is not a cd box. Why are you inheriting from cd box?

I'm missing a few bits here and there, though.
But a very important point to think about: how is this system going to work? Are you going to create a music cd, add it to a cd collection then add that to a vector of products? E.g.:

MusicCD MyCd(...);
CDCollection MyCdCollection(..., MyCd);
MyProductStore MyStore(..., MyCdCollection);

If so, you should take a step back and learn about polymorphism and pointers first because otherwise it's not going to work.

When we're talking about hierarchies like this with inheritance and base classes, polymorphism becomes absolutely essential to understand. It's not just about virtual classes. It's also about virtual functions and how to avoid type slicing.

You need to make your design a little clearer in the diagram. The set number of cds in album makes no sense for the same reasons I talked about before. Many of your classes lack any public functions. If they lack public functions, how are you going to create and initialize them?

Also for the set functions in your store, you need to consider whether it makes more sense to have a "add new" kind (e.g. add new cd) or "a new collection" type (typically represented by a std::vector). The former is typically more flexible and generally more accepted for setters.

For diamond store, are you sure you want to separate all different products? In the future, if you decide to add more products, you have to add more state, which increases memory and add new functions. Or you could just use the fact that they all are products and have only one adder, getter, possibly finder and deleter.
Also since you store books (which can be comic books), you really need polymorphism here, so std::vector<Book> should be std::vector<std::unique_ptr<Book>>.

As far as design goes, product still lacks getters and the print function is still there which it shouldn't be, as I explained.
Album should have a constructor that takes not one audio cd, but a collection of them. Remember that an album is a collection of cds. AddNewCD should not take a size (why?) and should take a Music CD. Why is it taking an audio track? That makes no sense. An album contains no audio tracks.

Music CD lacks getter for price. It also lacks a proper function for adding new tracks. I expect the AddNewTrack should take a new track as argument, not no arguments.
Finally, AudioTrack lacks getters.

Also, I would expect all classes to contain at least a constructor that sets the common properties, just like the product class.

Thank you very much for you answer.

Originally Posted by Elysia

For diamond store, are you sure you want to separate all different products? In the future, if you decide to add more products, you have to add more state, which increases memory and add new functions. Or you could just use the fact that they all are products and have only one adder, getter, possibly finder and deleter.
Also since you store books (which can be comic books), you really need polymorphism here, so std::vector<Book> should be std::vector<std::unique_ptr<Book>>.

I must split in two my doubts.
I think that makes all sense use only one "add function" to create the different type of products (different subClasses). I think that I was avoiding put it on design, because I don't know how to implement this kind of function.
I think that you're right about the Polymorphism in Book and ComicBook. I need to read more about the subject because I didn't get how it can be implemented.

Creating a conceptual problem was very useful. I figured out how important is the design fase, how important is study some subjects such as Composition or Polymorphism.

This is my current ClassDiagram:
https://dl.dropboxusercontent.com/u/...0diagram_5.png