Subhash Sharma

Subhash Sharma
Subhash Sharma

This is Subhash Sharma(Software Engineer) Blog

Welcome to this blog and find every solution.............

Search This Blog

Software Engineer(Subhash Sharma)

Software Engineer(Subhash Sharma)
Software Engineer

Wednesday, September 15, 2010

Abstract Class and Interface differences with example

An Abstract class without any implementation just looks like an Interface; however there are lot of differences than similarities between an Abstract class and an Interface. Let's explain both concepts and compare their similarities and differences.

What is an Abstract Class?

An abstract class is a special kind of class that cannot be instantiated. So the question is why we need a class that cannot be instantiated? An abstract class is only to be sub-classed (inherited from). In other words, it only allows other classes to inherit from it but cannot be instantiated. The advantage is that it enforces certain hierarchies for all the subclasses. In simple words, it is a kind of contract that forces all the subclasses to carry on the same hierarchies or standards.

What is an Interface?

An interface is not a class. It is an entity that is defined by the word Interface. An interface has no implementation; it only has the signature or in other words, just the definition of the methods without the body. As one of the similarities to Abstract class, it is a contract that is used to define hierarchies for all subclasses or it defines specific set of methods and their arguments. The main difference between them is that a class can implement more than one interface but can only inherit from one abstract class. Since C# doesn�t support multiple inheritance, interfaces are used to implement multiple inheritance.

Both Together

When we create an interface, we are basically creating a set of methods without any implementation that must be overridden by the implemented classes. The advantage is that it provides a way for a class to be a part of two classes: one from inheritance hierarchy and one from the interface.

When we create an abstract class, we are creating a base class that might have one or more completed methods but at least one or more methods are left uncompleted and declared abstract. If all the methods of an abstract class are uncompleted then it is same as an interface. The purpose of an abstract class is to provide a base class definition for how a set of derived classes will work and then allow the programmers to fill the implementation in the derived classes.

There are some similarities and differences between an interface and an abstract class that I have arranged in a table for easier comparison:

Feature

Interface

Abstract class

Multiple inheritance

A class may inherit several interfaces.

A class may inherit only one abstract class.

Default implementation

An interface cannot provide any code, just the signature.

An abstract class can provide complete, default code and/or just the details that have to be overridden.

Access Modfiers An interface cannot have access modifiers for the subs, functions, properties etc everything is assumed as public An abstract class can contain access modifiers for the subs, functions, properties
Core VS Peripheral

Interfaces are used to define the peripheral abilities of a class. In other words both Human and Vehicle can inherit from a IMovable interface.

An abstract class defines the core identity of a class and there it is used for objects of the same type.

Homogeneity

If various implementations only share method signatures then it is better to use Interfaces.

If various implementations are of the same kind and use common behaviour or status then abstract class is better to use.

Speed

Requires more time to find the actual method in the corresponding classes.

Fast

Adding functionality (Versioning)

If we add a new method to an Interface then we have to track down all the implementations of the interface and define implementation for the new method.

If we add a new method to an abstract class then we have the option of providing default implementation and therefore all the existing code might work properly.

Fields and Constants No fields can be defined in interfaces An abstract class can have fields and constrants defined
Using the Code

Let me explain the code to make it a bit easier. There is an Employee abstract class and an IEmployee interface. Within the Abstract class and the Interface entity I am commenting on the differences between the artifacts.

I am testing both the Abstract class and the Interface by implementing objects from them. From the Employee abstract class, we have inherited one object: Emp_Fulltime. Similarly from IEmployee we have inherited one object: Emp_Fulltime2.

In the test code under the GUI, I am creating instances of both Emp_Fulltime and Emp_Fulltime2 and then setting their attributes and finally calling the calculateWage method of the objects.

Abstract Class Employee

Collapse
using System;

namespace AbstractsANDInterfaces
{
///


/// Summary description for Employee.

///


public abstract class Employee
{
//we can have fields and properties


//in the Abstract class

protected String id;
protected String lname;
protected String fname;

//properties


public abstract String ID
{
get;
set;
}

public abstract String FirstName
{
get;
set;
}

public abstract String LastName
{
get;
set;
}
//completed methods


public String Update()
{
return "Employee " + id + " " +
lname + " " + fname +
" updated";
}
//completed methods


public String Add()
{
return "Employee " + id + " " +
lname + " " + fname +
" added";
}
//completed methods


public String Delete()
{
return "Employee " + id + " " +
lname + " " + fname +
" deleted";
}
//completed methods


public String Search()
{
return "Employee " + id + " " +
lname + " " + fname +
" found";
}

//abstract method that is different


//from Fulltime and Contractor

//therefore i keep it uncompleted and

//let each implementation

//complete it the way they calculate the wage.


public abstract String CalculateWage();

}
}
Interface Employee


