Skip to content

EzDevPrac/CSharp_Karan

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

76 Commits
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

C-Sharp Project Karan

Build Status

Web API

API is some kind of interface which has a set of funtions that allows programmers to acess specific features or data of an application,OS or other services. or we can also say it as a set of subroutine defination , protocols and tools for building software and application.

Web API is an API over the web which can be accessed using HTTP protocol.

Model : Set of classes that represents the data that the application manages.

REST API's

  1. Representational state transfer Application Progrgramming Interface.
  2. API that uses http request to GET/PUT/POST/DELETE etc .
  3. REST technology is generally preferred over the Simple object Access Protocol(SOAP),it uses less bandwidth.
  4. Its Stateless( i.e there is nomrecord of the previous interaction and each interaction request has to be handled based entirely on the information that comes with it ).
  5. SOAP: Developer handwrite the XML document with Remote Procedure Call(RPC) in the body.They than specify the end point and post their SOAP envelop the endpoint.
  6. Rest API tend to deliver JSON or XML data.

Some of the main HTTP Methods of the RESt API

  1. GET : Get all the required data(GET/API/ToDOItem or GET/API/ToDoItem/{Id}(get data based on id)).
  2. POSt: Add new data(POST/API/todoItem.)
  3. PUT : Update an existing item(PUT/API/ToDoItem/{Id}).
  4. DELETE: Delete an Item(DELETE/API/ToDoItem/{id}).

Code for the above Code snippet is available in the following link https://github.com/EzDevPrac/CSharp_Karan/tree/master/WebApiDemo

Dependency Injection

  1. It is a software design pattern which enables the developement of loosely coupled code
  2. Three types of DI's -->Constructor injection -->Setter Injection -->Method Injection
  3. High level modules should not depend on low level module,Both should depend on abstraction.
  4. Abstraction should not depend upon details.details should depend upon abstarction.

Code Snippent

  1. Module Builder Class Which registers the dependencies
using System;
using Autofac;

namespace DependencyInjection
{
    public class ModuleBuilder : Module
    {
       protected override void Load(ContainerBuilder builder)
       {
        builder.RegisterType<ConsoleNotification>().As<INotificationService>();
        builder.RegisterType<UserService>().AsSelf();
       }

    }
}
  1. Notification Sevice Interface
using System;

namespace DependencyInjection
{
    public interface INotificationService
    {
    void NotifyUserChange(string User);
    }
}
  1. Console notification class which implements the Notification Service
using System;

namespace DependencyInjection
{
    public class ConsoleNotification : INotificationService
    {

     public void NotifyUserChange(string NewUser)
     {
         Console.WriteLine("User Name has been changed to  " + NewUser);

     }   
    }
}
  1. User Service Class
using System;

namespace DependencyInjection
{
    public class UserService
    {
       private INotificationService _INotificationService;

       public UserService(INotificationService notifcationService)
       {
           _INotificationService = notifcationService;
       }
        public void ChangeUserName(User OldUserName, string newUserName)
        {
           OldUserName.UserName = newUserName;
           _INotificationService.NotifyUserChange(OldUserName.UserName);

        }
    
        
    }
}
  1. User Class which is independent
using System;

namespace DependencyInjection
{
    public class User
    {
        public string UserName{get;set;}
        public User(string userName )
        {
               UserName = userName;
               }
        }
}
  1. Main Class which shows how the dependency injection is done
using System;
using Autofac;

namespace DependencyInjection
{
    class Program
    {
        static void Main(string[] args)
        {
            var ContainerBuilder = new ContainerBuilder();
            ContainerBuilder.RegisterModule<ModuleBuilder>();
            var container = ContainerBuilder.Build();
            var notificationService = container.Resolve<INotificationService>();
            var UserService = container.Resolve<UserService>();
              
            var user1 = new User("Karan");
            UserService.ChangeUserName(user1,"Karan Kumar");
         }
    }
}

Working code for the above snippet is available in the following link

https://github.com/EzDevPrac/CSharp_Karan/tree/master/DependencyInjection

DESIGN PATTERN

