If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

"new" type set at runtime?

I have several classes, which we'll call classA, classB and classC to keep things simple, all of which inherit from a single class, which we'll call baseClass. In my code I want to instantiate an object of one of the child types, based on what the user clicks on. So if they click "classA" I want to instantiate an object of type classA, etc. The way I have it working at the moment is that I have a pointer of type baseClass, and the user selection is stored in a string. The string is then run through an if statement which selects the appropriate new statement, something like the sudo-code below:

Clearly, you have an event driven system where the user clicks and that click is handled by handler-code? If so, why not add the item then and there, instead of creating a string, passing it back out, and handling the action associated with the click in some other odd location? If you have a good reason to not do this, thats ok, but if you can, do the work in the handler without the extra code (there is no reason for the string & string parse, its just extra code to maintain and debug unless there is a very good reason to have this stuff). This bypasses the need for checks too --- if the user clicked addClassA button, and you are in the handler for that button, then you add class A, no way that could be invalid (as your string must check for bad values), so you eliminate that mess too.

We really need to understand your needs better, but you can also make a container for the 3 (or N) or whatever classes too, and then use some sort of storage for that. Or you can have a container of each type seperate, if that fits your design better. If you set the classes up properly, you can store them in vector, list, etc. if that fits your needs, just be sure the vector functions that you need are enabled by your class (for example, if you need to use std::sort, you need to create comparison operators and more).

I have to disagree with jonnins' approach for one reason (there might be more or better ones):
If you create your business objects in your GUI-handlers you cement an architecture that will be very difficult to break up later. It contravenes layering of your application with all the problems that come with it:
- scalability impact
- maintainance problems
- code duplication
- ...
I would always, even for small projects, layer my application at least into GUI I/O and business objects, because from experience small (unimportant) projects have a tendency to grow in importance.
By delegating the creation of your business objects to a different module you separate concerns which ensures that minimal code has to be touched if you need to amend/extend your application.

DKyb

-------------------------------
Life is a short warm moment -
Death is the long cold rest.Pink Floyd
-------------------------------

Drybelk is 100% correct, but I still say that you can avoid a string, and possibly the switch statement, as you see fit.

The handler for the gui object has to do *something* such that the program can process the event. So what will it do? Create a string and parse it (current approach)? Call a function that is portable (my preferred approach to GUI code)? Something else? If you go with just having it call another function, what does *that* function do? This is where I say you could just create the object, instead of the a string, to remove both the string and the case statements. If you want the code all in one place, or to layer it up in something like the current design, the function you call can take a parameter(enum, please!) and then you can drop the switch statement around that, and still avoid the string. I argue that the work done to change the code later would be no more than using other methods --- add a new enum value, add that to your case list, add a new handler, call function with new enum parameter, and its the same as using a string to convey the data but more efficient and less confusing to read. Perhaps that is all I am really saying, in the end, is replace your string with an enum, but if you wanted to put each object creation in a seperate function and call that from the handlers without the parameter, that is also reasonable (its the exact same code, you replace the enum creation & case filler statements with function headers to make several tiny functions --- the volume of code is pretty much the same and the maintence is very similar (add a function, add a case statement, its about the same work).

Thanks for the responses. I hadn't thought of the enum approach, but I definitely like it as it will (I think, at least) allow me to use a switch statement rather than a bunch of ifs, and make things cleaner. As far as even handlers go, there is only one that I am working with here, so breaking things out into separate event handlers each of which creates an object of the proper type wouldn't be an option. The way things are set up, the user selects the value from a pull-down list rather than clicking individual buttons, so the only event is the list selection, and it is the same event no matter what the user selects- thus the need to look at a string (or something) to determine what was just selected. Using an enum should definitely make things nicer though. I'll have to look up that 'factory pattern' thing as well - that's not something I am familiar with :) Thanks again!