using System;


namespace AbstractsANDInterfaces
{
///


/// Summary description for IEmployee.

///


public interface IEmployee
{
//cannot have fields. uncommenting


//will raise error!
// protected String id;
// protected String lname;
// protected String fname;


//just signature of the properties

//and methods.

//setting a rule or contract to be

//followed by implementations.


String ID
{
get;
set;
}

String FirstName
{
get;
set;
}

String LastName
{
get;
set;
}

// cannot have implementation


// cannot have modifiers public

// etc all are assumed public

// cannot have virtual


String Update();

String Add();

String Delete();

String Search();

String CalculateWage();
}
}
Inherited Objects

Emp_Fulltime:


using System;

namespace AbstractsANDInterfaces
{
///


/// Summary description for Emp_Fulltime.

///


//Inheriting from the Abstract class

public class Emp_Fulltime : Employee
{
//uses all the properties of the


//Abstract class therefore no

//properties or fields here!


public Emp_Fulltime()
{
}


public override String ID
{
get

{
return id;
}
set
{
id = value;
}
}

public override String FirstName
{
get

{
return fname;
}
set
{
fname = value;
}
}

public override String LastName
{
get

{
return lname;
}
set
{
lname = value;
}
}

//common methods that are

//implemented in the abstract class

public new String Add()
{
return base.Add();
}
//common methods that are implemented


//in the abstract class

public new String Delete()
{
return base.Delete();
}
//common methods that are implemented


//in the abstract class

public new String Search()
{
return base.Search();
}
//common methods that are implemented


//in the abstract class

public new String Update()
{
return base.Update();
}

//abstract method that is different


//from Fulltime and Contractor

//therefore I override it here.

public override String CalculateWage()
{
return "Full time employee " +
base.fname + " is calculated " +
"using the Abstract class...";
}
}
}
Emp_Fulltime2:


using System;

namespace AbstractsANDInterfaces
{
///

/// Summary description for Emp_fulltime2.


///


//Implementing the interface

public class Emp_fulltime2 : IEmployee
{
//All the properties and


//fields are defined here!

protected String id;
protected String lname;
protected String fname;

public Emp_fulltime2()
{
//


// TODO: Add constructor logic here

//

}

public String ID
{
get

{
return id;
}
set
{
id = value;
}
}

public String FirstName
{
get
{
return fname;
}
set

{
fname = value;
}
}

public String LastName
{
get
{
return lname;
}
set
{
lname = value;
}
}

//all the manipulations including Add,Delete,


//Search, Update, Calculate are done

//within the object as there are not

//implementation in the Interface entity.

public String Add()
{
return "Fulltime Employee " +
fname + " added.";
}

public String Delete()
{
return "Fulltime Employee " +
fname + " deleted.";
}

public String Search()
{
return "Fulltime Employee " +
fname + " searched.";
}

public String Update()
{
return "Fulltime Employee " +
fname + " updated.";
}

//if you change to Calculatewage().


//Just small 'w' it will raise

//error as in interface

//it is CalculateWage() with capital 'W'.

public String CalculateWage()
{
return "Full time employee " +
fname + " caluculated using " +
"Interface.";
}
}
}
Code for Testing

Collapse
//This is the sub that tests both

//implementations using Interface and Abstract

private void InterfaceExample_Click(object sender,
System.EventArgs e)
{
try

{

IEmployee emp;

Emp_fulltime2 emp1 = new Emp_fulltime2();

emp = emp1;
emp.ID = "2234";
emp.FirstName= "Rahman" ;
emp.LastName = "Mahmoodi" ;
//call add method od the object


MessageBox.Show(emp.Add().ToString());

//call the CalculateWage method

MessageBox.Show(emp.CalculateWage().ToString());


}
catch(Exception ex)
{
MessageBox.Show(ex.Message);
}

}

private void cmdAbstractExample_Click(object sender,
System.EventArgs e)
{

Employee emp;

emp = new Emp_Fulltime();


emp.ID = "2244";
emp.FirstName= "Maria" ;
emp.LastName = "Robinlius" ;
MessageBox.Show(emp.Add().ToString());

//call the CalculateWage method


MessageBox.Show(emp.CalculateWage().ToString());

}

Conclusion

In the above examples, I have explained the differences between an abstract class and an interface. I have also implemented a demo project which uses both abstract class and interface and shows the differences in their implementation.

