IAAS vs PAAS vs SAAS

• IaaS requires the most user management of all the cloud services. The user is responsible for managing the operating systems, data, and applications.
• PaaS requires less user management. The cloud provider manages the operating systems, and the user is responsible for the applications and data they run and store.
• SaaS requires the least amount of management. The cloud provider is responsible for managing everything, and the end user just uses the software

IaaS, PaaS, and SaaS each contain different levels of managed services. You may easily use a combination of these types of infrastructure. You could use Office 365 on your company's computers (SaaS), and in Azure, you could host your VMs (IaaS) and use Azure SQL Database (PaaS) to store your data. With the cloud's flexibility, you can use any combination that provides you with the maximum result.

Azure Infra

Design Principle vs Design Pattern

Design Principle
Design principles provide high level guidelines to design better software applications. They do not provide implementation guidelines and are not bound to any programming language. The SOLID (SRP, OCP, LSP, ISP, DIP) principles are one of the most popular sets of design principles.

For example, the Single Responsibility Principle (SRP) suggests that a class should have only one reason to change. This is a high-level statement which we can keep in mind while designing or creating classes for our application. SRP does not provide specific implementation steps but it's up to you how you implement SRP in your application.

Design Pattern
Design Pattern provides low-level solutions related to implementation, of commonly occurring object-oriented problems. In other words, design pattern suggests a specific implementation for the specific object-oriented programming problem. For example, if you want to create a class that can only have one object at a time, then you can use the Singleton design pattern which suggests the best way to create a class that can only have one object.

Design patterns are tested by others and are safe to follow, e.g. Gang of Four patterns: Abstract Factory, Factory, Singleton, Command, etc.

The following pattern (but not limited) implements the IoC principle.

MVVM vs MVP vs MVC

   MVVM:-




MVP:-

MVP is a user interface architectural pattern engineered to facilitate automated unit testing and improve the separation of concerns in presentation logic:

• The model is an interface defining the data to be displayed or otherwise acted upon in the user interface.
• The view is a passive interface that displays data (the model) and routes user commands (events) to the presenter to act upon that data.
• The presenter acts upon the model and the view. It retrieves data from repositories (the model), and formats it for display in the view.

The view implementation instantiates the concrete presenter object, providing a reference to itself. The following C# code demonstrates a simple view constructor, where ConcreteDomainPresenter implements the IDomainPresenter interface:

public class DomainView : IDomainView
{
    private IDomainPresenter domainPresenter = null;

    ///<summary>Constructor</summary>
    public DomainView()
    {
        domainPresenter = new ConcreteDomainPresenter(this);
    }
}

MVC:- 

Model
The central component of the pattern. It is the application's dynamic data structure, independent of the user interface.It directly manages the data, logic and rules of the application.
View
Any representation of information such as a chart, diagram or table. Multiple views of the same information are possible, such as a bar chart for management and a tabular view for accountants.
Controller
Accepts input and converts it to commands for the model or view. 
In addition to dividing the application into these components, the model–view–controller design defines the interactions between them. 

The model is responsible for managing the data of the application. It receives user input from the controller.
The view means presentation of the model in a particular format.
The controller responds to the user input and performs interactions on the data model objects. The controller receives the input, optionally validates it and then passes the input to the model.

Abstract class vs Interface

Abstract class vs Interface: 

1. A class can implement any number of interfaces but a subclass can at most use only one abstract class.

2. An abstract class can have non-abstract Methods(concrete methods or full method definition) while in case of Interface all the methods has to be abstract.

3. An abstract class can declare or use any variables while an interface is not allowed to do so.

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.

=========================================================================

Dictionary vs Hashtable

 

Dictionary:

– Dictionary is a generic type which means we can use it with any data type.
– Only public static members are thread safe.
– It returns error if we try to find a key which does not exist.
– It is faster than a Hashtable because there is no boxing and unboxing.

Hashtable:

– Hashtable is not a generic type.
– All the members in a Hashtable are thread safe.
– It returns null if we try to find a key which does not exist.
– It is slower than dictionary because it requires boxing and unboxing.

SOLID design pattern

SRP – Single Responsibility Principle

The SRP states that a class should have only a single reason to change. This responsibility should be entirely encapsulated by the class. The services of the class should be narrowly aligned with that responsibility.

OCP – Open/Closed Principle

The Open-Closed Principle (OCP) states that software entities (classes, modules, methods, etc.) should be open for extension, but closed for modification.

LSP – Liskov Substitution Principle  states that objects of a superclass should be replaceable with objects of its subclasses without breaking the application.”

