List

Data Structure 

1. IEnumerable
2. IQueryable
3. Dictionary and IDictionary
4. ICollection
5. HashTable
6. IList or List

7. ArrayList 

http://www.dotnet-tricks.com/Tutorial/csharp/bDRH230314-Understanding-Collections-and-Collections-Interfaces.html

http://www.dotnet-tricks.com/Tutorial/linq/I8SY160612-IEnumerable-VS-IQueryable.html

*******************IEnumerable***************************

IEnumerable exists in System.Collections Namespace.

MyDataContext dc = new MyDataContext ();

IEnumerable<Employee> list = dc.Employees.Where(p => p.Name.StartsWith("S"));

list = list.Take<Employee>(10);

SELECT [t0].[EmpID], [t0].[EmpName], [t0].[Salary] FROM [Employee] AS [t0]WHERE [t0].[EmpName] LIKE @p0

*******************IQueryable ***************************

IQueryable exists in System.Linq Namespace.

MyDataContext dc = new MyDataContext ();
IQueryable<Employee> list = dc.Employees.Where(p => p.Name.StartsWith("S"));
list = list.Take<Employee>(10); 

SELECT TOP 10 [t0].[EmpID], [t0].[EmpName], [t0].[Salary] FROM [Employee] AS [t0] WHERE [t0].[EmpName] LIKE @p0

Notice that in this query "top 10" is exist since IQueryable executes query in SQL server with all filters.

************** HashTable*************************

 Hashtable weeks = new Hashtable();
            weeks.Add("1", "SunDay");
            weeks.Add("2", "MonDay");
            weeks.Add("3", "TueDay");
            weeks.Add("4", "WedDay");
            weeks.Add("5", "ThuDay");
            weeks.Add("6", "FriDay");
            weeks.Add("7", "SatDay");
            //Display a single Item 
            MessageBox.Show(weeks["5"].ToString ());
            //Search an Item 
            if (weeks.ContainsValue("TueDay"))
            {
                MessageBox.Show("Find");
            }
            else
            {
                MessageBox.Show("Not find");
            }

            //remove an Item 
            weeks.Remove("3");
            //Display all key value pairs
            foreach (DictionaryEntry day in weeks )
            {
                MessageBox.Show (day.Key + "   -   " + day.Value );
            }

************* ArrayList *****************

 int i = 0;
            ArrayList ItemList = new ArrayList();
            ItemList.Add("Item4");
            ItemList.Add("Item5");
            ItemList.Add("Item2");
            ItemList.Add("Item1");
            ItemList.Add("Item3");
            MessageBox.Show ("Shows Added Items");
            for (i = 0; i < = ItemList.Count - 1; i++)
            {
                MessageBox.Show(ItemList[i].ToString());
            }
            //insert an item 
            ItemList.Insert(3, "Item6");
            //sort itemms in an arraylist 
            ItemList.Sort();
            //remove an item 
            ItemList.Remove("Item1");
            //remove item from a specified index 
            ItemList.RemoveAt(3);
            MessageBox.Show("Shows final Items the ArrayList");
            for (i = 0; i < = ItemList.Count - 1; i++)
            {
                MessageBox.Show(ItemList[i].ToString());
            }

***************IList or List****************

http://www.dotnet-tricks.com/Tutorial/linq/VXTY160612-IEnumerable-VS-IList.html

 List < string > colors = new List < string > ();
            //add items in a List collection
            colors.Add("Red");
            colors.Add("Blue");
            colors.Add("Green");
            //insert an item in the list
            colors.Insert(1, "violet");
            //retrieve items using foreach loop
            foreach (string color in colors)
            {
                MessageBox.Show(color);
            }
            //remove an item from list
            colors.Remove("violet");
            //retrieve items using for loop
            for (int i = 0; i < colors.Count; i++)
            {
                MessageBox.Show(colors[i]);
            }
            if (colors.Contains("Blue"))
            {
                MessageBox.Show("Blue color exist in the list");
            }
            else
            {
                MessageBox.Show("Not exist");
            }

            //copy array to list
            string[] strArr = new string[3];
            strArr[0] = "Red";
            strArr[1] = "Blue";
            strArr[2] = "Green";
            List < string > arrlist = new List < string > (strArr);
            foreach (string str in strArr)
            {
                MessageBox.Show(str);
            }
            //call clear method
            arrlist.Clear ();
            MessageBox.Show(arrlist.Count.ToString ());
        }