Adapter Design Pattern

  1. Adapter design pattern falls under structural design pattern category of Gang of four (GoF) design patterns.
  2. Adapter design pattern enables a system to use classes of another system that is incompatible with each other.
  3. Adapter design pattern allows a system to use classes whose interfaces are mutually incompatible. Adapter design pattern provides
    the bridge or connection between these mutually incompatible interfaces. This pattern is useful for off-the-self code, toolkits and libraries.

UML DIAGRAM

Client and Adaptee classes are incompatible with each other. Client calls ITarget interface to achieve functionality of Adaptee class.

Participants in above UML diagram are:

1. Client: This is the class which is incompatible with Adaptee class but wants to use Adaptee class code

2. ITarget: The interface that client class uses to achieve Adaptee class functionality.

3. Adapter: This class implements ITarget interface; this class also calls Adaptee class functionality inside.

4. Adaptee: This is the class which Client class want to use.

Code Snippet

1. Target Interface

2. Adapter Class

3. Adaptee Class

4. Client Class

5. Main Class

Output

Code for the above Code snippet is available in the following link https://github.com/EzDevPrac/CSharp_Karan/tree/master/AdapterDesignPatttern

Proxy Design Pattern

  1. Proxy Design pattern falls under Structural Pattern of Gang of Four (GOF) Design Patterns
  2. The proxy design pattern is used to provide a surrogate object, which references to other objects.
  3. The proxy pattern involves a class, called proxy class, which represents the functionality of another class.

UML Diagram

The classes, interfaces, and objects in the above UML class diagram are as follows:

1. Subject This is an interface having members that will be implemented by RealSubject and Proxy class.

2. RealSubject This is a class which we want to use more efficiently by using proxy class.

3. Proxy This is a class which holds the instance of RealSubject class and can access RealSubject class members as required.

There are various kinds of proxies, some of them are as follows:

  1. Virtual proxies: Hand over the creation of an object to another object

  2. Authentication proxies: Checks the access permissions for a request

  3. Remote proxies: Encodes requests and send them across a network

  4. Smart proxies: Change requests before sending them across a network

Code Snippet

  1. Bank Interface

  1. Bank Class That Implements Bank

  1. Atm Class(Proxy)

  1. Client Class

OUTPUT

Code for the above code snippet is available in the following link

https://github.com/EzDevPrac/CSharp_Karan/tree/master/ProxyDesignPattern

Abstract Factory Design Pattern

  1. The Abstract Factory Pattern is a creational Gang of Four (GoF) design pattern
  2. The Abstract Factory Pattern is used when you want to return several related classes of objects, each of which can return several
    different objects on request
  3. Abstract Factory patterns act a super-factory which creates other factories. This pattern is also called a Factory of factories. In
    Abstract Factory pattern an interface is responsible for creating a set of related objects, or dependent objects without specifying their concrete classes.

UML Diagram

The classes, interfaces, and objects in the above UML class diagram are as follows:

1. AbstractFactory This is an interface which is used to create abstract product

2. ConcreteFactory This is a class which implements the AbstractFactory interface to create concrete products.

3. AbstractProduct This is an interface which declares a type of product.

4. ConcreteProduct This is a class which implements the AbstractProduct interface to create a product.

5. Client This is a class which uses AbstractFactory and AbstractProduct interfaces to create a family of related objects.

Code Snippet

  1. Abstract Factory

  1. Concrete Abstract Factory for BMW Vehicles

  1. Concrete Abstract Factory for Ducati Vehicales

  1. Vehicle Client

  1. Abstract Product For Two Wheelers

  1. Concrete Product for Regular Two Wheelers

  1. Concrete Product for Sports Two Wheelers

  1. Abstact Product For Four Wheelers

  1. Concrete Product for Sports Four Wheelers

  1. Concrete Product for Regular Four Wheelers

  1. Main Class

OUTPUT

Code for the above code snippet is avaikable in the following link

https://github.com/EzDevPrac/CSharp_Karan/tree/master/AbstractDesignPattern

Prototype Design Pattern

  1. Prototype pattern falls under Creational Pattern of Gang of Four (GOF) Design Patterns
  2. Prototype design pattern is used to create a duplicate object or clone of the current object to enhance performance. This pattern
    is used when the creation of an object is costly or complex.
  3. This pattern is particularly useful for creating lots of instances of an object, all of which share some or all of their values.
  4. Prototype pattern solves problem related with duplicating a class in C#. There are scenarios in our programs where we want to copy
    any object and proceed independently with the copied object without affecting the original object.In C#, classes are reference type, so if you will copy the class object to another empty object and change the one object then it will also effect the other object, which is not desirable.

