Inheritance

A C# class may only subclass—inherit from—one other class. Therefore, by inheriting from (subclassing) an abstract class, the derived class has used up its ability to participate in a meaningful type hierarchy.
On the other hand, a class can implement—inherit from—any number of interfaces. And, it can still inherit from (subclass) a base class which makes sense.

[edit]

Single inheritance

C# supports single inheritance: C# does not support multiple inheritance from multiple classes like C++ does. But, by using abstract classes and interfaces, C# programs can achieve most of the same functionality without the confusion and maintenance problems associated with multiple inheritance.

[edit]

Value type polymorphism

.NET value types are objects descending from Object; but, they cannot inherit from other types. They can implement interfaces. Thus, primitives—such as Int32— can implement the IComparable interface, for example, making them comparable.

[edit]

Separation of contract and implementation

Interfaces separate the syntax rather than the semantic contract from the implementation. Classes can be designed to decouple the semantic contract from the implementation. For example, abstract classes can be separated in a different assembly than their concrete implementations.

[edit]

Versioning

An abstract class can contain an interface plus implementations. This simplifies versioning. An abstract class can be extended by adding new nonabstract methods with default implementations. Also, a convenience method is easily added to an abstract class.
An interface cannot be modified without breaking its contract with the classes which implement it. Once an interface has been shipped, its member set is permanently fixed. An API based on interfaces can only be extended by adding new interfaces.

[edit]

Design flexibility

Interfaces offer more design flexibility; precisely because, they can be implemented by any class regardless of its type hierarchy.

[edit]

Visual C# Best Practices

• Use abstract classes and interfaces in combination to optimize your design trade-offs.

[edit]

Use an abstract class

• When creating a class library which will be widely distributed or reused—especially to clients, use an abstract class in preference to an interface; because, it simplifies versioning. This is the practice used by the Microsoft team which developed the Base Class Library. (COM was designed around interfaces.)

• Use an abstract class to define a common base class for a family of types.

• Use an abstract class to provide default behavior.

• Subclass only a base class in a hierarchy to which the class logically belongs.

[edit]

Use an interface

• When creating a standalone project which can be changed at will, use an interface in preference to an abstract class; because, it offers more design flexibility.

• Use interfaces to introduce polymorphic behavior without subclassing and to model multiple inheritance—allowing a specific type to support numerous behaviors.

• Use an interface to design a polymorphic hierarchy for value types.

• Use an interface when an immutable contract is really intended.

• A well-designed interface defines a very specific range of functionality. Split up interfaces that contain unrelated functionality.

[edit]

Summary

The following table compares the features of abstract classes and interfaces.

Abstract class	Interface
Derived classes exhaust their single base class inheritance option.	Classes can implement multiple interfaces without using up their base class option. But, there are no default implementations.
Cannot be instantiated except as part of subclasses. Only derived classes can call an abstract class constructor.	Cannot be instantiated.
Defines abstract member signatures which derived classes must implement. Otherwise, the derived class itself will be abstract.	Defines abstract member signatures—all of which—implementing classes must implement. Otherwise, a compiler error results.
New non-abstract members may be added that derived classes will inherit without breaking version compatibility.	Extending an interface with new members breaks version compatibility.
Optionally, provide default (virtual) member implementation.	All members are virtual and cannot provide implementations.
Can include data fields.	Cannot include data fields. However, abstract properties may be declared.

Radio button validation in javascript

HTML
                     <input type="radio" name="paymenttype" id="paymenttype"  value="Payment through Gayeway"/>Payment By Card
                      <input type="radio" name="paymenttype" id="paymenttype"  value="Payment through Check" />Payment By Check

Script

 if (!checkRadio())
 {
 alert('You have to select payment type');
 return false;
 }


    function checkRadio () {
 var radios = document["frmUser"].elements["paymenttype"];
 for (var i=0; i <radios.length; i++) {
  if (radios[i].checked) {
  document.getElementById("hdn").value=radios[i].value;
//alert(document.getElementById("hdn").value)
   return true;
  }
 }
 return false;
}