******* Dictionary and IDictionary**********

Dictionary is a generic type, Hashtable is not. That means you get type safety with Dictionary, because you can't insert any random object into it, and you don't have to cast the values you take out. Since both Dictionary and Hashtable are internally hashtables

Dictionary < string, int > dict = new Dictionary < string, int > ();
dict.Add("one", 1);
dict.Add("two", 2);
dict.Add("three", 3);
dict.Add("four", 4);

foreach (KeyValuePair < string, int >  pair in dict)
{
 MessageBox.Show(pair.Key.ToString() + "  -  " + pair.Value.ToString());
}

***************************************

Operation 

Algorithm = > Operation

http://auk-port.blogspot.com/2012/08/difference-among-ienumerable-iqueryable_5620.html

http://people.cs.aau.dk/~normark/oop-csharp/html/notes/collections_themes-list-sect.html

http://www.dotnet-tricks.com/Tutorial/linq/I8SY160612-IEnumerable-VS-IQueryable.html

MVC Unit Testing

http://www.codeproject.com/Articles/763928/MVC-Unit-Testing-Unleashed

An ASP.NET MVC SiteMapProvider implementation for the ASP.NET MVC framework.

PM> INSTALL-PACKAGE mvcsitemapprovider.mvc4

http://maartenba.github.io/MvcSiteMapProvider/getting-started.html

C#

Abstraction

Hiding the implementation and providing services to user is known as Abstraction. 

Polymorphism

Polymorphism means “Many forms”, When one method behaves in different forms it is known as Polymorphism. Also, new implementation of same method with different signature is known as Function Overloading. There are the following two types of Polymorphism.

• Static Polymorphism
• Dynamic Polymorphism

Func

http://msdn.microsoft.com/en-us/library/bb549151.aspx

Func<X, Y, Z> translated to English is: “A method that takes an X, and a Y as parameters and returns a Z”.”

using System;

class Program
{
    static void Main()
    {
 //
 // Create a Func instance that has one parameter and one return value.
 // ... Parameter is an integer, result value is a string.
 //
 Func<int, string> func1 = (x) => string.Format("string = {0}", x);
 //
 // Func instance with two parameters and one result.
 // ... Receives bool and int, returns string.
 //
 Func<bool, int, string> func2 = (b, x) =>
     string.Format("string = {0} and {1}", b, x);
 //
 // Func instance that has no parameters and one result value.
 //
 Func<double> func3 = () => Math.PI / 2;

 //
 // Call the Invoke instance method on the anonymous functions.
 //
 Console.WriteLine(func1.Invoke(5));
 Console.WriteLine(func2.Invoke(true, 10));
 Console.WriteLine(func3.Invoke());
    }
}

Output

string = 5
string = True and 10
1.5707963267949

 We stored anonymous functions inside Func pointers and then invoked those methods through the Invoke method on the Func instances.

The Action type receives parameters but does not return a parameter. Func receives parameters and returns a result value.

So:An Action instance never returns anything, while the Func always returns something.

C# Action
using System;

class Program
{
    static void Main()
    {
 // Example Action instances.
 // ... First example uses one parameter.
 // ... Second example uses two parameters.
 // ... Third example uses no parameter.
 // ... None have results.
 Action<int> example1 =
     (int x) => Console.WriteLine("Write {0}", x);
 Action<int, int> example2 =
     (x, y) => Console.WriteLine("Write {0} and {1}", x, y);
 Action example3 =
     () => Console.WriteLine("Done");
 // Call the anonymous methods.
 example1.Invoke(1);
 example2.Invoke(2, 3);
 example3.Invoke();
    }
}

Output

Write 1
Write 2 and 3
Done

http://www.dotnetperls.com/func

http://www.growingwiththeweb.com/2012/08/func-and-action-basics-in-c.html

Timer

Timer Example ; Auto  Fire after 3 seconds...........................

