As a follow up, I have now converted all my collection classes to being publicly derived from a Singleton class that automates the singleton proceedure. It is working just fine for me to access the arrays and/or lists held in the collection classes. Very nice!

Dave Mark - President and Lead Designer
Intrinsic Algorithm - "Reducing the world to mathematical equations!"

Great! I''m glad I could help.

Have you ''disposed'' of the coder you hired then Dave?



ai-junkie.com

No... he''s still working on some of the other stuff... him and his team. I''ve just resigned myself to the fact that I''m going to have to do a lot more than I anticipated.

I''m actually getting quite good at this considering I was only barely familiar with C++ a few months ago.

Dave Mark - President and Lead Designer
Intrinsic Algorithm - "Reducing the world to mathematical equations!"

quote: Original post by InnocuousFox
As a follow up, I have now converted all my collection classes to being publicly derived from a Singleton class that automates the singleton proceedure.

Darn, I shouldn't have taken yesteday away from my keyboard!!! I was beaten to the punch by the looks of things.

Having read your new example it was painfully obvious that you need to implement inheritance in your class structure. I'm not convinced you need to go with Singleton's, but if it works for you, then by all means do it.

Personally, I think that your configuration class should be a subclass of the aircraft class, since it is a property of an aircraft, rather than say a terminal building! Furthermore, your flight class could be an inherited class from your aircraft class, since it is defined by an aircraft type and a wider set of parameters: departure and landing times/sites, company, terminal, etc. The benefit of this approach is that you can use polymorphic functions in your inheritance structure that have different behaviours depending on what level of the inheritance the function is being called from.

Just food for thought.

Timkin

[edited by - Timkin on January 29, 2003 7:22:27 PM]

Not that anyone asked me but im going to chime in: Fox, polymorphism is by far the coolest feature of Cpp (IMHO)
definitely check it out before you design yourself into a "point of no return" mode. once you start using it a bit you''ll wonder how you ever went without it.

Regaring the inheritance of the config class from the aircraft class, I don''t think you understand the functions of those. The aircraft class is representative of a specific plane in the game. That is... this plane right here that I''m pointing to. I think you were under the impression that I was talking about an aircraft TYPE... as in "a 737-400". In that case, a config would take on some of the aspects of that 737-400 and add to it so inheritance would be appropriate. However, we may have hundreds of aircraft of a particular type and config combination... that is "many 737-400s in a standard 2 class cabin configuration". Rather than toting the data of what a 2 class cabin config is in each plane''s object, I will have a member datum that will be pointing to the specific config that that this aircraft is.

My thinking was the same in separating the type/config into two distinct classes. A config is based off of a certain body type (e.g. the OTHER possible cabin configs that you can put a 737-400 in) If I were to use inheritance, each config would have to have the data "above" it for the 737-400. Many years of relational database modeling has drummed into me that storing the same data over and over is not correct, safe or efficient. So, a config will likewise point to a type... i.e. Config #124 is the 2 class 123 seat version of the type "737-400".

@Dred: I am familiar with the concept of polymorphism and use it where appropriate.

Dave Mark - President and Lead Designer
Intrinsic Algorithm - "Reducing the world to mathematical equations!"

quote: Original post by InnocuousFox
The aircraft class is representative of a specific plane in the game.

In OO programming, as opposed to data mining, a CLASS should be representative of a set of objects with the same attributes, but of differing attribute values. In data mining a CLASS is distinguished by having the same (or similar) attribute values on a subset of its attributes. I think you''ve brought a little too much of your db practice to your OO analysis!

In OO, an instantiation of a class, to one of the possible set of attribute values, reflects a data object in the program. *If* you''ve designed your class so that it only represents one type of aircraft with one set of attribute values, then I would suggest that you haven''t implemented the best OO data structures. I suspect though that this was merely poor use of terminology in your explanation.

I see your point about storing the config information in each instantiation... I guess I was thinking it wouldn''t be more than a few dozen bytes of info and so wouldn''t be costly to store in each aircraft... even with a few thousand aircraft.

So, getting back to your original problem... do I now understand you correctly if I say that your problem was with your collections of aircraft... in that you might want to access data regarding the configuration of a particular aircraft from a list of aircraft... and that the problem was in whether you should be linking collections by pointers or array indexes?

I suspect though that this wasn''t the problem, since this has a trivial solution in including a pointer to a config type within the aircraft class.

I know you said you have a working solution, so you may not feel inclined to discuss this further. If you do though, I would definitely enjoy working through a non-Singleton solution to this problem... I always enjoy the challenge of OO analysis on realistic problems and I would love to get more practice!

Cheers,

Timkin

quote: Original post by Timkin In OO programming, as opposed to data mining, a CLASS should be representative of a set of objects with the same attributes, but of differing attribute values. In data mining a CLASS is distinguished by having the same (or similar) attribute values on a subset of its attributes. I think you''ve brought a little too much of your db practice to your OO analysis!

