When to Use Delegates Instead of Interfaces?

Both delegates and interfaces allow 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 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 with 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 they use an interface?
Use a delegate when:

• An eventing design pattern is used.
• It is desirable to encapsulate a static method.
• The caller has no need 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 when:

• There are 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.

One good example of using a single-method interface instead of a delegate is IComparable or IComparable. IComparable declares the CompareTo method, which returns an integer specifying a less than, equal to, or greater than relationship between two objects of the same type. IComparable can be used as the basis of a sort algorithm, and while using a delegate comparison method as the basis of a sort algorithm would be valid, it is not ideal. Because the ability to compare belongs to the class, and the comparison algorithm doesn’t change at run-time, a single-method interface is ideal.

 

What is Delegate?

 Delegate is a simple class that is used to point to methods with a specific signature, becoming essentially a type-safe function pointer. A delegate's purpose is to facilitate a call back to another method  (or methods), after one has been completed, in a structured way
Delegate is a type which  holds the method(s) reference in an object. It is also referred to as a type safe function pointer.

Advantages

• Encapsulating the method's call from caller
• Effective use of delegate improves the performance of application
• Used to call a method asynchronously

Declaration
Creating a delegate is easy to do. Identify the class as a delegate with the "delegate" keyword. Then specify the signature of the type.

public delegate type_of_delegate delegate_name()
Example.
public delegate double Integrand(double x);

public delegate double Delegate_Prod(int a,int b);
class ClassDel
{
    static double fn_Prodvalues(int val1,int val2)
    {
        return val1*val2;
} static void Main(string[] args) {   
        Delegate_Prod delObj = new Delegate_Prod(fn_Prodvalues);
        Console.Write("Please Enter Values");
        int v1 = Int32.Parse(Console.ReadLine());
        int v2 = Int32.Parse(Console.ReadLine());
        //use a delegate for processing        double res = delObj(v1,v2);
        Console.WriteLine ("Result :"+res);
        Console.ReadLine();
    }
}

.

What is Multicast Delegate?

It is a delegate which holds the reference of more than one method.

Multicast delegates must contain only methods that return void, else there is a run-time exception.

 

delegate void Delegate_Multicast(int x, int y);

Class Class2

{

    static void Method1(int x, int y)

    {

        Console.WriteLine("You r in Method 1");

    }

 

    static void Method2(int x, int y)

    {

        Console.WriteLine("You r in Method 2");

    }

 

    public static void <place w:st="on" />Main</place />()

    {

        Delegate_Multicast func = new Delegate_Multicast(Method1);

        func += new Delegate_Multicast(Method2);

        func(1,2);             // Method1 and Method2 are called

        func -= new Delegate_Multicast(Method1);

        func(2,3);             // Only Method2 is called

    }

}

 

 

Where use delegate?

 

• Event handlers (for GUI and more like Menu)
• Starting threads(like progress bar)
• Callbacks (e.g. for async APIs)
• LINQ and similar (List.Find etc)
• Anywhere else where I want to effectively apply "template" code with some specialized logic inside (where the delegate provides the specialization)
• Event Handling
• Multi Casting
• Filtering

How to build a positive attitude