Submit in jquery

<html>
<head>
  <style>

  p { margin:0; color:blue; }
  div,p { margin-left:10px; }
  span { color:red; }
  </style>
  <script src="http://code.jquery.com/jquery-latest.js"></script>
</head>
<body>
  <p>Type 'correct' to validate.</p>
  <form action="javascript:alert('success!');">
    <div>
      <input type="text" />

      <input type="submit" />
    </div>
  </form>
  <span></span>
<script>

    $("form").submit(function() {
      if ($("input:first").val() == "correct") {//first input tag,
  //if ($("input:second").val() == "correct") {second input tag,
        $("span").text("Validated...").show();//for all span
        return true;
      }
      $("span").text("Not valid!").show().fadeOut(1000);
      return false;
    });
</script>

</body>
</html>



<html>
<head>
  <style>

  p { margin:0; color:blue; }
  div,p { margin-left:10px; }
  span { color:red; }
  </style>
  <script src="http://code.jquery.com/jquery-latest.js"></script>
</head>
<body>
  <p>Type 'correct' to validate.</p>
 <form id="target" action="destination.html">
  <input type="text" value="Hello there" />
  <input type="submit" value="Go" />
</form>
<div id="other">
  Trigger the handler
</div>
  <span></span>
<script>

   $('#target').submit(function() {
  alert('Handler for .submit() called.');
  return false;
});
$('#other').click(function() {
  $('#target').submit();
});
</script>

</body>
</html>

Ready() event in jquery

.ready( handler ) Returns: jQuery

Description: Specify a function to execute when the DOM is fully loaded.

• version added: 1.0.ready( handler )

  handlerA function to execute after the DOM is ready.

While JavaScript provides the load event for executing code when a page is rendered, this event does not get triggered until all assets such as images have been completely received. In most cases, the script can be run as soon as the DOM hierarchy has been fully constructed. The handler passed to .ready() is guaranteed to be executed after the DOM is ready, so this is usually the best place to attach all other event handlers and run other jQuery code. When using scripts that rely on the value of CSS style properties, it's important to reference external stylesheets or embed style elements before referencing the scripts.
In cases where code relies on loaded assets (for example, if the dimensions of an image are required), the code should be placed in a handler for the load event instead.

The .ready() method is generally incompatible with the <body onload=""> attribute. If load must be used, either do not use .ready() or use jQuery's .load() method to attach load event handlers to the window or to more specific items, like images.

All three of the following syntaxes are equivalent:

• $(document).ready(handler)
• $().ready(handler) (this is not recommended)
• $(handler)

There is also $(document).bind("ready", handler). This behaves similarly to the ready method but with one exception: If the ready event has already fired and you try to .bind("ready") the bound handler will not be executed. Ready handlers bound this way are executed after any bound by the other three methods above.
The .ready() method can only be called on a jQuery object matching the current document, so the selector can be omitted.
The .ready() method is typically used with an anonymous function:

$(document).ready(function() {
  // Handler for .ready() called.
});

Which is equivalent to calling:

$(function() {
 // Handler for .ready() called.
});

If .ready() is called after the DOM has been initialized, the new handler passed in will be executed immediately.

Aliasing the jQuery Namespace

When using another JavaScript library, we may wish to call $.noConflict() to avoid namespace difficulties. When this function is called, the $ shortcut is no longer available, forcing us to write jQuery each time we would normally write $. However, the handler passed to the .ready() method can take an argument, which is passed the global jQuery object. This means we can rename the object within the context of our .ready() handler without affecting other code:

jQuery(document).ready(function($) {
  // Code using $ as usual goes here.
});

Example:

Display a message when the DOM is loaded.

<!DOCTYPE html>
<html>
<head>
  <style>p { color:red; }</style>
  <script src="http://code.jquery.com/jquery-latest.js"></script>
  <script>
  $(document).ready(function () {
  $("p").text("The DOM is now loaded and can be manipulated.");
});
  </script>
</head>
<body>
  <p>Not loaded yet.</p>
</body>
</html>