Well, I think I did more of the former than the latter. Remember my class list is as follows:

Aircraft //the actual individual planes - "pieces" if you will
AircraftCollection //the container that holds the list of aircraft

ACType //info about a specific type. e.g. "Boeing 737-200"
ACTypeCollection

ACConfig //info about a configuration type e.g. "737-200 with 2 seating classes"
ACConfigCollection

As you are shopping for aircraft, you would be looking at the list of types with data about those types... range, cruise speed, runway needed, and obviously cost. This obviously involves browsing the AircraftCollection list.

Once you have a type in mind, you can decide on what cabin config to use of those that are available for that type. That may include data on seating arrangements and their relative capacities in each class of service, the seat width and spacing, etc. That would be the equivalent of browsing the ACConfigCollection list - but filtered by the ACType you have selected.

Once you have decided on that information, you would purchase or lease an aircraft. That would create a new object of the Aircraft class that needs to know what type and config it is as well as information that is specific to that plane (current location, maintenance status and the state machine being obvious examples).

quote: I see your point about storing the config information in each instantiation... I guess I was thinking it wouldn''t be more than a few dozen bytes of info and so wouldn''t be costly to store in each aircraft... even with a few thousand aircraft.

If the configs were completely customizable, it would be stored in the aircraft. They are not. There are only a few possible arrangements for the cabin depending on the type of aircraft. Perhaps no more than 4 or 5 different ones but usually only 2 or 3 per type. Therefore, it is reasonable to assume that all the 737-400 objects in the game will only have 3 possibilites for their config which makes the duplication of data in each object kind of useless.

However, there ARE such things as what type of entertainment service you have available on an aircraft... ranging from nothing through audio, taped video and up to personal live DirectTV feeds in each seat like JetBlue has. THAT is something that is installable on a per plane basis and is therefore stored as a member variable in the Aircraft class rather than creating different configs for each of the combinations.

quote: So, getting back to your original problem... do I now understand you correctly if I say that your problem was with your collections of aircraft... in that you might want to access data regarding the configuration of a particular aircraft from a list of aircraft... and that the problem was in whether you should be linking collections by pointers or array indexes?

I suspect though that this wasn''t the problem, since this has a trivial solution in including a pointer to a config type within the aircraft class.

You ARE correct... that was the problem. The issue with the pointers is that I have no way of storing the aircraft object in a file and expecting the pointer data to be relevant when I reload it. The address of the Config will have changed.

quote: I know you said you have a working solution, so you may not feel inclined to discuss this further. If you do though, I would definitely enjoy working through a non-Singleton solution to this problem... I always enjoy the challenge of OO analysis on realistic problems and I would love to get more practice!

I sense an implication that Singletons are frowned upon?



Dave Mark - President and Lead Designer
Intrinsic Algorithm - "Reducing the world to mathematical equations!"

quote: Original post by InnocuousFox
Aircraft //the actual individual planes - "pieces" if you will
AircraftCollection //the container that holds the list of aircraft

ACType //info about a specific type. e.g. "Boeing 737-200"
ACTypeCollection

ACConfig //info about a configuration type e.g. "737-200 with 2 seating classes"
ACConfigCollection

*SNIP*

Okay... I can''t say I would have done it that way... but then that isn''t relevant here... and it obviously works for you. 8^)

quote: Original post by InnocuousFox
You ARE correct... that was the problem. The issue with the pointers is that I have no way of storing the aircraft object in a file and expecting the pointer data to be relevant when I reload it. The address of the Config will have changed.

Oh, that''s easy to get around! Write customised save and load functions that replace in class y the pointer_to_type_x with an identifier_for_type_x. Make sure there exists an instantiated object of type x before you try and load the object y. When you load y again, set the pointer_to_type_x based on the identifier_for_type_x value. There are a couple of ways to do this... the most clear being the use of a union . Other alternatives include using two different variables or even a single variable... although the latter isn''t very smart.

quote: Original post by InnocuousFox
I sense an implication that Singletons are frowned upon?

Not that I am aware of... in fact, they have a fairly wide use in games AFAIK. It''s simply that I like to be able to come up with solutions without resorting to the extra overhead of management classes and the like... just call it a personal idiosyncracy!


Cheers,

Timkin

quote: Original post by Timkin Oh, that''s easy to get around! Write customised save and load functions that replace in class y the pointer_to_type_x with an identifier_for_type_x.

As I mentioned, in my original post...

quote: I made a quick effort to change my data load function to ask BCollection to return the pointer to a B object when I gave it the index to the array. However, I had originally been calling the data load function of ACollection in its constructor and I ran into some issues so I quickly backed out my changes prior to rethinking the issue.

...that''s the direction I was headed in. However, since that would have involved some more moving around that I was loathe to do until I had explored other solutions, I waited on that part.

I''m thinking for the moment that I may stick with the singleton approach for now. Thanks for the input, however.

Dave Mark - President and Lead Designer
Intrinsic Algorithm - "Reducing the world to mathematical equations!"