|
Hi Mr. Chistopher
In the same way I can create Interface with( add, print method etc).
I then Implement this Interface so that I can print from datagrid or datatable.
Correct me if I am wrong.
krishna
|
|
|
|
|
You are correct, although I am not Mr Christopher I am Mr Guy 
The interface declares the methods you will be implementing such as print, add line, page header, page footer etc.
The abstract class then implements these methods but cannot be instantiated - so you then create classes that use the abstract class as their base class overriding the add line etc methods.
Does that make sense to you?
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
modified 8-Mar-13 9:41am.
|
|
|
|
|
Mr. Guy,
I am very much clear about what you said. Now I have another doubt, Is that any rules that abstract class must inherit interface, than we need to override from abstract class ?
I can create a normal class which can implement this Interface and use those methods. But here we have to create instance of the class to access those implemented methods.
So overall you mean to say that, one of the reason to go for abstract class to avoid creating instance of the class ?
krishna
|
|
|
|
|
Hi Krishna,
Please just call me Guy as Mr Guy is too formal for the codeproject
An abstract class does not need to implement an interface.
An abstract class must be inherited as you cannot create an instance of an abstract class - think of an abstract class as something like a Feline, in Keith's excellent illustration, which is a concept and for which there is no such concrete existence.
However there are tigers which are Feline and are very much concrete - so a tiger inherits from the abstract class of Feline.
You can just create an abstract class and then inherit from that class to create your instances(without implementing an interface).
An abstract class allows you to implement some very general methods such as the LookAround method in Keith's illustration which will not need to be overridden.
Abstract classes are a means of writing less code and implementing polymorphism.
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
|
|
|
|
|
Explained very well, thanks a lot guy..
krishna
|
|
|
|
|
Let it evolve as you develop it. Don't force it.
|
|
|
|
|
Abstract class and inheritance is all about building a hierarchy (or family) of classes while Interface is to enforce a contract.
Consider this hierarchy of classes. You can create FlyingVehicle as an abstract class.
Vehicle --> FlyingVehicle --> Helicopter
Consider another hierarchy of classes. You can create Bird as an abstract class.
Animal --> Bird --> Eagle
While the two families of classes are distinct, both the the FlyingVehicle and the Bird classes can implement an Interface called IFlyable.
interface IFlyable {
void Fly();
void Land();
}
As you can see in this example, you created two distinct families of classes using Abstract classes and enforced the ability to fly using an interface.
|
|
|
|
|
Mr.Shameel,
Can you please make those example's little clear, mean to say.. describing interface & abstract class with the same example by inheriting.
krishna
|
|
|
|
|
That's the point here, abstract classes and interfaces are not meant to be used interchangeably (although most programming languages allow you to do that). Classes are to build family and interfaces are to enforce contracts, nothing more, nothing less.
|
|
|
|
|
|
krishnavaradharajan wrote: I know the functionality of Abstract Class & Interface.
Normally the "functionality" has nothing to do with the decision.
You use them because they meet the design needs.
krishnavaradharajan wrote: How to find out which is suitable for particular situation.
1. Collect some requirements.
2. Create a design.
3. Use the design to implement code.
Step 3 is where you decide which one to use based on the objects of the design.
|
|
|
|
|
Hi,
I know the functionality of sqlcommandBuilder.
But when to use sqlcommandbuilder instant of sql query.
If sqlcommandBuilder does everything( insert/update/delete ), than why I required sql query's. I can do everything through sqlcommandBuilder rite.
Is there any particular sinario that i can use sqlcommandBuilder or I cant use sqlcommandBuilder ?
krishna
|
|
|
|
|
krishnavaradharajan wrote: If sqlcommandBuilder does everything( insert/update/delete ), than why I required sql query's.
It doesn't do "everything", just the crud-operations. It's not used when creating a table using a query, or when things get complex. As the documentation states, it only generates a single-table update.
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
|
|
|
|
|
Hi Mr.Eddy,
So you mean to say that, commanbuilder can be used only for simple and single query operation.
Another thing is, consider I have a dataset(ds) of 1000 records, and how do I edit dataset, means how to update without using commanbuilder and fetch only updated rows from ds.
krishna
|
|
|
|
|
krishnavaradharajan wrote: So you mean to say that, commanbuilder can be used only for simple and single query operation.
Yup. It's a shortcut, an easy way to generate a simple query.
krishnavaradharajan wrote: Another thing is, consider I have a dataset(ds) of 1000 records, and how do I edit dataset, means how to update without using commanbuilder and fetch only updated rows from ds.
The GetChanges method will give you everything that changed in the dataset.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
|
You're welcome 
|
|
|
|
|
krishnavaradharajan wrote: when to use sqlcommandbuilder
Never.
|
|
|
|
|
Do you have any particular reason to say never..
krishna
|
|
|
|
|
Experience.
It has always bitten me with its limitations. Plus it's closely associated with DataAdapter which is even worse.
|
|
|
|
|
Thank you..
krishna
|
|
|
|
|
I am trying to develop a very simple wireless sensor node simulator using C#. I have figured out how to "divide" the simulation time into different "states" of the sensor node but I am currently having some problems on how to properly implement a global simulation time for all the sensor nodes.
Here's what I did so far but I am sure there is a much better way to do this.
I made a NODE class which contains a Run() method that has a for loop executed to simulate time. But the obvious problem is, if I duplicate this NODE class to make other nodes (5-10 other nodes), there's a tendency that they will not be synchronized (especially when they communicate with each other).
public void Run()
{
for (int i = 0; i < 1000; i++ )
{
if (sleep)
{
if (csleep < timeToSleep)
{
Sleep(i);
csleep++;
}
else
{
sleep = false;
csleep = 0;
wakeup = true;
}
}
if (wakeup)
{
if (cwakeup < timeToWakeUp)
{
WakeUp(i);
cwakeup++;
}
else
{
wakeup = false;
cwakeup = 0;
listen = true;
}
}
if (listen)
{
...same as above code...
}
if (send)
{
...same as above code...
}
if (receive)
{
...same as above code...
}
}
Console.WriteLine("END SIMULATION");
}
So, when I execute the nodes in the main simulation class, it looks like this:
class Program
{
static void Main(string[] args)
{
Node node1 = new Node();
Node node2 = new Node();
node1.Run();
node2.Run();
}
}
The above codes are obviously incorrect since the simulation time is placed inside each node object. What I am trying to do is this:
I want to treat all nodes as if they are threads communicating with each other or could sometimes just independently "exist" in the simulation. But how do I make it that all of these nodes could have one single basis for the simulation time?
Simulation loop
{
Node 1 executed;
Node 2 executed;
}
|
|
|
|
|
Unless NODE has some sort of interrupt mechanism (Sleep; I/O; etc.), once one is “Run”, it will hog the (one) thread indefinitely.
I would suggest putting the “timing” code in a separate class (or in static methods of the NODE base class), and use a “Timer” instead of a “for” loop for invoking “sleep”, “awake”, etc. states.
Prior to creating and “running” a NODE, start the “timing” object / static methods.
As a NODE is created, it should subscribe to (state-change) events in the timing object that call the “Sleep”, “Awake”, etc. event handlers in a subscribing NODE.
In this way, the timing object will call the “Sleep”, “Awake”, etc. methods in each (subscribing) NODE with each “state” change (i.e. x number of ticks of the Timer).
This of course assumes you want all NODEs to be “asleep” or “awake”, etc. at the same time.
You will need some sort of (message) queuing mechanism to actually “communicate” between these NODEs; since if they are all “sending” at the same time (state-wise), they can also not be “receiving” at the same time.
|
|
|
|
|
Thanks Gerry! I will try your suggestions
|
|
|
|
|
You're welcome. Glad I could help.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