LSP states that any child class should only extend or modify behavior defined in the parent class, NOT introduce new behavior.

ISP – Interface Segregation Principle

DIP – Dependency Inversion Principle 

High level modules should not depend on low level modules; both should depend on abstractions. Abstractions should not depend on details.  Details should depend upon abstractions. 

Singleton Pattern vs Static Class

 

In simple words, Singleton is a pattern and not a keyword. The Singleton pattern has several advantages over static classes. A singleton allows a class for which there is just one, persistent instance across the lifetime of an application. That means, it created a single instance and that instance (reference to that instance) can be passed as a parameter to other methods, and treated as a normal object. While a static class allows only static methods and and you cannot pass static class as parameter.
A Singleton can implement interfaces, inherit from other classes and allow inheritance. While a static class cannot inherit their instance members. So Singleton is more flexible than static classes and can maintain state.
A Singleton can be initialized lazily or asynchronously and loaded automatically by the .NET Framework CLR (common language runtime) when the program or namespace containing the class is loaded. While a static class is generally initialized when it is first loaded and it will lead to potential class loader issues.
Singleton class follow the Object Oriented Principles, so that singletons can be handled polymorphically without forcing their users to assume that there is only one instance. While static cannot.
Other differencess:

1. Singleton Objects stored on heap while static class stored in stack.

1. Singleton Objects can have constructor while Static Class cannot.

1. Singleton Objects can dispose but not static class.

1. Singleton Objects can clone but not with static class.

x

Break singleton using c#

public class Person
{
    private static Person _person = null;

    private Person()
    { }

    public string Name { get; }

    public static Person PersonObj
    {
        get
        {
            if (_person == null)
                _person = new Person();

            return _person;
        }
    }
}

now i can create two instances of this class by Serialization.

static void Main(string[] args)
{
    Person p = Person.PersonObj;
    string sss = Newtonsoft.Json.JsonConvert.SerializeObject(p);
    Person p1 = JsonConvert.DeserializeObject<Person>(sss);    
    if (p != p1)
    {
           // insert here 
    }
} 

Now after Serialization I have two different object. As the class is singleton how it can have two different objects ?

Discussion :

This structural code demonstrates the Singleton pattern which assures only a single instance (the singleton) of the class can be created. 

A singleton is a programming concept - not a language feature. Its perfectly possible to create code that creates instances of classes that - in theory - should only be created by a singleton factory. You don't even need to use serialization to achieve that - just use Activator.CreateInstance().

It might be helpful also to consider that your class constructor also doesn't have to get called; sure, if your call new MyClass() it will do, but deserialization doesn't have to call the constructor. Serialization as a concept stores and rehydrates the state of a class instance; so it doesn't need to obey other class instantiation concepts, like constructor scope or constructor logic.

Cloning is a concept to create duplicate objects. Using clone we can create copy of object. Suppose, we ceate clone of a singleton object, then it wil create a copy that is there are two instances of a singleton class, hence the class is no more singleton.

Design Pattern(s)

1. Creational Patterns

  Abstract Factory : Creates an instance of several families of classes

  Builder : Separates object construction from its representation

  Factory Method : It is tedious when the client needs to specify the class name while creating the objects. So, to resolve this problem, we can use the Factory Method design pattern. It provides the client with a simple way to create the object.

  Prototype : A fully initialized instance to be copied or cloned

  Singleton : A class of which only a single instance can exist

Builder

Separates object construction from its representation

2. Structural Patterns

  Adapter ==> Match interfaces of different classes

  Bridge ==> Separates an object’s interface from its implementation

  Composite ==> A tree structure of simple and composite objects

  Decorator ==> Add responsibilities to objects dynamically

  Facade ==> A single class that represents an entire subsystem

  Flyweight ==> A fine-grained instance used for efficient sharing

  Proxy ==> An object representing another object

3. Behavioral Patterns

   Chain of Resp. ==> A way of passing a request between a chain of objects

  Command ==> Encapsulate a command request as an object

  Interpreter ==> A way to include language elements in a program

  Iterator ==> Sequentially access the elements of a collection

  Mediator ==> Defines simplified communication between classes

  Memento ==> Capture and restore an object's internal state

  Observer ==> A way of notifying change to a number of classes

  State ==> Alter an object's behavior when its state changes

  Strategy ==> Encapsulates an algorithm inside a class

  Template Method ==> Defer the exact steps of an algorithm to a subclass

  Visitor ==> Defines a new operation to a class without change