using System;

using System.Collections.Generic;

using System.ComponentModel;

using System.Data;

using System.Drawing;

using System.Linq;

using System.Text;

using System.Threading.Tasks;

using System.Windows.Forms;

using System.Text;

using System.Timers;

namespace WindowsFormsApplication1

{

  

    public partial class Form1 : Form

    {

       private System.Timers.Timer timer;

       private int counter = 0;

       public Form1()

       {

        

           InitializeComponent();

           timer = new System.Timers.Timer();

           timer.Elapsed += timer_Elapsed;

           timer.Interval = (1000 * 3);

           timer.Start();

       }

       void timer_Elapsed(object sender, ElapsedEventArgs e)

       {

           counter = counter + 1;

       

               timer.Stop();

             MessageBox.Show(counter.ToString());

               timer.Start();

         

       }

    }

}

http://www.codeproject.com/Tips/480049/Shut-Down-Restart-Log-off-or-Lock-your-computer-in

SOLID

Introduction:   

As we all know that using Object Oriented Programming System (OOPS) concepts and using classes, objects will not show that we are writing efficient code in our applications. Without knowing OOPS principles we will be using OOPS and facing problems in maintaing and enhancing the code in our applications. So we should know how to implement OOPS and use them in right manner, that is where 5 Object Oriented Principles (also called as SOLID Principles) comes into picture. Let us go through each principle and understand how to implement classes and objects in our real time applications.

Single Responsibility Principle:

One Class should be responsible for one task.

E.g.

Want to Insert data into database and want to log the details.

If we create a class to represent DataAccess, it should not be used to save to the database (task 1), as well as log the details (task 2).

Problem:

If we want to change database type or we want to change the logger type/location, If both tasks present in single class, one task changes affects to another.

Solution:

Create one class for saving into database and another class for logging the details.

  

Exmple:

C#

//1. Single Responsibility Principle 
 
// Data access class is only responsible for data base related operations 
class DataAccess 
{ 
    public static void InsertData() 
    { 
        Console.WriteLine("Data inserted into database successfully"); 
    } 
} 
// Logger class is only responsible for logging related operations 
class Logger 
{ 
    public static void WriteLog() 
    { 
        Console.WriteLine( "Logged Time:"  + DateTime.Now.ToLongTimeString() + " Log  Data insertion completed successfully"); 
    } 
}

Open Closed Principle:

Classes, modules, functions, etc. should be open for extension, but closed for modification.

Create a Base class with Required functionality, and ensure we will not modify that class. (Closed for modification)

Create a Derived class by inheriting the Base class for extension (Open for modification)

Example:

C#

//2. Open Close Principle 
// Here DataProvder is open for extension (extends to Sql, Oracle, Oledb Providers and so on..) and closed for manipulation 
abstract class DataProvider 
{ 
    public abstract  int OpenConnection(); 
    public abstract  int CloseConnection(); 
    public abstract int ExecuteCommand(); 
} 
class SqlDataProvider : DataProvider 
{ 
    public override int OpenConnection() 
    { 
        Console.WriteLine("\nSql Connection opened successfully"); 
        return 1; 
    } 
    public override int CloseConnection() 
    { 
        Console.WriteLine("Sql Connection closed successfully"); 
        return 1; 
    } 
    public override int ExecuteCommand() 
    { 
        Console.WriteLine("Sql Command Executed successfully"); 
        return 1; 
    } 
} 
class OracleDataProvider : DataProvider 
{ 
    public override int OpenConnection() 
    { 
        Console.WriteLine("Oracle Connection opened successfully"); 
        return 1; 
    } 
    public override int CloseConnection() 
    { 
        Console.WriteLine("Oracle Connection closed successfully"); 
        return 1; 
    } 
    public override int ExecuteCommand() 
    { 
        Console.WriteLine("Oracle Command Executed successfully"); 
        return 1; 
    } 
} 
 