Difference between Shadow and Deep Cloning

  1. The cloning falls under two categories: shallow and deep. A shallow copy copies all reference types or value types, but it does not copy the objects that the references refer to. The references in the new object point to the same objects that the references in the original object points to. (Only Parent Object is cloned here).

  2. In contrast, a deep copy of an object copies the elements and everything directly or indirectly referenced by the elements. (Parent Object is cloned along with the containing objects)

UML DIAGRAM

Participants in above UML diagram are:

1. IPrototype: Interface that is used for the Prototypes (objects) to clone itself

2. ConcretePrototype1, ConcretePrototype2: Implements IPrototype interface

3. Client: Client class will make clones of different objects

Code Snippet

1. Prototype Interface

2. Student Concrete Prototype

3. Employee Concrete Prorotype

4. Client

Output

Code for the above snippet is available in the following link.

https://github.com/EzDevPrac/CSharp_Karan/tree/master/PrototypePattern

Itterator Design Pattern

  1. Iterator Design Pattern falls under Behavioral Pattern of Gang of Four (GOF) Design Patterns.
  2. Iterator Design Pattern provides a way to access the elements of a collection object in a sequential manner without knowing its underlying structure.
  3. This pattern is commonly used in the menu systems of many applications such as Editor, IDE, etc.
  4. The idea is that we'll have a class (the "Iterator") which contains a reference to a corresponding aggregate object, and that Iterator can traverse over its aggregate to retrieve individual objects.

UML DIAGRAM

The classes, interfaces, and objects in the above UML class diagram are as follows:

1. Client This is the class that contains an object collection and uses the Next operation of the iterator to retrieve items from the aggregate in an appropriate sequence.

2. Iterator This is an interface that defines operations for accessing the collection elements in a sequence.

3. ConcreteIterator This is a class that implements the Iterator interface.

4. Aggregate This is an interface which defines an operation to create an iterator.

5. ConcreteAggregate This is a class that implements an Aggregate interface.

Code Snippet

  1. Aggregate Interface

  1. Collection Class

  1. Concrete Aggregate

  1. Iterttor

  1. Concrete Itterator

  1. Main Menu

OUTPUT

Link for the example code for the above code snippet

https://github.com/EzDevPrac/CSharp_Karan/tree/master/IceCreamShopItteratorPattern

Strategy Design Pattern

  1. Strategy Design Pattern falls under Behavioral Pattern.
  2. This pattern allows a client to choose an algorithm from a family of algorithms at run-time and gives it a simple
    way to access it.
  3. Strategy Design Pattern involves the removal of an algorithm from its host class and putting it in a separate class. As you know, there may be multiple strategies which are applicable for a given problem.

UML diagram for the Strategy Design Pattern is given Below

The classes, interfaces, and objects in the above UML class diagram are as follows:

1. Context This is a class that contains a property to hold the reference of a Strategy object. This property will be set at run-time according to the algorithm that is required.

2. Strategy This is an interface that is used by the Context object to call the algorithm defined by a ConcreteStrategy.

3. ConcreteStrategyA/B These are classes that implement the Strategy interface.

CODE SNIPPET

  1. Strategy Class

  1. Concrete Strategy class for PhonePe

  1. Concrete Strategy Class for Paytm

  1. Concrete Strategy Class for Google pay

  1. Context class

  1. Main Class

INPUT AND OUTPUT

Code for the above code snippet is available in the following link https://github.com/EzDevPrac/CSharp_Karan/tree/master/OnlinePaymentStrategyPattern

Observer Design Pattern

Observer Design Pattern

  1. Observer design pattern should "Define a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically"

  2. The two important key terms in the pattern are the Subject and the Observer.

    • Subject: The Subject is the object which holds the value and takes responsibility in notifying the observers when the value is changed. The subject could be a database change, property change or so.
    • Observer: The Observer is the object listening to the subject's change. Basically it will be having its own updating/calculating routine that runs when get notified.
  3. There will be only one Subject and multiple number of Observers.

  4. Observer Design Pattern falls under Behavioral Pattern

UML diagram for the Observer Design Pattern