Positive attitude keeps us in positive state of mind. It is easier to dust off past failures and get back to the present with such an attitude. A person with negative attitude often plays blame game and never accepts responsibilities. This restricts life and success at work will be limited too. Fewer friends, lesser enjoyment and limited relationships become the part of life of a person with such a fatalistic and erratic attitude. Good news is that one can cultivate a few traits to develop a positive attitude. Traits to build a positive attitude: Focus on Positive aspect We always look for faults and forget to see positive vibes. If we condition our mind to read positive things, we are bound to have positive personality. Remember, in goldmines, people focus on Gold and not on dirt and dust that comes out while digging. If you focus on negative, you spread negative messages and create environment conducive to negative results. Avoid procrastination Cultivate the habit of living in the present and doing it now. A completed task is fulfilling and energizing and an incomplete task drains energy. Most of us have the habit of dragging and postponing things, consequently we always find our selves in planning and analyzing mode and actual action never takes place. Focus on virtues Focus on knowledge and wisdom and not on grades. Educating the mind and not developing moral create menace in the society. Wealth without character and conscience is a waste. If you are not trustworthy, you have no credibility. Trust is a capital, once lost very difficult to regain. Commonsense Apart from 5 god gifted senses, we have a sixth sense – commonsense, that we develop over the time. It is the sense that enables us to take right decision at the right time. If you lack commonsense, it is useless how strong your other senses are. I have seen many walking encyclopedia and living failure simply for lack commonsense. High Self-Esteem Self-Esteem is the way we feel about ourselves. Self-Esteem is the feeling of gratification that has nothing to do with success and winning. When you do something for others, you feel good, you are at you best and your self esteem gets a big boost. No matter how rich or poor you are, a person with high self esteem definitely touches high goals in life. Avoid negative influences We are born achievers and winners. It is the negative influences and environment that conditions our mind to be a loser. We all are impressionable to varying degree and thus required stay in the company of well motivated people. Learn to like the task Never hate your work, perform with utmost passion, result is guaranteed. When I asked a mother that how she could manage to take care 3 demanding kids. She said that it was a job she loved. Practice having positive thoughts and behavior daily Just as you feed your body with food everyday, treat you mind with positive thoughts everyday. Our mind is most receptive in the morning. Repeating healthy thoughts in the morning conditions your mind to be positive and ultimately becomes your habit. Success and positive thoughts go hand in hand.

Types of SDLC

1.Water fall

2.Spiral

3.Rapid Prototype

4.Iterative

5.Incrementals.

 

What is SDLC?

The General Model
Software life cycle models describe phases of the software cycle and
the order in which those phases are executed. There are tons of
models, and many companies adopt their own, but all have very similar
patterns. The general, basic model is shown below:
Each phase produces deliverables required by the next phase in the
life cycle. Requirements are translated into design. Code
is produced during implementation that is driven by the design.
Testing verifies the deliverable of the implementation phase against
requirements.
Requirements
Business requirements are gathered in this phase. This phase
is the main focus of the project managers and stake holders.
Meetings with managers, stake holders and users are held in order to
determine the requirements. Who is going to use the system?
How will they use the system? What data should be input into the
system? What data should be output by the system? These are
general questions that get answered during a requirements gathering
phase. This produces a nice big list of functionality that the
system should provide, which describes functions the system should
perform, business logic that processes data, what data is stored and
used by the system, and how the user interface should work. The
overall result is the system as a whole and how it performs, not how it
is actually going to do it.
Design
The software system design is produced from the results of the
requirements phase. Architects have the ball in their court
during this phase and this is the phase in which their focus
lies. This is where the details on how the system will work is
produced. Architecture, including hardware and software,
communication, software design (UML is produced here) are all part of
the deliverables of a design phase.
Implementation
Code is produced from the deliverables of the design phase during
implementation, and this is the longest phase of the software
development life cycle. For a developer, this is the main focus
of the life cycle because this is where the code is produced.
Implementation my overlap with both the design and testing
phases. Many tools exists (CASE tools) to actually automate the
production of code using information gathered and produced during the
design phase.
Testing
During testing, the implementation is tested against the
requirements to make sure that the product is actually solving the
needs addressed and gathered during the requirements phase. Unit
tests and system/acceptance tests are done during this phase.
Unit tests act on a specific component of the system, while system
tests act on the system as a whole.
So in a nutshell, that is a very basic overview of the general
software development life cycle model. Now lets delve into some
of the traditional and widely used variations.

 

What is the Waterfall Model?