class OledbDataProvider : DataProvider 
{ 
    public override int OpenConnection() 
    { 
        Console.WriteLine("OLEDB Connection opened successfully"); 
        return 1; 
    } 
    public override int CloseConnection() 
    { 
        Console.WriteLine("OLEDB Connection closed successfully"); 
        return 1; 
    } 
    public override int ExecuteCommand() 
    { 
        Console.WriteLine("OEDB Command Executed successfully"); 
        return 1; 
    } 
} 
class OpenClosePrincipleDemo 
{ 
    public static void OSPDemo() 
    { 
        Console.WriteLine("\n\nOpen Close Principle Demo "); 
 
        DataProvider DataProviderObject = new SqlDataProvider(); 
        DataProviderObject.OpenConnection(); 
        DataProviderObject.ExecuteCommand(); 
        DataProviderObject.CloseConnection(); 
 
        DataProviderObject = new OracleDataProvider(); 
        DataProviderObject.OpenConnection(); 
        DataProviderObject.ExecuteCommand(); 
        DataProviderObject.CloseConnection(); 
    } 
}

Liskov Substitution Principle:

Subtypes must be substitutable for their base types.

http://www.abhishekshukla.com/net-2/solid-design-principles-liskov-substitution-principle-lsp/

http://www.codeproject.com/Articles/595160/Understand-Liskov-Substitution-Principle-LSP

This principle is just an extension of the Open Close Principle. 

It means that we must make sure that new derived classes are extending the base classes without changing their behavior.

Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it. 

 Or   

If any module is using a Base class then the reference to that Base class can be replaced with a Derived class without affecting the functionality of the module. 

Or 

While implementing derived classes, need to ensure that the derived classes just extend the functionality of base classes without replacing the functionality of base classes. 

E.g.

If we are calling a method defined at a base class upon an abstracted class, the function must be implemented properly on the subtype class. 

// If any module is using a Base class then the reference to that Base class can be replaced with a Derived class without affecting the functionality of the module.  

// Or  

// While implementing derived classes, one needs to ensure that, derived classes just extend the functionality of base classes without replacing the functionality of base classes.     

4

public abstract class Shape {     public abstract double GetArea(); } public class Rectangle : Shape {     private double _height;     private double _width;     public double Height     {         get { return _height; }         set { _height = value; }     }     public double Width     {         get { return _width; }         set { _width = value; }     }     public override double GetArea()     {         return Height * Width;     } } public class Square : Shape {     private double _sideLength;     public double SideLength     {         get    {   return _sideLength;        }         set    {   _sideLength = value;      }     }     public override double GetArea()     {         return SideLength*SideLength;     } } static void Main()         {             Shape shape = new Rectangle { Height = 40, Width = 60 };             Console.WriteLine("Area of the rectangle shape = " + shape.GetArea());             shape = new Square { SideLength = 40 };             Console.WriteLine("Area of the square shape = " + shape.GetArea());             Console.ReadLine();         } Area of the rectangle shape = 2400 Area of the square shape = 1600 So now the parent class is substitutable by the child classes without changing any existing functionality and so we are not violating the Liskov Substitution Principle.

Interface Segregation Principle:

Clients should not be forced to depend upon interfaces that they do not use.

E.g.

When a client depends upon a class that contains interfaces that the client does not use, but that other clients do use, then that client will be affected by the changes that those other clients force upon the class

Base Interface:                                 IDataProvider

Derived Interfaces:         ISqlDataProvider, IOracleDataProvider

Derived Classes:                SqlDataClient, OracleDataClient

Each Derived class should implement functions from their respective interfaces.

No derived interface force other derived classes to implement the functionalities which they won't use.

Example:

C#

// Only common generic methods exists for all derived classes. 
interface IDataProvider 
{ 
    int OpenConnection(); 
    int CloseConnection(); 
} 
// Implement methods specific to the respective derived classes 
interface ISqlDataProvider : IDataProvider 
{ 
    int ExecuteSqlCommand(); 
} 
// Implement methods specific to the respective derived classes 
interface IOracleDataProvider : IDataProvider 
{ 
    int ExecuteOracleCommand(); 
} 
// Client 1 
// Should not force SqlDataProvider client to implement ExecuteOracleCommand, as it wont required that method to be implemented. 
// So that we will derive ISqlDataProvider not IOracleDataProvider 
class SqlDataClient : ISqlDataProvider 
{ 
    public int OpenConnection() 
    { 
        Console.WriteLine("\nSql Connection opened successfully"); 
        return 1; 
    } 
    public int CloseConnection() 
    { 
        Console.WriteLine("Sql Connection closed successfully"); 
        return 1; 
    } 
 