The classes, interfaces, and objects in the above UML class diagram are as follows:

  1. Subject This is a class that contains a private collection of the observers that are subscribed to a subject for notification by using Notify operation.

  2. ConcreteSubject This is a class that maintains its own state. When a change is made to its state, the object calls the base class's Notify operation to indicate this to all of its observers.

  3. Observer This is an interface which defines an operation Update, which is to be called when the subject's state changes.

  4. ConcreteObserver This is a class that implements the Observer interface and examines the subject to determine which information has changed.

Code Snippet

  1. Subject Class

  1. Concrete Subject Class

  1. Observer Interface

  1. Concrete Observer Class

  1. Main Class

INPUT

OUTPUT

Below Link is available for the above code Snippet https://github.com/EzDevPrac/CSharp_Karan/tree/master/SportsShopObserverPattern

Decorator Design Pattern

  1. A Decorator is a structural design pattern that allows us to extend the behavior of objects by placing these objects into a special wrapper class.
  2. The structure of this pattern consists of a Component class and a Concrete Component class from one part and a Decorator class and a Concrete Decorator class on the other side. The Concrete Decorator class is going to add additional behavior to our Concrete Component.
  3. Decorator pattern provides an alternative way to inheritance for modifying the behavior of an object.

UML Diagram of the structure of the Decorator Design Pattern

The classes, interfaces, and objects in the above UML class diagram are as follows:

1. Component

This is an interface containing members that will be implemented by ConcreteClass and Decorator.

2. ConcreteComponent

This is a class which implements the Component interface.

3. Decorator

This is an abstract class which implements the Component interface and contains the reference to a Component instance. This class also acts as base class for all decorators for components.

4. ConcreteDecorator

This is a class which inherits from Decorator class and provides a decorator for components.

Code Snippet

1. Component Interface

2. Concrete Component

3. Decorator Class

4. Concrete Decorator

5. Main Class

INPUT

OUTPUT

Code for the Above snippet is available in the following link

https://github.com/EzDevPrac/CSharp_Karan/tree/master/DecoratorPattern

Singleton Design Pattern

  1. Ensures a class has only one instance and provides a global point of access to it.
  2. A singleton is a class that only allows a single instance of itself to be created and usually gives simple access to that instance.
  3. Most commonly, singletons don't allow any parameters to be specified when creating the instance since the second request of an instance with a different parameter could be problematic! (If the same instance should be accessed for all requests with the same parameter then the factory pattern is more appropriate.)

Implementation Singleton Pattern in your code

There are many ways to implement a Singleton Pattern in C#.

  1. No Thread Safe Singleton.

  2. Thread-Safety Singleton.

  3. Thread-Safety Singleton using Double-Check Locking.

  4. Thread-Safe Singleton without using locks and no lazy instantiation.

  5. Fully lazy instantiation.

  6. No Thread Safe Singleton

Explanation of the following code:

  1. The following code is not thread-safe.
  2. Two different threads could both have evaluated the test (if instance == null) and found it to be true, then both create instances, which violates the singleton pattern.

So,the application will give you the following output.

  1. Thread Safety Singleton

Here, within the main method, we use Parallel.Invoke method to invoke multiple methods parallelly, This concept is introduced in .NET Framework 4.0.

So in our example, we are using the Parallel.Invoke method to access the GetInstance property parallelly, means at the same time multiple threads are accessing the GetInstance property. The below code is not Thread-safe because the way we code here two different threads can evaluate the condition if (instance == null) at the same time and both the threads found it to be true and they both will create the instances, which violates the singleton design pattern.

So,the application will give you the following output.

  1. Thread-Safety Singleton using Double-Check Locking.

In the Double-checked locking mechanism, first, we will check whether the instance is created or not. If not then only we will synchronize the method as shown below.

So,the application will give you the following output.

The below code is implemented using a singleton design pattern.

Code Snippet

1.Singleton calculate Class

2.Main Class

Output of the above Code

Below the link for the working code for the above example is available

https://github.com/EzDevPrac/CSharp_Karan/tree/master/SingletonDesignPattern/CalculatorUsingSingleton

