Run time decision on type of new object

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

Is it possible to decide on the type of an object at run time. So in
pseudo-code I am looking for one (or preferably both) of the following....

string s = "SomeExistingClass"
ClassTypeInString(s) MyThing = new ClassTypeInString(s) ;

....or....

SomeClass myVar = new SomeClass() // and later on we do...
ClassTypeOfObject(myVar) MyThing = new ClassTypeOfObject(myVar)

I suspect there is something in System.Reflection. I dipped a toe in there,
but the water looks awfully deep for a beginner. I am trying to convert some
powerbuilder code and I want the equivalent of...

myObj = Create using sSomeStringVariable

Many thanks to the hundreds who reply...
 
I suspect there is something in System.Reflection. I dipped a toe in there,
but the water looks awfully deep for a beginner. I am trying to convert
Click to expand...
some

:) I heard something like "he didnt know it was impossible so he did it!" I
always remember this :)

Have you tried looking at the Activator class. It does something like what u
want to do. It has a CreateInstance method that does that :)

Abubakar.
 
"Paulustrious" <msdn_whoisat_paulcotter.com> a écrit dans le message de
news: (e-mail address removed)...

| Is it possible to decide on the type of an object at run time. So in
| pseudo-code I am looking for one (or preferably both) of the following....
|
| string s = "SomeExistingClass"
| ClassTypeInString(s) MyThing = new ClassTypeInString(s) ;
|
| ...or....
|
| SomeClass myVar = new SomeClass() // and later on we do...
| ClassTypeOfObject(myVar) MyThing = new ClassTypeOfObject(myVar)
|
| I suspect there is something in System.Reflection. I dipped a toe in
there,
| but the water looks awfully deep for a beginner. I am trying to convert
some
| powerbuilder code and I want the equivalent of...
|
| myObj = Create using sSomeStringVariable

You certainly can use Activator.CreateInstance(...) to do things like this,
it works with either strings or Types.

The practice of using strings to decide runtime behaviour is prone to error
due to mis-spelling, and other things. This style of programming is really a
hangover from the days of interpreters like BASIC, Clipper and others. Why
would you want to use strings to make these decisions ?

OTOH, IMO, you would be better advised to use variables of Type to hold the
type that you want to instantiate.

There is a Design Pattern called Class Factory which is recommended, usually
to create instances of derived classes into an abstract class reference or
an interface reference.

Do you have a hierarchy of classes in mind or just any class that comes
along ?
If the former, then I would recommend that you use Activator.CreateInstance
inside a Class Factory class; if the latter, then I personally would
recommend you redesign the way things are being done.

Joanna
 
Hi,


Paulustrious said:
Is it possible to decide on the type of an object at run time. So in
pseudo-code I am looking for one (or preferably both) of the following....

string s = "SomeExistingClass"
ClassTypeInString(s) MyThing = new ClassTypeInString(s) ;
Click to expand...


Hi, you can use one of the CreateInstance method , depending of how/(where
from) you want to instantiate the class.

But that is only half of the problem, how do you intend to use this new
instance?
Unless that all the possible classes share a common interface you will need
to instantiate it in an object variable, (as you do not know beforehand the
real type of the instance).
You would have to use reflection to use the members of the isntance. No a
very elegant thing.

If they support a common interface then all is easy, the "real" type of the
instance is not important as you do have a concrete interface to interact
with it.

Under this presunction then you may wrap the creation of the classes itself
, in such a way that only one class (the factory) knows how to instantiate
the concrete type you will be using. This is called a Factory pattern:
http://en.wikipedia.org/wiki/Factory_method_pattern
 
Thank you all for your replies. Sorry this is so late.

An existing application directed what user could do from a database. So for
example there may be a column called EditMenu which for each user defined
which Editmenu was instantiated at run time.

It actually goes deeper than. There was a rich inheritance structure. So
rather than disabling facilities at run time as in...

If (role == "personnel") Button_LegGo.visible = true

There is a window window_Personel inheriting from win_Internal inheriting
from win_Everyone. So before opening a window there is a stored procedure
that does something like...

select window_class, menu_class from window
where window_type='sales_ledger'
and user = ?

and in psuedo code we have
open ( new window(string_window_class) )

I have to say it works well. Database constraints enforce real window names.
You can distribute a new version of an app with version 1 and 2 of a window
and then on an indivdual, departmental or universal basis switch from version
1 to version 2 ... and if it turns into a dog's dinner switch back.

The other big advantage is you can see the window at design time as the user
sees it rather than imagining that various controls and menu items are/not
disabled, resized, invisible, relabeled, different language depending on who
is looking at it.

I don't want to rewrite the complete methodology. So I will look into all
you have said, but I would like to know if you still agree with Class Factory
as the solution.

I understand your points about Basic / Clipper etc. However this is not an
unstructured system. The abstraction of the window name I think can be a
benefit.

After all, when we get down to machine code it's all if-goto.. :)
 
Back
Top