    // Implemeting ISqlDataProvider, we are not forcing the client to implement IOracleDataProvider 
    public int ExecuteSqlCommand() 
    { 
        Console.WriteLine("Sql Server specific Command Executed successfully"); 
        return 1; 
    } 
} 
// Client 2 
// Should not force OracleDataProvider client to implement ExecuteSqlCommand, as it wont required that method to be implemented. 
// So that we will derive IOracleDataProvider not ISqlDataProvider 
class OracleDataClient : IOracleDataProvider 
{ 
    public int OpenConnection() 
    { 
        Console.WriteLine("\nOracle Connection opened successfully"); 
        return 1; 
    } 
    public int CloseConnection() 
    { 
        Console.WriteLine("Oracle Connection closed successfully"); 
        return 1; 
    } 
    // Implemeting IOracleDataProvider, we are not forcing the client to implement ISqlDataProvider 
    public int ExecuteOracleCommand() 
    { 
        Console.WriteLine("Oracle specific Command Executed successfully"); 
        return 1; 
    } 
} 
class InterfaceSegregationPrincipleDemo 
{ 
    public static void ISPDemo() 
    { 
        Console.WriteLine("\n\nInterface Inversion Principle Demo "); 
 
        // Each client will implement their respective methods no base class forces the other client to implement the methods which dont required. 
        // From the above implementation, we are not forcing Sql client to implemnt orcale logic or Oracle client to implement sql logic. 
 
        ISqlDataProvider SqlDataProviderObject = new SqlDataClient(); 
        SqlDataProviderObject.OpenConnection(); 
        SqlDataProviderObject.ExecuteSqlCommand(); 
        SqlDataProviderObject.CloseConnection(); 
 
        IOracleDataProvider OracleDataProviderObject = new OracleDataClient(); 
        OracleDataProviderObject.OpenConnection(); 
        OracleDataProviderObject.ExecuteOracleCommand(); 
        OracleDataProviderObject.CloseConnection(); 
    } 
}

Dependency Inversion Principle:

A: High level modules should not depend upon low level modules. Both should depend upon abstractions.

B: Abstractions should not depend upon details. Details should depend upon abstractions.

By passing dependencies to classes as abstractions, you remove the need to program dependency specific. 

Also referred as IoC Inversion of Control principle and implements as DI Dependency Injection Pattern in programming world.

E.g:

An Employee class that needs to be able to save to XML and a database.

Problem 1:

If we placed ToXML() and ToDB() functions in the class, we'd be violating the single responsibility principle.

Problem 2:

If we created a function that took a value that represented whether to print to XML or to DB, we'd be hard-coding a set of devices and thus be violating the open closed principle.

Solution:

1. Create an abstract class named 'DataWriter' that can be inherited from 'XMLDataWriter' and 'DbDataWriter'.

2. Then Create a class named 'EmployeeWriter' that would expose an Output 'DataWriter saveMethod' that accepts a dependency as an argument.

See how the Output method is dependent upon the abstractions just as the output types are?

The dependencies have been inverted.

Now we can create new types of ways for Employee data to be written, perhaps via HTTP/HTTPS by creating abstractions, and without modifying any of our previous code!

Read more about Inversion of Control (IoC) with Dependency Injection (DI) Pattern here

http://code.msdn.microsoft.com/Dependency-Injection-with-5702acaf

http://www.codeproject.com/Articles/872007/Dependency-Inversion-Principle-What-you-always-kne  
http://www.aspnphp.com/inversion-of-control-ioc/#

Example:

C#

using System; 
using System.Collections.Generic; 
using System.Linq; 
using System.Text; 
 
namespace SOLIDPrinciplesDemo 
{ 
//DIP Violation 
// Low level Class 
public class BankAccount 
{ 
    public string AccountNumber { get; set; } 
    public decimal Balance { get; set; } 
         
