Tuples in Dotnet 4.0

A tuple is a data structure that has a specific number and sequence of elements. An example of a tuple is a data structure with three elements (known as a 3-tuple or triple) that is used to store an identifier such as a person's name in the first element, a last name in the second element, and the person's age in the third element. The .NET Framework directly supports tuples with one to seven elements. In addition, you can create tuples of eight or more elements by nesting tuple objects in the Rest property of a Tuple<T1, T2, T3, T4, T5, T6, T7, TRest> object.

Tuples are commonly used in four ways:

• To provide easy access to, and manipulation of, a data set.
• To represent a single set of data. For example, a tuple can represent a database record, and its components can represent individual fields of the record.
• To pass multiple values to a method through a single parameter. For example, the Thread.Start(Object) method has a single parameter that lets you supply one value to the method that the thread executes at startup time. If you supply a Tuple<T1, T2, T3> object as the method argument, you can supply the thread’s startup routine with three items of data.
• To return multiple values from a method without using out parameters (in C#) or ByRef parameters (in Visual Basic).

The Tuple class does not itself represent a tuple. Instead, it is a factory class that provides static methods for creating instances of the tuple types that are supported by the .NET Framework. It provides helper methods that you can call to instantiate tuple objects without having to explicitly specify the type of each tuple component.

Let’s see how to use Tuple,

//Creating Tuple using constructor

Tuple<string, string, int> t1 = new Tuple<string, string, int>("Kalpesh","Patolia", 27);

//Creating Tuple using static method

Tuple<string, string, int> t1 = Tuple.Create("Kalpesh", "Patolia", 27);

Console.WriteLine(t1.Item1); // Output - "Kalpesh"

Console.WriteLine(t1.Item2); // Output - "Patolia"

Console.WriteLine(t1.Item3); // Output - 27

Each item in Tuple is statically typed so while using those items don’t need to cast. So instead of using object array and doing boxing and unboxing you can easily use Tuple in that scenario.

For more information refer the MSDN http://msdn.microsoft.com/en-us/library/system.tuple.aspx

S.O.L.I.D. Principles in Object Oriented Programming

Single Responsibility Principle (SRP)

It states that every object should have a single responsibility, and that responsibility should be entirely encapsulated by the class. There should not be more than one reason to change the class. This means class should be designed for one purpose only. This principle states that if we have 2 reasons to change for a class, we have to split the functionality in two classes. Each class will handle only one responsibility and on future if we need to make one change we are going to make it in the class which handles it. When we need to make a change in a class having more responsibilities the change might affect the other functionality of the classes.

Example- Sales Order class: This class is using for CRUD functionality of Sales Order, and then it should not have any method to MAP Sales Order attributes with Database columns, because later if there is any new column added in Database  the class need to be modified which is violating the rule of Single Responsibility Principle.

Open/Close Principle (OCP)

It states that Class should be open for extension, but close for modification. At first, this seems to be contradictory: how can you make an object behave differently without modifying it? The answer: by using abstractions, or by placing behavior (responsibility) in derivative classes. In other words, by creating base classes with override-able functions, we are able to create new classes that do the same thing differently without changing the base functionality. 

Liskov Substitution Principle (LSP) 

Basically when we designed a class, we use maintain Class hierarchies. We must make sure that the new derived classes just extend without replacing the functionality of old classes. Otherwise the new classes can produce undesired effects when they are used in existing program modules.
LSV states that if the module using any base class, then the reference to the Base class can be replaced with a Derived class without affecting the functionality of the program module. 

Example: - A typical example that violates LSP is a Square class that derives from a Rectangle class, assuming getter and setter methods exist for both width and height. The Square class always assumes that the width is equal with the height. If a Square object is used in a context where a Rectangle is expected, unexpected behavior may occur because the dimensions of a Square cannot (or rather should not) be modified independently. This problem cannot be easily fixed: if we can modify the setter methods in the Square class so that they preserve the Square invariant (i.e. keep the dimensions equal), then these methods will weaken (violate) the post conditions for the Rectangle setters, which state that dimensions can be modified independently. If Square and Rectangle had only getter methods (i.e. they were immutable objects), then no violation of LSP could occur.

Interface Segregation Principle (ISP)

It states avoid tying a client class to a big interface if only a subset of this interface is really needed. Many times you see an interface which has lots of methods. This is a bad design choice since probably a class implementing. . This can make it harder to understand the purpose of a component, but it can also cause increase coupling, where by components that make use of such a component are exposed to more of that components capabilities that are appropriate.
The Interface Segregation Principle (or ISP) aims to tackle this problem by breaking a components interface into functionally separate sub-interfaces. Although a component may still end up with the same set of public members, those members will be separated into separate interfaces such that a calling component can operate on the component by referring only to the interface that concerns the calling component. 

Dependency Inversion Principle (DIP)

In an application we have low level classes which implement basic and primary operations and high level classes which encapsulate complex logic and rely on the low level classes. A natural way of implementing such structures would be to write low level classes and once we have them to write the complex high level classes. Since the high level classes are defined in terms of others this seems the logical way to do it. But this is not a flexible design. High-level modules should not depend on low-level modules. Both should depend on abstractions. Abstractions should not depend on details. Details should depend on abstractions.