.Net(C#) Programming Tips

1. Virtual vs Abstract

Virtual methods allow subclasses to provide their own implementation of that method using the override keyword. A virtual method can be part of any class and needs to have body. A class with only virtual (or) non_virtual methods can be instantiated.

Abstract methods in a class contain no method body, and are implicitly virtual.If a class has any abstact methods, then it must tag itself as abstract, and no instances of it can be created.

Neither abstract or virtual can be declared private, since it would defeat the purpose, and subclasses must override them using the same method signature and "override" keyword.

2. Abstract Classe vs Interface

An abstract base class is needed in a different situation. Some times you can write most of the implementation of a class but not all of it. perhaps you have some classes that have a lot in common, and could really use a parent class, but some of the methods and/or properties don't generalize well. Let’s take the example of Image. There are lots of different kinds of images: bit maps, jpegs, gifs, tiffs, etc. You want all of those kinds of images to have (mostly) the same methods and properties, for example you want them all to have a RotateFlip() method to allow the caller to rotate the image, but you can't write a meaningful implementation for that method until you know what kind of image you're dealing with.

You need an interface if you want to assign common behaviour to various classes that do not derive from the same base class (other than Object). The excellent example of IEnumerable: you want to be able to make many classes from all over the class hierarchy enumerable, and in some methods treat them as "the same" for purposes of enumeration, even though they're otherwise completely different classes that have nothing in common. If you create an abstract class with no method implementation and no data members it is pretty much the same as defining an interface.

In general there are a number of differences.

1. In abstract classes you can have data members to keep, for instance, internal state

2. In abstract classes you can provide implementation for a method:

say you have a Vehicle abstract class, you can derive Bike, MotorCycle and Car from that, but you might want to define a method GetCC() in the base class that will never change (no can do with interfaces)

3. C# object can implement as many interface you want but can just inherit from one class.

4. An abstract class can have constructor declaration while an interface can not do so.

5. An abstract Class is allowed to have all access modifiers for all of its member declaration while in interface we can not declare any access modifier(including public) as all the members of interface are implicitly public.

ref:

http://bytes.com/topic/c-sharp/answers/259751-confuesd-about-abstract-class-vs-interface

http://www.c-sharpcorner.com/UploadFile/prasoonk/AbstractClassvsInterface06102009051117AM/AbstractClassvsInterface.aspx

3. Delegate vs Interface

Both delegates and interfaces enable a class designer to separate type declarations and implementation. A given interface can be inherited and implemented by any class or struct. A delegate can be created for a method on any class, as long as the method fits the method signature for the delegate. An interface reference or a delegate can be used by an object that has no knowledge of the class that implements the interface or delegate method. Given these similarities, when should a class designer use a delegate and when should it use an interface?

Use a delegate in the following circumstances:

· An eventing design pattern is used.

· It is desirable to encapsulate a static method.

· The caller has no need to access other properties, methods, or interfaces on the object implementing the method.

· Easy composition is desired.

· A class may need more than one implementation of the method.

Use an interface in the following circumstances:

· There is a group of related methods that may be called.

· A class only needs one implementation of the method.

· The class using the interface will want to cast that interface to other interface or class types.

· The method being implemented is linked to the type or identity of the class: for example, comparison methods.

ref:

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

4. XAML Compilation: BAML

The creators of WPF knew that XAML needed to not just solve the problem of design collaboration - it also needed to be fast. And though XML-based formats such as XAML are flexible and easily portable to other tools and platforms, they aren’t always the most efficient option. XML was designed to be logical, readable, and straightforward - not compact.

WPF addresses this shortcoming with BAML (Binary Application Markup Language). BAML is really nothing more than a binary representation of XAML. When you compile a WPF application in Visual Studio, all your XAML files are converted into BAML and that BAML is then embedded as a resource into the final DLL or EXE assembly. BAML is tokenized, which means lengthier bits of XAML are replaced with shorter tokens. Not only is BAML significantly smaller, it’s also optimized in a way that makes it faster to parse at runtime.

5. WPF and XAML

XAML and WPF are separate, albeit complementary, technologies. As a result, it’s quite possible to create a WPF application that doesn’t use the faintest bit of XAML.

Altogether, there are three distinct coding styles that you can use to create a WPF application:

1. Code-only - This is the traditional approach used in Visual Studio for Windows Forms applications. It generates a user interface through code statements.

2. Code and uncompiled markup (XAML) - This is a specialized approach that makes sense in certain scenarios where you need highly dynamic user interfaces. You load part of the user interface from a XAML file at runtime using the XamlReader class from the System.Windows.Markup namespace.

3. Code and compiled markup (BAML) - This is the preferred approach for WPF, and the one that Visual Studio supports. You create a XAML template for each window and this XAML is compiled into BAML and embedded in the final assembly. At runtime the compiled BAML is extracted and used to regenerate the user interface.

6. ThreadPool.QueueUserWorkItem vs Delegate.BeginInvoke

Both Delegate.BeginInvoke and ThreadPool.QueueUserWorkItem will execute on a thread pool thread.

The difference is that if you call BeginInvoke, you're obliged to call EndInvoke at some point. In contrast, ThreadPool.QueueUserWorkItem is "fire and forget". That has benefits and drawbacks. The benefit being that you can forget about it. The drawback being that you have no way of knowing, unless you add your own synchronization/notification mechanism, when the task has completed.

ref :

http://en.csharp-online.net/XAML—XAML_Compilation

7. Automated White Box Testing for .NET with Pex

Pex (Program EXploration) produces a traditional unit test suite with high code coverage. A parameterized unit test is simply a method that takes parameters, calls the code under test, and states assertions. Given a parameterized unit test written in a .NET language, Pex automatically produces a small unit test suite with high code and assertion coverage. To do so, Pex performs a systematic white box program analysis.

Pex learns the program behavior by monitoring execution traces, and uses a constraint solver to produce new test cases with different behavior. At Microsoft, this technique has proven highly effective in testing even an extremely well-tested component. Pex is now capable of producing NUnit and MSUnit tests.

ref :

http://research.microsoft.com/en-us/projects/Pex/

8. Moles - Detours for .NET

Moles is an extension of the Stubs framework to detour any .net methods i.e. any static, non-virtual method even in sealed types.To illustrate the moles, we will write a unit test involving DateTime.Now. Traditionally, any code relying on DateTime.Now would be hard to unit test because of the dependency on the machine clock.

ref :

http://research.microsoft.com/en-us/projects/stubs/moles.aspx