    public void AddFunds(decimal value) 
    { 
        Balance += value; 
    } 
    public void RemoveFunds(decimal value) 
    { 
        Balance -= value; 
    } 
} 
// High level Class 
public class TransferAmount 
{ 
    public BankAccount Source { get; set; } 
    public BankAccount Destination { get; set; } 
    public decimal Value { get; set; } 
 
    public void Transfer() 
    { 
        Source.RemoveFunds(Value); 
        Destination.AddFunds(Value); 
    } 
} 
/*  
Problem with above design: 
  
1. The high level TransferAmount class is directly dependent upon the lower level BankAccount class i.e. Tight coupling. 
2. The Source and Destination properties reference the BankAccount type.So impossible to substitute other account types unless they are subclasses of BankAccount.  
3. Later we want to add the ability to transfer money from a bank account to pay bills, the BillAccount class would have to inherit from BankAccount.  
 As bills would not support the removal of funds,  
 3.A. This is likely to break the rules of the Liskov Substitution Principle (LSP) or  
 3.B. Require changes to the TransferAmount class that do not comply with the Open/Closed Principle (OCP). 
  
4. Any extension functionality changes be required to low level modules.  
 4.A. Change in the BankAccount class may break the TransferAmount.  
 4.B. In complex scenarios, changes to low level classes can cause problems that cascade upwards through the hierarchy of modules.  
5. As the software grows, this structural problem can be compounded and the software can become fragile or rigid. 
6. Without the DIP, only the lowest level classes may be easily reusable. 
7. Unit testing should be redone when there is a change in high level or low level classes. 
8. Time taken process to change the existing functionality and extending the functionality 
*/  
 
//Applying DIP resolves these problems by removing direct dependencies between classes.  
public interface ITransferSource 
{ 
    long AccountNumber { get; set; } 
    decimal Balance { get; set; } 
    void RemoveFunds(decimal value); 
} 
public interface ITransferDestination 
{ 
    long AccountNumber { get; set; } 
    decimal Balance { get; set; } 
    void AddFunds(decimal value); 
} 
public class BOABankAccount : ITransferSource, ITransferDestination 
{ 
    public long AccountNumber { get; set; } 
    public decimal Balance { get; set; } 
 
    public void AddFunds(decimal value) 
    { 
        Balance += value; 
    } 
    public void RemoveFunds(decimal value) 
    { 
        Balance -= value; 
    } 
} 
public class TransferAmounts 
{ 
    public decimal Amount { get; set; } 
    public void Transfer(ITransferSource TransferSource, ITransferDestination TransferDestination) 
    {             
        TransferSource.RemoveFunds(Amount); 
        TransferDestination.AddFunds(Amount); 
    } 
}     
/* 
Advantage in above example after applying DIP: 
 
1. Higher level classes refer to their dependencies using abstractions, such as interfaces or abstract classes i.e. loose coupling.  
2. Lower level classes implement the interfaces, or inherit from the abstract classes. 
3. This allows new dependencies can be substituted without any impact.  
4. Lower levels classes will not cascade upwards as long as they do not involve changing the abstraction. 
5. Increases the robustness of the software and improves flexibility.  
6. Separation of high level classes from their dependencies raises the possibility of reuse of these larger areas of functionality.  
7. Minimized risk to affect old funtionallity present in Higher level classes. 
8. Testing applies only for  newly added low level classes. 
9. Though using this principle implies an increased effort and a more complex code, but it is more flexible.  
  
Note: 
In that case the creation of new low level objects inside the high level classes(if necessary) can not be done using the operator new.  
Instead, some of the Creational design patterns can be used, such as Factory Method, Abstract Factory, Prototype. 
 
The Template Design Pattern is an example where the DIP principle is applied.    
   
This principle cannot be applied for every class or every module.  
If we have a class functionality that is more likely to remain unchanged in the future there is not need to apply this principle. 
*/ 
class DependencyInversionPrincipleDemo 
{ 
    public static void DIPDemo() 
    { 
            Console.WriteLine("\n\nDependency Inversion Principle Demo "); 
 
        //Created abstract class/interfaces objects for low level classes. 
        ITransferSource TransferSource = new BOABankAccount(); 
        TransferSource.AccountNumber = 123456789; 
        TransferSource.Balance = 1000; 
        Console.WriteLine("Balance in Source Account : " + TransferSource.AccountNumber + " Amount " + TransferSource.Balance);  
 
        ITransferDestination TransferDestination = new BOABankAccount(); 
        TransferDestination.AccountNumber = 987654321; 
        TransferDestination.Balance = 0; 
        Console.WriteLine("Balance in Destination Account : " + TransferDestination.AccountNumber + " Amount " + TransferDestination.Balance); 
             
             
        TransferAmounts TransferAmountsObject = new TransferAmounts(); 
        TransferAmountsObject.Amount = 100; 
 
        // High level class using abstract class/interface objects  
        TransferAmountsObject.Transfer(TransferSource, TransferDestination); 
        Console.WriteLine("Transaction successful"); 
 
        Console.WriteLine("Balance in Source Account : " + TransferSource.AccountNumber + " Amount " + TransferSource.Balance); 
        Console.WriteLine("Balance in Destination Account : " + TransferDestination.AccountNumber + " Amount " + TransferDestination.Balance); 
    } 
}

I have explained each principle in detail with example in the sample. Download the sample and go through the code with comments.

Open/Close Principle

