A - you don't have any lists of reference, so that's pretty easy. Unless you mean "I want to model the tables of references as a list", in which case, go ahead. (Although lists don't offer random access -- you have to go through the list in order whenever you want to do something. Depending on what you actually intend to do, that may or may not be a good thing.)

B - If the people who did this are speaking Java, then "ref" just means "Help! I'm doing Java!" since everything is a ref in Java. And in that case, you yourself would need to decide whether you really do need references to objects or just plain objects. (For instance, I personally would expect "Piece of Clothing" to own its own "Clothing Type" object, rather than just link to an external clothing type object. But then, I wouldn't have the "Clothing Type" object contain a table inside it either, so that's already a wash.) If you want to store that as a reference, then by all means (that does mean that the Clothing Type has to already exist before you construct any Piece of Clothing). As to the lists/tables, I don't know if I've ever seen STL containers of reference objects. I don't know if there's a good reason for it, but there probably is. You can store pointers to objects instead if you want. Someone will come along soon and tell you to use smart pointers here, I'm pretty sure.

C - I have no idea what you mean here. I don't see any reason to do any inheritance; I don't see any reason to define a class inside another class. You may have an object containing a member that is an instance of another class, but that is neither exceptional nor what I would think of when I think of "nested class".

A You mean stl vectors? (C++ STL Tutorial) I would like to have a hashtable if I was in Java because of the O(1) complexity of finding stuff. I found out about maps (map - C++ Reference) would that be appropriate?

A. Sure you can use a map, it looks like a hash table, so if that is what you need then go for it.

B. Yes. But pay attention to what tabstop is saying. A C++ design would probably be a lot different. For example, I would create one object out of this design, Clothing. An outfit is just a set of clothing so I don't think it requires a dedicated type of its own, and I personally see a lot of redundancy in the picture.

(My previous post was in reply to whiteflags, so this one is for you tabstop)

A - "I want to model the tables of references as a list". About the random access you're quite right, I do need it and would like to ask you too if do you think the Map object is appropriate.

B - I need references to objects (smart pointers was mentioned by whiteflags). This is because one Piece of Clothing can be a part of many Outfits and I will probably have to list Pieces of Clothing by Tag, Outfit and Clothing Type. This is why I thought it would be best to just have one object Piece of Clothing and then pointers (smart or not) to it. Also to make editing a Piece of Clothing possible.

About redundancy and C++ design. This is one (ok two) big reasons I wrote the post in the first place. What would a good C++ design be like?

In the end I want to be able to know other Pieces of Clothing with the same Tag, in the same Outfit and of the same type. Having one object and then pointers was what I came up with to be able to do this quick, with only one copy of the each object so I could edit it after creation.

A map requires a [key]=value pair. I don't see any natural keys for any of your tables, really.

And I am pretty sure you're a level off, so to speak, in terms of your desire for searching. If you want to list Pieces of Clothing that fit a particular Tag, Outfit, or Clothing Type, that requires zero searching at all, as far as these data structures go. Once I hand you an Outfit, the container inside it contains (pointers to) all the Pieces of Clothing that go with it, no searching needed. That container could be a list, a vector, a queue, or a deque, and no one would notice or care -- because all you have to do is iterate through that container to list off all the Pieces of Clothing. Same thing if I hand you a Tag, or a Clothing Type. You may want to think about how your program will store all the Clothing Types that will show up in your database (and why aren't we doing this in SQL anyway), but that's a completely separate question from figuring out what a Clothing Type, itself, actually is.

It seems like you're off to a great start in creating this program. In your last post (the last one I read anyway, #7) you said some things that could be important when you are thinking about object-oriented design. Take these as your formal requirements. Here they are again:

1. Other Pieces of Clothing with the same Tag.
2. In the same Outfit.
3. And of the same type.

So you have Pieces of Clothing, Tags, Outfits, and Pieces of Clothing can be combined into Outfits. I think of Outfits as a collection of specific pieces of clothing, for example a hat, a belt, a bottom, a top, and a pair of shoes (just for example). These are all pieces of clothing. Maybe I'm totally wrong about this, so let me know if I am, but I'm just spinning the wheels in my head for a minute.

The I before each of the clothing items represents an interface. Interface could mean base class, interface, virtual class, abstract class, etc. It's just what all objects of a similar type have in common. I would define another interface as well, IPieceOfClothing or something similar that would represent all of the components that hats, belts, bottoms, and tops have in common, such as a pattern, color, or size:

@tabstop I'm sorry, I'm not understanding how I can do this without having multiple copies of the same Piece of Clothing

Well, that's ... well ... I don't know. There is never a point at which you need two copies of the same Piece of Clothing. I can't even come up a circumstance in which you might think you need two Pieces of Clothing, assuming we're storing pointers in all of our tables.

So I think there is one important goal of the architecture that I not explaining right: I really don't want to duplicate the instances of the same Piece of Clothing. This is to make suggestions based on the connection between objects.

@nathandelane the tags are for stuff like formal, fat, summer. For when you want to be using this Piece of Clothing or Outfit (each get their own tags).

Also a Tag is a bit more than a string, it really needs to know what Pieces of Clothing and/or Outfits it is associated with.

Knowing this, do smart pointers make more sense? (Yes a database makes even more but I want to put that aside for now)

@tabstop I think we might be having what we call in Portuguese a deaf men conversation. What I'm saying is I do not want to duplicate. What I understand from your suggestion is that I will have to duplicate. What I'm asking is is this really what you are suggesting (to have duplicate).

Well, that's ... well ... I don't know. There is never a point at which you need two copies of the same Piece of Clothing. I can't even come up a circumstance in which you might think you need two Pieces of Clothing, assuming we're storing pointers in all of our tables.

@kotoko

I think if you have a vector of IPieceOfClothing objects, then that can be where they live, and the outfits can "borrow" those objects by pointing to them, hence pointers.

For example (Not actual C++ code, and probably a specialized collection using multiple vectors would help a little more):