Monday, September 13, 2010

Bind Data Through Linq

SqlConnection con = new SqlConnection(ConfigurationManager.ConnectionStrings["Master2"].ConnectionString);



DataClassesDataContext db = new DataClassesDataContext(con);
var q = from empname in db.GetTable()
select empname.empid ;
GridView1.DataSource = q;
GridView1.DataBind();

Thursday, September 9, 2010

Transaction Isolation Level

I want to tell you about Transaction Isolation Level in SQL Server 6.5 and SQL Server 7.0, what kinds of Transaction Isolation Level exist, and how you can set the appropriate Transaction Isolation Level.

There are four isolation levels:

READ UNCOMMITTED
READ COMMITTED
REPEATABLE READ
SERIALIZABLE


SQL Server 6.5 supports all of these Transaction Isolation Levels, but has only three different behaviors, because in SQL Server 6.5 REPEATABLE READ and SERIALIZABLE are synonyms. It because SQL Server 6.5 supports only page locking (the row level locking does not fully supported as in SQL Server 7.0) and if REPEATABLE READ isolation level was set, the another transaction cannot insert the row before the first transaction was finished, because page will be locked. So, there are no phantoms in SQL Server 6.5, if REPEATABLE READ isolation level was set.

SQL Server 7.0 supports all of these Transaction Isolation Levels and can separate REPEATABLE READ and SERIALIZABLE.
Let me to describe each isolation level.

read uncommitted

When it's used, SQL Server not issue shared locks while reading data. So, you can read an uncommitted transaction that might get rolled back later. This isolation level is also called dirty read. This is the lowest isolation level. It ensures only that a physically corrupt data will not be read.

read committed

This is the default isolation level in SQL Server. When it's used, SQL Server will use shared locks while reading data. It ensures that a physically corrupt data will not be read and will never read data that another application has changed and not yet committed, but it does not ensure that the data will not be changed before the end of the transaction.

repeatable read

When it's used, the dirty reads and nonrepeatable reads cannot occur. It means that locks will be placed on all data that is used in a query, and another transactions cannot update the data.

This is the definition of nonrepeatable read from SQL Server Books Online:

nonrepeatable read
When a transaction reads the same row more than one time, and between the
two (or more) reads, a separate transaction modifies that row. Because the
row was modified between reads within the same transaction, each read
produces different values, which introduces inconsistency.
serializable

Most restrictive isolation level. When it's used, then phantom values cannot occur. It prevents other users from updating or inserting rows into the data set until the transaction is complete.

This is the definition of phantom from SQL Server Books Online:

phantom
Phantom behavior occurs when a transaction attempts to select a row that
does not exist and a second transaction inserts the row before the first
transaction finishes. If the row is inserted, the row appears as a phantom
to the first transaction, inconsistently appearing and disappearing.
You can set the appropriate isolation level for an entire SQL Server session by using the SET TRANSACTION ISOLATION LEVEL statement. This is the syntax from SQL Server Books Online:

SET TRANSACTION ISOLATION LEVEL
{
READ COMMITTED
| READ UNCOMMITTED
| REPEATABLE READ
| SERIALIZABLE
}
You can use DBCC USEROPTIONS command to determine the Transaction Isolation Level currently set. This command returns the set options that are active for the current connection. This is the example:

SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED
GO
DBCC USEROPTIONS
GO
This is the result:

Set Option Value
------------------------------ ------------------------------------
textsize 64512
language us_english
dateformat mdy
datefirst 7
isolation level read uncommitted

Wednesday, September 8, 2010

textbox value should not be more than 14 character and take only integer value

//textbox onblur Event

asp:TextBox ID="TextBox1" runat="server" onblur="Checktextboxlenth(this);">/asp:TextBox>



//.js file

function ValidateCCNum(ccNum)
{
var ccno = ccNum.value;
if(ccno == "")
{

return true;
}

if(isNaN(ccno))
{

alert("Credit card number should be numeric");
ccNum.value="";
ccNum.focus();

return false;
}


if(ccno.length < 14 || ccno.length >18)
{

alert("Credit card number should have 14-18 digits length");
ccNum.value="";
ccNum.focus();

return false;
}
return true;
}

text box will not take more than 5 character

//.js file

function Checktextboxlenth(ccNum)
{
var ccno = ccNum.value;
if(ccno.length < 0 || ccno.length >5)
{
alert("length cant acces 5 character");
return false ;
}

return true;
}

////onpageload

btnId1.Attributes.Add("onclick", "Checktextboxlenth(TextBox1)");