                                        LiskovSubstitutionPrinciple

http://code.msdn.microsoft.com/silverlight/OOPS-Principles-SOLID-7a4e69bf

http://www.codeproject.com/Articles/703634/SOLID-architecture-principles-using-simple-Csharp

LSP

namespace LiscovSubstitution

{

    class Program

    {

        static void Main(string[] args)

        {

            //In book at page: 141

            Area sq = new Square();

            Area rect = new Rectangle();

            sq.Height = 7;

            sq.Width = 3;

            rect.Height = 7;

            rect.Width = 3;

            Console.Write("Square :");

            Console.WriteLine(sq.Areas()); ;

            Console.Write("Rectangle :");

            Console.WriteLine(rect.Areas());

            Console.ReadKey();

        }

    }

}

namespace LiscovSubstitution

{

    public class Square:Area

    {

        public override int Height

        {

            get

            {

                return base.Height;

            }

            set

            {

                CalculateArea(value);

            }

        }

        public override int Width

        {

            get

            {

                return base.Width;

            }

            set

            {

                CalculateArea(value);

            }

        }

        public void CalculateArea(int value)

        {

            base.Height = value;

            base.Width = value;

        }

    }

}

namespace LiscovSubstitution

{

    public class Area

    {

        public virtual int Height { get; set; }

        public virtual int Width { get; set; }

        public int Areas()

        {

            return Height * Width;

        }

    }

}

 namespace LiscovSubstitution

{

    //Here Base class is the area

    //The derived class is Rectangle

    public class Rectangle:Area

    {

        public override int Height

        {

            get

            {

                return base.Height;

            }

            set

            {

                base.Height = value;

            }

        }

        public override int Width

        {

            get

            {

                return base.Width;

            }

            set

            {

                base.Width = value;

            }

        }

    }

}
********************************Another LSP Ex************************
namespace LiscovSubstitution
{
   public abstract class Shape
    {
       public abstract int Area();
    }

   public class Rectangle2 : Shape
   {
       public virtual int Height { get; set; }
       public virtual int Width { get; set; }
       public override int Area()
       {
           return Height * Width;
       }
   }
   public class Square2 : Shape
   {
       public int SideLength;

       public override int Area()
       {
           return SideLength * SideLength;
       }
   }

}

namespace LiscovSubstitution
{
    class Program
    {
        static void Main(string[] args)
        {          
            Show();
            Console.ReadKey();
        }

        static void Show()    
        {
            var shapes = new List<Shape>
                        {
                            new Rectangle2{Height=3,Width=7},
                             new Square2{SideLength=3},

                        };
            var areas = new List<int>();
            foreach (Shape shape in shapes)
            {
                areas.Add(shape.Area());
            }
            Console.Write("Rectangle :");
            Console.WriteLine(areas[0]);
            Console.Write("Square :");
            Console.WriteLine(areas[1]);            
        }
    }

}
**************************************************************************