The waterfall model is a sequential software development model in which development is seen as flowing steadily downwards (like a waterfall) through several phases. History of the Waterfall Model In 1970 Royce proposed what is now popularly referred to as the waterfall model as an initial concept, a model which he argued was flawed (Royce 1970). His paper then explored how the initial model could be developed into an iterative model, with feedback from each phase influencing previous phases, similar to many methods used widely and highly regarded by many today. Despite Royce's intentions for the waterfall model to be modified into an iterative model, use of the "waterfall model" as a purely sequential process is still popular, and, for some, the phrase "waterfall model" has since come to refer to any approach to software creation which is seen as inflexible and non-iterative. Usage of the waterfall model In Royce's original waterfall model, the following phases are followed perfectly in sequential order: Requirements specification Requirements are captured and set in stone. Design A "blueprint" is drawn up for the developers to implement. Implementation Integration Testing Installation Maintenance The waterfall model maintains that one should move to a phase only when its preceding phase is completed and perfected. Phases of development in the waterfall model are thus discrete, and there is no jumping back and forth or overlap between them. As many find this approach particularly rigid, modifications have been made over the years and new variants of the model have emerged. Criticism of the waterfall model The waterfall model however is argued by many to be a bad idea in practice, mainly because of their belief that it is impossible to get one phase of a software product's lifecycle "perfected" before moving on to the next phases and learning from them. A typical problem is when requirements change midway through, resulting in a lot of time and effort being invalidated due to the "Big Design Up Front". In summary, the criticisms of a non-iterative development approach (such as the waterfall model) are as follows: Poor flexibility; the majority of software is written as part of a contract with a client, and clients are notorious for changing their stated requirements. Thus the software project must be adaptable, and spending considerable effort in design and implementation based on the idea that requirements will never change is neither adaptable nor realistic in these cases. Unless those who specify requirements and those who design the software system in question are highly competent, it is difficult to know exactly what is needed in each phase of the software process before some time is spent in the phase "following" it. Constant testing from the design, implementation and verification phases is required to validate the phases preceding them. Users of the waterfall model may argue that if designers follow a disciplined process and do not make mistakes that there is no need to constantly validate the preceding phases. Frequent incremental builds (following the "release early, release often" philosophy) are often needed to build confidence for a software production team and their client. It is difficult to estimate time and cost for each phase of the development process. The waterfall model brings no formal means of exercising management control over a project and planning control and risk management are not covered within the model itself. Only a certain number of team members will be qualified for each phase, which can lead at times to some team members being inactive.

Advantages of Waterfall Model

Advantages of Waterfall Iterative Model

1) Waterfall model is simple to implement and also the amount of resources required for it are minimal.

2) In this model, output is generated after each stage (as seen before), therefore it has high visibility. The client and project manager gets a feel that there is considerable progress. Here it is important to note that in any project psychological factors also play an important role.

3) Project management, both at internal level and client's level, is easy again because of visible outputs after each phase. Deadlines can be set for the completion of each phase and evaluation can be done from time to time, to check if project is going as per milestones.

4) This methodology is significantly better than the haphazard approach to develop software. It provides a template into which methods of analysis, design, coding, testing and maintenance can be placed.

5) This methodology is preferred in projects where quality is more important as compared to schedule or cost.

Disadvantages of Waterfall Iterative Model of SDLC

1) Real projects rarely follow the sequential flow and iterations in this model are handled indirectly. These changes can cause confusion as the project proceeds.

2) It is often difficult to get customer requirements explicitly. Thus specifications can't be freezed. If that case arises baseline approach is followed, wherein output of one phase is carried forward to next phase. For example, even if SRS is not well defined and requirements can't be freezed, still design starts. Now if any changes are made in SRS then formal procedure is followed to put those changes in baseline document.

3) In this model we freeze software and hardware. But as technology changes at a rapid pace,such freezing is not advisable especially in long-term projects.

4) This method is especially bad in case client is not IT-literate as getting specifications from such a person is tough.

5) Even a small change in any previous stage can cause big problem for subsequent phases as all phases are dependent on each-other.

6) Going back a phase or two can be a costly affair.

Projects where Waterfall Method is suitable for SDLC:-

1) In development of database-related software, eg commercial projects.
2) In development of E-commerce website or portal.
3) In Development of network protocol software.

Simple Wcf Interview Quetion

What are the important principles of SOA (Service oriented Architecture)?


What are ends, contract, address, and bindings?


Which specifications does WCF follow?