FACTORY DESIGN PATTERN

  1. Design patterns are all about reusable solutions for a common problem.
  2. The 23 group of four are the foundation for the entire pattern
  3. They are classified into 3 groups i) Creational ii) Structural iii) Behavioural
  4. Factory pattern comes under the creational group.
    • Factory method is a design pattern which defines interface for creating an object but lets the class that implementing the interface decide which class to instantiate
    • Interfaces cannot have variables/fields , they can only have properties or methods.
    • It provides the client with a simple way to create the object.

  1. Product: Define the interface of the object the factory method creates.
  2. Concrete Product: This is a class that implements the product interface
  3. Creator: An abstract class and it declares the factory methods which returns a object of type product.
  4. Concrete Creator: Implements the creator class and overrides the factory methods

Code Snippet

  1. Product Class

  1. Concrete Product Class for Platinum card:

  1. Concrete Product Class for Titanium Card:

  1. Creator Class

  1. Concrete Creator class for the platinum card:

  1. Concrete Creator class for the Titanium Card

  1. Driver Class for the program:

Input

Output

Code Flow for the above given example

Below link is available for the Git to get the sample code

https://github.com/EzDevPrac/CSharp_Karan/tree/master/CreditCard

BUILDER DESIGN PATTERN:

  • This also falls under the category of creational design pattern.
  • This pattern is used to build complex object by using a step by step approach.
  • The main idea is “Separate the construction of complex object from its representation so that the same construction process can create different representation”.

  1. Builder: this is an interface which is used to define all the steps required to the product
  2. Concrete Builder: This is a class which implements the builder interface to create a complex product.
  3. Product: this is a class which defines the part of the complex object which are to be generated by the builder pattern
  4. Director: This is a class that is used to construct object using the builder interface.

Code Snippet

  1. Toy Builder Interface

  1. Product Class

  1. Concrete Builder for the Toy A

  1. Concrete Builder for the Toy B

  1. Director Class

  1. Main Class for the program

Output for the Code

Example code link for the above prototype is given below. https://github.com/EzDevPrac/CSharp_Karan/tree/master/BuilderPattern

Command Design Pattern:

It falls under behavioral patter. It is commonly used in the menu system of many applications such as Editor,IDE etc In this pattern a request is wrapped under an object as a command and passed to invoker object . The invoker object pass the command to the appropriate object which can handle it and that object executes the command.

  • UML diagram:

  1. Client Class --> Creates and executes the command object
  2. Invoker --> Asks the command to carry out the action
  3. Command --> This is an interface which specifies the execute operation
  4. Concrete Command --> Class that implements the execute operation by invoking on the receiver
  5. Receiver class --> Class that performs the Action Associated with the Request

Code Snippet

  1. command Interface

  1. The invoker Class

  1. The Reciever Class

  1. Concrete Command for addition

  1. Concrete Command for Subtraction

  1. Driver Class

Input And Output

A working Prototype of the code is available in the following link

https://github.com/EzDevPrac/CSharp_Karan/tree/master/CommandPattern

Facade Design Pattern

  1. Facade design pattern falls under the structural pattern of GOF.
  2. The Facade design pattern is particularly used when a system is very complex or difficult to understand because the system has a large number of interdependent classes
  3. Facade pattern hides the complexities of the system and provides an interface to the client using which the client can access the system.
  4. This pattern involves a single wrapper class which contains a set of members which are required by the client. These members access the system on behalf of the facade client and hide the implementation details.
  5. The facade design pattern is particularly used when a system is very complex or difficult to understand because the system has a large number of interdependent classes or its source code is unavailable.

UML Diagram

The classes, interfaces, and objects in the above UML class diagram are as follows:

Complex System A library of subsystems.

SubsystemA, SubsystemB, SubsystemC These are classes within a complex system and offer detailed operations.

Façade This is a wrapper class which wrapper class which contains a set of members which are required by the client.

Client This is a class which calls the high-level operations in the Façade.

Code Snippet

  1. Subsystem Class for System Ram

  1. Subsystem Class for System Processor

  1. Subsystem Class for System Capacity

  1. Subsystem Class for the System Graphics

  1. Subsystem Class for the System USB configuration

  1. The Facade Class to create the System

  1. The Main client Class

Input

Output

Below is the link for the working prototype of the above example

https://github.com/EzDevPrac/CSharp_Karan/tree/master/SystemConfigFacade

About

No description, website, or topics provided.

Resources

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published