# C# Interview Questions
###### tags: `Tech Interview` `Job Hunt`

## C# vs .NET
C# is a programming language while .NET is the framework used alongside C# to create a complete application.

## .NET Framework vs .NET Core vs .NET 5
- **.NET Framework:** Closed source, only ran on windows
- **.NET Core:** Open source, cross platform
- **.NET 5:** Unification of Framework with Core, alongside other runtimes such as Mono etc
**Also,**
- .NET Core an higher is superior in performance
- **Reason:** DLLs and dependencies where split to smaller ones, only needed DLLs are loaded

.Net Framework, less number of larger DLLs

.Net Core, more number of smalleer DLLs

## Compiling
C# is compiled into IL (Intermediate language) first, then JIT (Just in Time) compiler compiles IL into machine language.
**Why?:** Runtime environment might differ from development environment (different OS for example), hence, JIT chooses the best compile configuration depending on the runtime.

## CLR (Common Language Runtime)
Main usages:
1. Invokes JIT to compile code into machine language
2. Cleans any unused objects using GC (garbage collector)

## GC (Garbage Collector)
Keeps running in the background and claims any **unused and managed** resources.

**Managed vs Non-Managed**:
Managed is all the code that's written in C# (not imported as external DLLs for example) and is managed by the CLR.

## CTS (Common Type System)
Ensures different data types accross different .NET programming languages are compiled to the same "common type".

## CLS (Common Language Spec)
Is a specification where when followed, the program can be consumed by other programming language

**Example:**
Visual basic is not case sensitive, C# is
**Spec:** Don't used two variable names of different cases

## Stack vs Heap
#### Stack:
- Stores value-type variables (primitives such as doubles, ints, booleans, etc)
- Value is stored in the same place

#### Heap:
- Stores reference-type variables (objects) values refered to by a pointer
- Value is pointed by pointer in stack

## Value Type vs Reference Type
#### Value type:
- Variable and Value are both stored in stack

#### Reference type:
- Variable stored in stack with a pointer, Value is stored in heap (pointed to by the pointer).

## Boxing vs UnBoxing
- Boxing is moving data from value type to reference type (casting to an `object`)
- UnBoxing is moving data from reference type to value type (casting to a primitive)

## Casting
Converting data type

**Implicit Casting**: Happens when moving from a lower datatype to higher datatype (no data loss)

int x = 10;
double y = x;

> *See **Implicit Operators**..*

**Explicit Casting**: Must happen when moving from a higher datatype to a lower datatype (with data loss).

double x = 10;
int y = (int)x;

## Collections

| | Array | ArrayList | Collections (List) |
| -------- | -------- | -------- | -------- |
| Flexibility | Size is Constant | Variable in size | Variable in size |
| Type Safety | Strongly typed | Object (boxing and unboxing) | Strongly typed (using generics) |
| Notes | High Performance | Low performance due to boxing and unboxing + deprecated and should not be used in new code | Best of both worlds |

## TPL vs Threads
- TPL is an abstraction over threads
- TPL utilizes actual processor cores (without explicitly saying so)
- TPL uses thread pool, and might eventually run on the same thread (with await/async)

## Abstract Classes vs Interfaces

| Abstract Classes | Interfaces |
| -------- | -------- |
| "IS A" relationship | "HAS A" relationship |
| Is inherited from | Is Implemented |
| Allows "state" or fields | no fields |
| Allows default implementation (virtual) | Allows default implementation |
| Child class only allowed to inherit from one parent abstract class | Child class is allowed to implement multiple interfaces |

## Delegates
**Type-Safe** Pointer to a function and are used for thread communications and callbacks

#### Multicast Delegates:

Note that when functions do have return values, multicast delegates will hold the value of the last function called


Same case with out parameters (result will be 2)


## Func vs Action
Both of them are forms of delegates

- Func: Returns a value
- Action: Doesn't return any values

## Events

delegate void MyEventHandler(object o, EventArgs args);
event MyEventHandler MyEvent;

And then add method pointers (having the same signature as the handler) to MyEvent to subscribe to the event.

OR

EventHandler<EventArgs> MyEvent;

## SOLID
- S. Single Responsibility Principle
- `CLEAN CODE`: Module should only have a single reason to be modified later on.
- O. Open for extension, closed for modification
- When adding functionality, we should not modify existing modules, we should extend them
- L. Liskov Substitution Principle
- Objects of **Super Class** should be replaced with objects of **Sub Classes** without breaking the application
- Objects of **SubClass** should behave the same as its **Super Class**
- **BAD** EXAMPLE:

         class Bird
         {
             Fly();
         }

- `HummingBird` : `Bird` (Correct)
- `Ostritch` : `Bird` (Not Correct)
- **GOOD** EXAMPLE:

         class Bird
         {
         }
         
         class FlyingBird
         {
             Fly();
         }

- `HummingBird` : **`FlyingBird`** (Correct)
- `Ostritch` : `Bird` (Correct)
- I. Interface Segregation Principle
- No class (client) should be forced to implement an irrelevant method (that would not be used).
- **BAD** EXAMPLE:

         interface IOrder
         {
             orderBurger();
             orderFries();
         }
         class BurgerOrder : IOrder // Forced to implement orderFries()
         class FriesOrder : IOrder // Forced to implement orderBurger()

- **GOOD** EXAMPLE:

         interface IBurgerOrder
         {
             orderBurger();
         }
         interface IFriesOrder
         {
             
             orderFries();
         }
         class BurgerOrder : IBurgerOrder
         class FriesOrder : IFriesOrder

- D. Dependency Inversion
- High level modules shouldn't depend on low level modules
- High level modules **AND** low level modules should both depend **on abstractions**
- Abstractions should not depend on details
- Details should depend on abstractions
- In other words, don't inject concretes, inject interfaces

// Wrong example:
ElectricSwitch(LightBulb obj)
ElectricSwitch(TV obj)
ElectricSwitch(Fan obj)

// Correct example
ElectricSwitch(ISwitchable obj)

// See this vid
https://www.youtube.com/watch?v=9uubt7i_LGc

### OOP
- Inheritance
- **Encapsulation**: hides variables or some implementation that may be changed so often in a class to prevent outsiders access it directly. They must access it via getter and setter methods.
- **Abstraction**: is used to hide something too, but in a higher degree (class, interface). Clients who use an abstract class (or interface) do not care about what it was, they just need to know what it can do.

Encapsulation:-- Information hiding.
Abstraction:-- Implementation hiding.

- Polymorphism
- Objects are designed to share behaviors and they can take on more than one form. Polymorphism allows different types of objects to pass through the same interface (Array).

### Design Patterns
- Creational
- Builder: *Multisteps*
- Factory **Method**: *Just a method that is called*
- Abstract Factory: *Uses composition and dependency to construct a class*
- Behavioural
- Strategy
- Structural
- Adapter