What are the main components of WCF?


Explain how Ends, Contract, Address, and Bindings are done in WCF?


What is a service class?


What is a service contract, operation contract and Data Contract?


What are the various ways of hosting a WCF service?


How do we host a WCF service in IIS?


What are the advantages of hosting WCF Services in IIS as compared to self-hosting?


What are the major differences between services and Web services?


What is the difference WCF and Web services?


What are different bindings supported by WCF?


Which are the various programming approaches for WCF?


What is one-way operation?


Can you explain duplex contracts in WCF?


How can we host a service on two different protocols on a single server?


How can we use MSMQ bindings in WCF?


Can you explain transactions in WCF?


What different transaction isolation levels provided in WCF?


Can we do transactions using MSMQ?


Can we have two-way communications in MSMQ?


What are Volatile queues?


What are Dead letter queues?


What is a poison message?

Design Patterns

Definition:
Design Patterns represent solutions to problems which arise when developing a software within a particular context.

Types of Design Patterns
There are three types of design patterns
1. Creational Patterns: Creational Patterns deals with initializing and configuring classes and objects
2. Structural Patterns: Structural Patterns deals with decoupling the interface and implementation of classes and objects
3. Behavioral Patterns: Behavioral Patterns deals with dynamic interactions among societies of classes and objects

These three design patters are divided in to 22 different kinds of patterns as shown below.

 

WCF Contarcts

 A contract is a agreement between two or more parties for common understanding and it is a is a platform-neutral and standard way of describing what the service does. In WCF, all services expose contracts.
1) Operation Contract: An operation contract defines the parameters and return type of an operation.

[OperationContract] double Add(double i, double j);

2) Service Contract: Ties together multiple related operations contracts into a single functional unit. [ServiceContract] //System.ServiceModel public interface IMath { [OperationContract] double Add(double i, double j); [OperationContract] double Sub(double i, double j); [OperationContract] Complex AddComplexNo(Complex i, Complex j); [OperationContract] Complex SubComplexNo(Complex i, Complex j); } 3) Data Contract: The descriptions in metadata of the data types that a service uses. [DataContract] //using System.Runtime.Serialization public class Complex { private int real; private int imaginary; [DataMember] public int Real { get; set; } [DataMember] public int Imaginary { get; set; } }

Basics of WCF

Definition of WCF
Windows Communication Foundation (WCF) is a framework for building service-oriented applications. Using WCF we can build secure, reliable, transacted solutions that integrate across platforms.

WCF is a unified framework which provides :
1. NET Remoting 2.Distributed Transactions 3.Message Queues and 4.Web Services into a single service-oriented programming model for distributed computing.
WCF interoperate between WCF-based applications and any other processes that communicate via SOAP (Simple Object Access Protocol) messages

Features of WCF

1. Service Orientation
2. Interoperability
3. Multiple Message Patterns
4. Service Metadata
5. Data Contracts
6. Security
7. Multiple Transports and Encodings
8. Reliable and Queued Messages
9. Durable Messages
10. Transactions
11. AJAX and REST Support
12. Extensibility

Terms of WCF

A WCF service is exposed to the outside world as a collection of endpoints.

1. Endpoint: Endpoint is a construct at which messages are sent or received (or both). Endpoint comprises of ABC’s

What are ABC’s of WCF ?

A. Address - Address is a location that defines where messages can be sent

B. Binding - Binding is a specification of the communication mechanism (a binding) that described how messages should be sent

C. Contract - Contract is a definition for a set of messages that can be sent or received (or both) at that location (a service contract) that describes what message can be sent.

2. Service: A construct that exposes one or more endpoints, with each endpoint exposing one or more service operations.

3. Contracts: A contract is a agreement between two or more parties for common understanding and it is a is a platform-neutral and standard way of describing what the service does. In WCF, all services expose contracts.

Types of Contracts:
1) Operation Contract: An operation contract defines the parameters and return type of an operation.
2) Service Contract: Ties together multiple related operations contracts into a single functional unit.
3) Data Contract: The descriptions in metadata of the data types that a service uses