Static and dynamic binding is referring to when an object is created, at compile time or at runtime. There are advantages and disadvantages to either one.
With static binding, you get better run time efficiency because the compiler can actually optimize the code before running it. The drawback is that its less flexible since you have to know the type and number of objects you want created at the design phase.
Dynamic binding offers greater flexibility and a higher level of abstraction than static binding because it is done "on the fly" when a program executes. A programmer may not always know how many objects are needed or the size of an array until it reaches that point in the code. The downside is that it isn't optimized and is a bit slower in execution. Not to mention on smaller systems with limited memory, it could easily eat it all up if the program is not careful.
When referring to methods, it deals with the idea of polymorphism and which type of method is called when a subclass is created and used. Static methods in this case mean that a method in a base class is used even if the object is a subclass. Dynamic means that the current object's implementation of that method is used instead of its base class' version which is "on the fly". (aka virtual functions).
These mild simple definitions go for a lot of other languages like C++ and VB. You can find more information about these two types of bindings by typing phrases like "static binding" or "dynamic binding" into Google.
I hope this makes the distinction a bit more clear. Enjoy!
In programming, particularly the C# language, what are dynamic and static method bindings?
Static means objects are created at compile time.
Dynamic means objects are created at run time.
Binding is tying one object to another object.
In .NET everthing thing is considered an object; classes, its methods, its properties, it variables, data bases, it's tables, its fields, files, controls(classes really), etc.
You can bind objects to other objects at compile time or run time.
Always remember that in .NET everything is an object.
Your classes are objects it has child objects like methods or properties.
Coming from other languages you usually consider methods code and variables data and that they are nothing alike.
In .NET they are alike because they are both objects.
All objects have an associated code written for it.
Internally the CLR handles the code classifications, you use the .NET language of your choice that will tell the CLR what type of object it is.
In C# a "public int name;" line of code will have the C# compiler tell the CLR that you're declaring a variable object. Add "= somevalue" to the same line of code and then the object becomes a static variable object.
Methods are objects also.
private int name
{
code stuff;
}
or
private int name(string var, sting var)
{
code stuff;
}
is the basic declaration of a method object. Method objects can inherit other objects like so(same way you can inherit your friends traits and have inherited your parents traits):
private int name : base object name
{
code stuff;
}
Classes are objects and are declared like so:
private class name
{
code stuff;
}
or
private class name : base class name, interface .. interface
{
code stuff;
}
Class objects and method objects are declared almost in the same way. The reserved word class in C# distigushes them and so does the over all structure.
This is one of the confusing parts of .NET for developers from other languages. But when you consider that everything is an object in .NET it becomes less confusings.
When you see that class objects and method objects are special types of processing objects the declaration of the two and the many similar ways you can declare them becomes less confusing.
When you see that in .NET you only deal with objects and that is what you write code for, from basic to complex it becomes less confusing.
The 'everything is an object' paradigm allows for inheritance of internal objects and external objects. The hiearchy of objects determines the accessibility another object has to that object it's calling or inheriting.
Now, back to your method object....
You usually do dynamic binds because the information you need can only be gotten at run time.
Sometimes you create objects dynamically to better the performance of your application.
Static objects loads differently than dynamic objects.
If you write the code for an openFile() method object both statically and dynamically, the static method object would load taking more memory that the dynamic one.
The CLR knows how much memory to take up for the static method object but doesn't know how much memory to take up for the dynamic method object.
This gives you a better way to reduce your loads and increase performance by controlling the object loads amounts when you write the code for the object.
An extreme would be to write the object's code to load a portion of your object(in this case a method object), unload it- clear the garbarge disposable, load and unload the next portion of the object when needed.
With static objects all portions of the object will load unless you've written the object's code to better handle the object's memory usage in a way better than the CLR does it.
Most times objects are generated dynamically because your logic requires some unknown value to be known before it can process further.
If you were coding for a membership registration that loads different forms based on a persons age, say Teens and Adults, you would need to create code that loads a Teen form if the new user is a teen and an Adult form if the user is an Adult.
You could create the Adult and Teen form objects statically, at compile time.
You could create the object(s) dynamically, this means you will write code to have the form objects drawn to the screen and handle its events at run time.
If the forms are pretty much the same except for a few fields then just the part that differs you'd write dynamically.
Let's say adults add photos of themselves and teen do not, other than that the form is exactly the same.
You would write the code for the form object or if you're using an IDE like C# Expresion, you'll grahpically create the objects but the IDE writes the code for the objects.(in this example the form object and the photo object would be two separate .cs files)
Since the adults can add photos then this portion of the form object will be done dynamically.
You can create the photo object at compile time but have it written to the form object at run time.
This means the form object dynamically gets the photo object.
The photo object portion of the form was not added to it at compile time but instead at run time. You dynamically binded the photo object(all the code that makes of the photo portion of the form) to the form object(all the code that makes up the form object). At runtime if your new user is an adult this will occur.
If the difference between the adult and teen form information is much greater than just a few pieces of information then you'd probably save in performance and maintainence by creating two static form objects(teenform.cs and adultform.cs), one for Teens and one for Adults and load each one based on age. In this case the object that calls the static form object is doing a static binding.
You can also create method objects like a fileOpen() method object at runtime. You write code that will create a method called fileOpen() at runtime but only if some condition is met. The fileOpen() would be a dynamically binded method object to the calling class.
Like the photo object was inserted into the form object, the fileOpen() method object was inserted into the calling class object as a method object to bind to that class like its other method objects. You would have to use the correct syntax for full qualification of the method as a method of the class it's binding to: Namespace.ClasstoBindTo.fileOpen().
Hope that helps....
floral arrangements
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment