Newbie: instantiating an object?

  • Thread starter Thread starter Mykl
  • Start date Start date
M

Mykl

Hi all... I'm doing ok so far trying to learn C# on my own, but can't seem
to find the answer to this question...

When you instantiate objects, I'm just wondering, why in C# do you have to
go:

ObjectName varName = new ObjectName();

It seems redundant--- why wouldn't the designers of C# let you do this:

varName = new ObjectName();

Thanks,
Mykl
 
Hi Mykl,

One of the features of C# is that it is very explicit in syntax, primarily
so that people don't make assumptions that lead to errors. In this
particular case, the left hand side of the expression specifies the compile
time type of varName. The right hand side of the expression specifies,
varName's, runtime type. In the case of where the compile time and runtime
type of a variable are the same, you don't have any special behavior -- what
you call on the object is what is executed.

However, when using polymorphism, the compile time type is a base class or
interface and the runtime type can be a derived class or a class or struct
that implements the interface. Therefore, you must be specific in
specifying both the compile time and runtime type to get the behavior you
need.

Additionally, think about the scenario where you instantiate varName to a
runtime type of ObjectName at one point in a program and then try to
instantiate it with SomeOtherObjectName in another part of the program.
That would be bad and could lead to all types of runtime errors that would
be very difficult to debug. How would you know what the real type of
varName should be. Any attempt to make it adhere to the type it was
initially set to would also be error prone because of potential race
conditions.

The current behavior promotes strong typing, which is good for productivity
and creating robust code.

Joe
 
Hi Mykl,
Hi all... I'm doing ok so far trying to learn C# on my own, but can't seem
to find the answer to this question...

When you instantiate objects, I'm just wondering, why in C# do you have to
go:

ObjectName varName = new ObjectName();

It seems redundant--- why wouldn't the designers of C# let you do this:

varName = new ObjectName();
Click to expand...

You have to declare a type before you can create an object to store in it.
This is because the ability to inherit, in an OO language, allows you to
declare the variable to be of a 'parent' type while the object is of a
'child' type.

For example, let's say that you have an interface called ICollectionSorter
and you define different sorting routines, each inheriting your interface:
class QuickSort: ICollectionSorter
class BubbleSort: ICollectionSorter

etc...

Now, you can create a variable that will hold ANY of these objects by doing
this:
ICollectionSorter mysorter = new QuickSort();

Not so redundant now, is it? Your code can use the sorting routine by using
the methods defined in the interface. The code neither knows, nor cares,
which sorting routine you are using. You can substitute one for another
(the Liskov Substitution Principle at work).

In fact, in some circles, the ability to define a variable and create an
object of that type is considered a mixed blessing. It is better to
seperate the act of creating an object from the act of its use. Therefore
it would be preferable to say:

ObjectName var = ObjectFactory.MakeNewObjectName();


Johnathon Amsterdam published an article called 'Java's New Considered
Harmful' in DDJ that made this point for the Java language.
Scott Bain published an article called "The Perspectives of Use vs. Creation
in Object-Oriented Design" that makes this point for OO languages in general
and C# in specific.

The idea is the same: encapsulate the creation of an object and you buy
yourself considerable flexibility.

Either way, the designers of the language were cognizant of the fact that
defining an object is one activity and creating the object as an entirely
different activity.

That is why you have the name of the type appearing twice in your example.

--
--- Nick Malik [Microsoft]
MCSD, CFPS, Certified Scrummaster
http://blogs.msdn.com/nickmalik

Disclaimer: Opinions expressed in this forum are my own, and not
representative of my employer.
I do not answer questions on behalf of my employer. I'm just a
programmer helping programmers.[/QUOTE]
 
Holy smokes... 3 phenomenal answers... you guys rock. Understood SOME of
that--- Looks like I have some reading to do.

Thanks...

Mykl
 
Back
Top