Object-Oriented Programming

Inheritance ("is-a" relationship) - A class derives from another class and inherits its members.

Composition ("has-a" relationship) - A class contains instances of other classes as members.

Key Principle: Favor composition over inheritance for better flexibility and loose coupling.

Example:

// Inheritance Example (is-a relationship)
public class Vehicle
{
    public string Brand { get; set; }
    public void Start()
    {
        Console.WriteLine("Vehicle started");
    }
}

public class Car : Vehicle  // Car IS-A Vehicle
{
    public int NumberOfDoors { get; set; }
}

// Composition Example (has-a relationship)
public class Engine
{
    public int Horsepower { get; set; }
    
    public void Start()
    {
        Console.WriteLine("Engine started");
    }
}

public class Transmission
{
    public string Type { get; set; }
    
    public void ShiftGear()
    {
        Console.WriteLine("Gear shifted");
    }
}

public class Car2
{
    // Car HAS-A Engine
    private Engine engine;
    // Car HAS-A Transmission
    private Transmission transmission;
    
    public Car2()
    {
        engine = new Engine { Horsepower = 200 };
        transmission = new Transmission { Type = "Automatic" };
    }
    
    public void Start()
    {
        engine.Start();
        Console.WriteLine("Car is ready to drive");
    }
    
    public void Drive()
    {
        transmission.ShiftGear();
    }
}

// Why Composition is often better:
// 1. More flexible - can change components at runtime
// 2. No tight coupling
// 3. Avoids deep inheritance hierarchies
// 4. Easier to test and maintain

The Liskov Substitution Principle (LSP) is one of the SOLID principles. It states that objects of a derived class should be able to replace objects of the base class without affecting the correctness of the program.

In simple terms: If class B is a subtype of class A, then objects of type A should be replaceable with objects of type B without breaking the application.

Example:

// Violation of LSP
public class Rectangle
{
    public virtual int Width { get; set; }
    public virtual int Height { get; set; }
    
    public int GetArea()
    {
        return Width * Height;
    }
}

public class Square : Rectangle
{
    private int side;
    
    public override int Width
    {
        get { return side; }
        set { side = value; }  // Setting width also affects height
    }
    
    public override int Height
    {
        get { return side; }
        set { side = value; }  // Setting height also affects width
    }
}

// This violates LSP because:
void TestRectangle(Rectangle rect)
{
    rect.Width = 5;
    rect.Height = 4;
    Console.WriteLine(rect.GetArea());  // Expected: 20
    // But if rect is Square, result will be 16 (4*4), breaking expectations
}

// Correct approach following LSP
public abstract class Shape
{
    public abstract int GetArea();
}

public class Rectangle : Shape
{
    public int Width { get; set; }
    public int Height { get; set; }
    
    public override int GetArea()
    {
        return Width * Height;
    }
}

public class Square : Shape
{
    public int Side { get; set; }
    
    public override int GetArea()
    {
        return Side * Side;
    }
}

// Why LSP is important:
// 1. Ensures reliable polymorphism
// 2. Prevents unexpected behavior in derived classes
// 3. Makes code more maintainable and predictable
// 4. Enables proper use of inheritance hierarchies

Dependency Injection (DI) is a design pattern where objects receive their dependencies from external sources rather than creating them internally. It implements the Dependency Inversion Principle (one of SOLID principles).

Three types of DI:

1. Constructor Injection (most common)
2. Property/Setter Injection
3. Method Injection

Example:

// WITHOUT Dependency Injection (Tight Coupling)
public class EmailService
{
    public void SendEmail(string message)
    {
        Console.WriteLine($"Sending email: {message}");
    }
}

public class NotificationService
{
    private EmailService emailService;
    
    public NotificationService()
    {
        // Tightly coupled - hard to test and change
        emailService = new EmailService();
    }
    
    public void Notify(string message)
    {
        emailService.SendEmail(message);
    }
}

// WITH Dependency Injection (Loose Coupling)
public interface IMessageService
{
    void SendMessage(string message);
}

public class EmailService : IMessageService
{
    public void SendMessage(string message)
    {
        Console.WriteLine($"Sending email: {message}");
    }
}

public class SmsService : IMessageService
{
    public void SendMessage(string message)
    {
        Console.WriteLine($"Sending SMS: {message}");
    }
}

// Constructor Injection
public class NotificationService
{
    private readonly IMessageService messageService;
    
    // Dependency is injected through constructor
    public NotificationService(IMessageService messageService)
    {
        this.messageService = messageService;
    }
    
    public void Notify(string message)
    {
        messageService.SendMessage(message);
    }
}

// Usage
var emailService = new EmailService();
var notificationService = new NotificationService(emailService);
notificationService.Notify("Hello via Email");

// Can easily switch to SMS
var smsService = new SmsService();
var smsNotificationService = new NotificationService(smsService);
smsNotificationService.Notify("Hello via SMS");

// Using DI Container (e.g., Microsoft.Extensions.DependencyInjection)
// In Startup.cs or Program.cs
services.AddScoped<IMessageService, EmailService>();
services.AddScoped<NotificationService>();

Benefits of Dependency Injection:

1. Loose Coupling - Classes depend on abstractions, not concrete implementations
2. Testability - Easy to mock dependencies for unit testing
3. Maintainability - Changes in dependencies don't affect dependent classes
4. Flexibility - Easy to swap implementations without changing code
5. Reusability - Components can be reused in different contexts

Design Patterns are reusable solutions to common software design problems. They represent best practices and provide a template for solving specific issues in software development.

2.9.1. Singleton Pattern

Ensures a class has only one instance and provides a global point of access to it.

public sealed class DatabaseConnection
{
    private static DatabaseConnection instance = null;
    private static readonly object lockObject = new object();
    
    private DatabaseConnection()
    {
        // Private constructor prevents instantiation
    }
    
    public static DatabaseConnection Instance
    {
        get
        {
            lock (lockObject)
            {
                if (instance == null)
                {
                    instance = new DatabaseConnection();
                }
                return instance;
            }
        }
    }
    
    public void Query(string sql)
    {
        Console.WriteLine($"Executing: {sql}");
    }
}

// Usage
var db1 = DatabaseConnection.Instance;
var db2 = DatabaseConnection.Instance;
// db1 and db2 refer to the same instance

2.9.2. Factory Pattern

Creates objects without specifying the exact class to create.

public interface IPayment
{
    void ProcessPayment(decimal amount);
}

public class CreditCardPayment : IPayment
{
    public void ProcessPayment(decimal amount)
    {
        Console.WriteLine($"Processing credit card payment: ${amount}");
    }
}

public class PayPalPayment : IPayment
{
    public void ProcessPayment(decimal amount)
    {
        Console.WriteLine($"Processing PayPal payment: ${amount}");
    }
}

public class CryptoPayment : IPayment
{
    public void ProcessPayment(decimal amount)
    {
        Console.WriteLine($"Processing crypto payment: ${amount}");
    }
}

public class PaymentFactory
{
    public static IPayment CreatePayment(string paymentType)
    {
        return paymentType.ToLower() switch
        {
            "creditcard" => new CreditCardPayment(),
            "paypal" => new PayPalPayment(),
            "crypto" => new CryptoPayment(),
            _ => throw new ArgumentException("Invalid payment type")
        };
    }
}

// Usage
IPayment payment = PaymentFactory.CreatePayment("creditcard");
payment.ProcessPayment(100.50m);

2.9.3. Observer Pattern

Defines a one-to-many dependency between objects so that when one object changes state, all its dependents are notified.

public interface IObserver
{
    void Update(string message);
}

public interface ISubject
{
    void Attach(IObserver observer);
    void Detach(IObserver observer);
    void Notify(string message);
}

public class NewsAgency : ISubject
{
    private List<IObserver> observers = new List<IObserver>();
    
    public void Attach(IObserver observer)
    {
        observers.Add(observer);
    }
    
    public void Detach(IObserver observer)
    {
        observers.Remove(observer);
    }
    
    public void Notify(string message)
    {
        foreach (var observer in observers)
        {
            observer.Update(message);
        }
    }
    
    public void PublishNews(string news)
    {
        Console.WriteLine($"Breaking News: {news}");
        Notify(news);
    }
}

public class NewsChannel : IObserver
{
    public string Name { get; set; }
    
    public NewsChannel(string name)
    {
        Name = name;
    }
    
    public void Update(string message)
    {
        Console.WriteLine($"{Name} received news: {message}");
    }
}

// Usage
var agency = new NewsAgency();
var channel1 = new NewsChannel("CNN");
var channel2 = new NewsChannel("BBC");

agency.Attach(channel1);
agency.Attach(channel2);
agency.PublishNews("Major event occurred!");

2.9.4. Strategy Pattern

Defines a family of algorithms, encapsulates each one, and makes them interchangeable.

public interface ISortStrategy
{
    void Sort(List<int> list);
}

public class BubbleSort : ISortStrategy
{
    public void Sort(List<int> list)
    {
        Console.WriteLine("Sorting using Bubble Sort");
        // Bubble sort implementation
        for (int i = 0; i < list.Count - 1; i++)
        {
            for (int j = 0; j < list.Count - i - 1; j++)
            {
                if (list[j] > list[j + 1])
                {
                    int temp = list[j];
                    list[j] = list[j + 1];
                    list[j + 1] = temp;
                }
            }
        }
    }
}

public class QuickSort : ISortStrategy
{
    public void Sort(List<int> list)
    {
        Console.WriteLine("Sorting using Quick Sort");
        // Quick sort implementation
        list.Sort();
    }
}

public class SortContext
{
    private ISortStrategy sortStrategy;
    
    public void SetSortStrategy(ISortStrategy strategy)
    {
        sortStrategy = strategy;
    }
    
    public void SortList(List<int> list)
    {
        sortStrategy.Sort(list);
    }
}

// Usage
var numbers = new List<int> { 5, 2, 8, 1, 9 };
var context = new SortContext();

context.SetSortStrategy(new BubbleSort());
context.SortList(numbers);

context.SetSortStrategy(new QuickSort());
context.SortList(numbers);

2.9.5. Repository Pattern

Mediates between the domain and data mapping layers, acting like an in-memory collection of domain objects.

public class Product
{
    public int Id { get; set; }
    public string Name { get; set; }
    public decimal Price { get; set; }
}

public interface IRepository<T> where T : class
{
    T GetById(int id);
    IEnumerable<T> GetAll();
    void Add(T entity);
    void Update(T entity);
    void Delete(int id);
}

public class ProductRepository : IRepository<Product>
{
    private List<Product> products = new List<Product>();
    
    public Product GetById(int id)
    {
        return products.FirstOrDefault(p => p.Id == id);
    }
    
    public IEnumerable<Product> GetAll()
    {
        return products;
    }
    
    public void Add(Product entity)
    {
        products.Add(entity);
        Console.WriteLine($"Product {entity.Name} added");
    }
    
    public void Update(Product entity)
    {
        var existing = GetById(entity.Id);
        if (existing != null)
        {
            existing.Name = entity.Name;
            existing.Price = entity.Price;
            Console.WriteLine($"Product {entity.Id} updated");
        }
    }
    
    public void Delete(int id)
    {
        var product = GetById(id);
        if (product != null)
        {
            products.Remove(product);
            Console.WriteLine($"Product {id} deleted");
        }
    }
}

// Usage
var repository = new ProductRepository();
repository.Add(new Product { Id = 1, Name = "Laptop", Price = 999.99m });
repository.Add(new Product { Id = 2, Name = "Mouse", Price = 29.99m });

var allProducts = repository.GetAll();
var laptop = repository.GetById(1);

Shallow Copy creates a new object but copies only the reference of nested objects. Changes to nested objects affect both the original and copied object.

Deep Copy creates a new object and recursively copies all nested objects. Changes to the copy don't affect the original.

Example:

public class Address
{
    public string Street { get; set; }
    public string City { get; set; }
    
    public Address Clone()
    {
        return new Address
        {
            Street = this.Street,
            City = this.City
        };
    }
}

public class Person
{
    public string Name { get; set; }
    public int Age { get; set; }
    public Address Address { get; set; }
    
    // Shallow Copy using MemberwiseClone
    public Person ShallowCopy()
    {
        return (Person)this.MemberwiseClone();
    }
    
    // Deep Copy - manually copying all reference types
    public Person DeepCopy()
    {
        return new Person
        {
            Name = this.Name,
            Age = this.Age,
            Address = this.Address?.Clone()  // Clone nested object
        };
    }
}

// Demonstration
class Program
{
    static void Main()
    {
        // Original object
        var person1 = new Person
        {
            Name = "John",
            Age = 30,
            Address = new Address { Street = "123 Main St", City = "New York" }
        };
        
        // Shallow Copy
        var shallowCopy = person1.ShallowCopy();
        shallowCopy.Name = "Jane";  // Changing value type
        shallowCopy.Address.City = "Los Angeles";  // Changing reference type
        
        Console.WriteLine("After Shallow Copy:");
        Console.WriteLine($"Original: {person1.Name}, {person1.Address.City}");
        // Output: Original: John, Los Angeles (City changed!)
        Console.WriteLine($"Shallow Copy: {shallowCopy.Name}, {shallowCopy.Address.City}");
        // Output: Shallow Copy: Jane, Los Angeles
        
        Console.WriteLine();
        
        // Deep Copy
        var person2 = new Person
        {
            Name = "Bob",
            Age = 25,
            Address = new Address { Street = "456 Oak Ave", City = "Chicago" }
        };
        
        var deepCopy = person2.DeepCopy();
        deepCopy.Name = "Alice";
        deepCopy.Address.City = "Boston";
        
        Console.WriteLine("After Deep Copy:");
        Console.WriteLine($"Original: {person2.Name}, {person2.Address.City}");
        // Output: Original: Bob, Chicago (City unchanged!)
        Console.WriteLine($"Deep Copy: {deepCopy.Name}, {deepCopy.Address.City}");
        // Output: Deep Copy: Alice, Boston
    }
}

These three keywords control how methods behave in inheritance hierarchies and are fundamental to understanding polymorphism in C#.

1. virtual Keyword:

• Marks a method in the base class as overridable
• Allows derived classes to provide their own implementation
• Enables runtime polymorphism

2. override Keyword:

• Used in derived classes to replace the virtual method implementation
• Provides runtime polymorphism - the correct method is called based on the actual object type
• Must override a virtual, abstract, or override method

3. new Keyword:

• Used for method hiding (not overriding)
• Creates a new method that hides the base class method
• Provides compile-time polymorphism - method called depends on reference type, not object type

Example:

public class Animal
{
    // Virtual method - can be overridden
    public virtual void MakeSound()
    {
        Console.WriteLine("Animal makes a sound");
    }
    
    // Regular method - can be hidden with 'new'
    public void Move()
    {
        Console.WriteLine("Animal moves");
    }
}

public class Dog : Animal
{
    // Override - runtime polymorphism
    public override void MakeSound()
    {
        Console.WriteLine("Dog barks: Woof!");
    }
    
    // Method hiding with 'new' - compile-time polymorphism
    public new void Move()
    {
        Console.WriteLine("Dog runs on four legs");
    }
}

public class Cat : Animal
{
    // Override - runtime polymorphism
    public override void MakeSound()
    {
        Console.WriteLine("Cat meows: Meow!");
    }
    
    // Method hiding with 'new' - compile-time polymorphism
    public new void Move()
    {
        Console.WriteLine("Cat walks gracefully");
    }
}

// Demonstration of the differences
public class PolymorphismDemo
{
    public static void DemonstratePolymorphism()
    {
        // Runtime Polymorphism (override)
        Animal animal1 = new Dog();
        Animal animal2 = new Cat();
        
        // Calls the overridden method based on actual object type
        animal1.MakeSound(); // Output: "Dog barks: Woof!"
        animal2.MakeSound(); // Output: "Cat meows: Meow!"
        
        // Compile-time Polymorphism (new)
        // Calls the method based on reference type, not object type
        animal1.Move(); // Output: "Animal moves" (base class method)
        animal2.Move(); // Output: "Animal moves" (base class method)
        
        // To call the hidden method, need to cast to derived type
        ((Dog)animal1).Move(); // Output: "Dog runs on four legs"
        ((Cat)animal2).Move(); // Output: "Cat walks gracefully"
        
        // Direct instantiation calls the correct method
        Dog dog = new Dog();
        Cat cat = new Cat();
        
        dog.MakeSound(); // Output: "Dog barks: Woof!"
        dog.Move();      // Output: "Dog runs on four legs"
        
        cat.MakeSound(); // Output: "Cat meows: Meow!"
        cat.Move();      // Output: "Cat walks gracefully"
    }
}

Key Differences Summary:

Best Practices:

• Use virtual in base classes when you want derived classes to customize behavior
• Use override when you want true polymorphism and method replacement
• Use new sparingly - only when you need to hide a method and don't want polymorphism
• Prefer override over new for better object-oriented design
• Always call base.MethodName() in overrides when you want to extend, not replace, functionality

Access modifiers control the visibility and accessibility of classes, methods, properties, and other members in C#. They are fundamental to encapsulation and object-oriented design.

Available Access Modifiers:

1. public - Most Permissive

• Accessible from anywhere
• No restrictions on access

2. private - Most Restrictive

• Only accessible within the same class
• Default for class members

3. protected - Family Access

• Accessible within the same class and derived classes
• Not accessible from outside the inheritance hierarchy

4. internal - Assembly Access

• Accessible within the same assembly (project)
• Default for classes and interfaces

5. protected internal - Family or Assembly Access

• Accessible within the same assembly OR derived classes (even in different assemblies)

6. private protected - Family and Assembly Access (C# 7.2+)

• Accessible within the same class, derived classes, AND same assembly

Example:

// Assembly: MyLibrary.dll
namespace MyLibrary
{
    // Internal class - only accessible within this assembly
    internal class InternalHelper
    {
        public void DoWork() { }
    }
    
    // Public class - accessible from other assemblies
    public class BankAccount
    {
        // Private field - only accessible within this class
        private decimal balance;
        private string accountNumber;
        
        // Protected field - accessible in derived classes
        protected DateTime lastTransactionDate;
        
        // Internal field - accessible within this assembly
        internal string internalNotes;
        
        // Protected internal - accessible in derived classes OR same assembly
        protected internal string specialNotes;
        
        // Private protected - accessible in derived classes AND same assembly
        private protected string confidentialNotes;
        
        // Public constructor
        public BankAccount(string accountNumber, decimal initialBalance)
        {
            this.accountNumber = accountNumber;
            this.balance = initialBalance;
            lastTransactionDate = DateTime.Now;
        }
        
        // Public property - accessible from anywhere
        public decimal Balance
        {
            get { return balance; }
            private set // Private setter - only this class can modify
            {
                if (value < 0)
                    throw new ArgumentException("Balance cannot be negative");
                balance = value;
            }
        }
        
        // Public method - accessible from anywhere
        public void Deposit(decimal amount)
        {
            if (amount <= 0)
                throw new ArgumentException("Amount must be positive");
            
            Balance += amount;
            lastTransactionDate = DateTime.Now;
            LogTransaction("Deposit", amount);
        }
        
        // Protected method - accessible in derived classes
        protected virtual void LogTransaction(string type, decimal amount)
        {
            Console.WriteLine($"{type}: {amount:C} on {lastTransactionDate}");
        }
        
        // Internal method - accessible within this assembly
        internal void InternalAudit()
        {
            Console.WriteLine($"Internal audit for account {accountNumber}");
        }
        
        // Private method - only accessible within this class
        private void ValidateAccount()
        {
            if (string.IsNullOrEmpty(accountNumber))
                throw new InvalidOperationException("Invalid account number");
        }
    }
    
    // Derived class in the same assembly
    public class SavingsAccount : BankAccount
    {
        private decimal interestRate;
        
        public SavingsAccount(string accountNumber, decimal initialBalance, decimal interestRate)
            : base(accountNumber, initialBalance)
        {
            this.interestRate = interestRate;
        }
        
        // Can access protected members
        public void ApplyInterest()
        {
            decimal interest = Balance * interestRate;
            Balance += interest; // Can access protected setter through property
            lastTransactionDate = DateTime.Now; // Can access protected field
            LogTransaction("Interest", interest); // Can access protected method
        }
        
        // Can access protected internal members
        public void UpdateSpecialNotes(string notes)
        {
            specialNotes = notes; // Accessible
        }
        
        // Can access private protected members
        public void UpdateConfidentialNotes(string notes)
        {
            confidentialNotes = notes; // Accessible (same assembly + derived)
        }
        
        // Override protected method
        protected override void LogTransaction(string type, decimal amount)
        {
            base.LogTransaction(type, amount);
            Console.WriteLine($"Interest Rate: {interestRate:P}");
        }
    }
}

// Assembly: MyApplication.exe (references MyLibrary.dll)
namespace MyApplication
{
    public class Program
    {
        public static void Main()
        {
            var account = new BankAccount("123456", 1000);
            
            // Public members - accessible
            account.Deposit(500);
            Console.WriteLine($"Balance: {account.Balance}");
            
            // Internal members - NOT accessible (different assembly)
            // account.InternalAudit(); // Compilation error
            
            // Protected members - NOT accessible (not derived class)
            // account.lastTransactionDate = DateTime.Now; // Compilation error
            
            // Private members - NOT accessible
            // account.balance = 2000; // Compilation error
            
            var savingsAccount = new SavingsAccount("789012", 2000, 0.05m);
            savingsAccount.ApplyInterest();
            savingsAccount.UpdateSpecialNotes("VIP Customer");
        }
    }
    
    // Derived class in different assembly
    public class CheckingAccount : BankAccount
    {
        public CheckingAccount(string accountNumber, decimal initialBalance)
            : base(accountNumber, initialBalance)
        {
        }
        
        // Can access protected members
        public void ProcessCheck(decimal amount)
        {
            Balance -= amount; // Can access protected setter
            lastTransactionDate = DateTime.Now; // Can access protected field
        }
        
        // Can access protected internal members
        public void UpdateSpecialNotes(string notes)
        {
            specialNotes = notes; // Accessible (derived class)
        }
        
        // CANNOT access private protected members (different assembly)
        // public void UpdateConfidentialNotes(string notes)
        // {
        //     confidentialNotes = notes; // Compilation error
        // }
    }
}

Access Modifier Guidelines:

When to use public:

• API surface that external code needs to use
• Properties that represent the object's state
• Methods that provide core functionality

When to use private:

• Implementation details that should be hidden
• Helper methods used only within the class
• Fields that should only be modified through properties

When to use protected:

• Members that derived classes need to access
• Virtual methods that can be overridden
• Fields that derived classes need to modify

When to use internal:

• Classes that are implementation details of your library
• Methods that should only be used within your assembly
• Testing utilities that shouldn't be exposed publicly

When to use protected internal:

• Members that derived classes OR assembly code needs
• Rarely used - consider if you really need this level of access

When to use private protected:

• Members that only derived classes in the same assembly should access
• Very specific use case - rarely needed

Default Access Levels:

• Class members: private
• Classes and interfaces: internal
• Namespaces: Always public (cannot be modified)

Best Practices:

• Start with the most restrictive access level (private)
• Only increase visibility when necessary
• Use properties instead of public fields
• Prefer protected over protected internal when possible
• Document public APIs thoroughly
• Use internal for testing utilities

Static members belong to the class itself, while instance members belong to individual objects (instances) of the class. This fundamental difference affects memory allocation, access patterns, and usage scenarios.

Key Differences:

Example:

public class Counter
{
    // Static field - shared across all instances
    private static int totalCount = 0;
    
    // Instance field - each object has its own copy
    private int instanceCount = 0;
    
    // Static property - accessed via class name
    public static int TotalCount
    {
        get { return totalCount; }
        private set { totalCount = value; }
    }
    
    // Instance property - accessed via object reference
    public int InstanceCount
    {
        get { return instanceCount; }
        private set { instanceCount = value; }
    }
    
    // Static constructor - called once when class is first used
    static Counter()
    {
        Console.WriteLine("Static constructor called - Counter class initialized");
        TotalCount = 0;
    }
    
    // Instance constructor - called for each new object
    public Counter()
    {
        Console.WriteLine("Instance constructor called - new Counter created");
        InstanceCount = 0;
    }
    
    // Static method - can only access static members
    public static void ResetTotalCount()
    {
        TotalCount = 0;
        Console.WriteLine("Total count reset to 0");
    }
    
    // Instance method - can access both static and instance members
    public void Increment()
    {
        InstanceCount++;
        TotalCount++; // Can access static members from instance methods
        Console.WriteLine($"Instance count: {InstanceCount}, Total count: {TotalCount}");
    }
    
    // Static method that creates and returns instances
    public static Counter CreateCounter()
    {
        return new Counter();
    }
    
    // Instance method that uses static members
    public void DisplayStats()
    {
        Console.WriteLine($"This counter: {InstanceCount}");
        Console.WriteLine($"All counters total: {TotalCount}");
    }
}

// Usage demonstration
public class StaticVsInstanceDemo
{
    public static void Demonstrate()
    {
        Console.WriteLine("=== Static vs Instance Members Demo ===");
        
        // Access static members via class name
        Console.WriteLine($"Initial total count: {Counter.TotalCount}");
        Counter.ResetTotalCount();
        
        // Create instances
        Counter counter1 = new Counter();
        Counter counter2 = new Counter();
        Counter counter3 = new Counter();
        
        // Use instance methods
        counter1.Increment(); // Instance: 1, Total: 1
        counter1.Increment(); // Instance: 2, Total: 2
        
        counter2.Increment(); // Instance: 1, Total: 3
        counter2.Increment(); // Instance: 2, Total: 4
        counter2.Increment(); // Instance: 3, Total: 5
        
        counter3.Increment(); // Instance: 1, Total: 6
        
        // Display stats for each instance
        counter1.DisplayStats();
        counter2.DisplayStats();
        counter3.DisplayStats();
        
        // Static count is shared across all instances
        Console.WriteLine($"Final total count: {Counter.TotalCount}");
    }
}

When to Use Static Members:

• Utility methods that don't need instance data
• Constants and configuration values
• Factory methods
• Extension methods
• Shared state across instances

When to Use Instance Members:

• Object-specific data and behavior
• Methods that need access to instance fields
• Stateful operations
• Object lifecycle management

Constructors are special methods that initialize objects when they are created, while destructors (finalizers) are special methods that clean up resources when objects are destroyed by the garbage collector.

Constructor Types:

1. Default Constructor

• Parameterless constructor
• Automatically provided if no constructors are defined
• Initializes fields to default values

2. Parameterized Constructor

• Takes parameters to initialize the object
• Allows custom initialization

3. Copy Constructor

• Creates a new object by copying another object
• Useful for creating deep copies

4. Static Constructor

• Initializes static members
• Called once before the class is first used

Example:

public class Person
{
    // Fields
    private string name;
    private int age;
    private DateTime birthDate;
    private static int totalPersons = 0;
    
    // Static constructor - called once when class is first used
    static Person()
    {
        Console.WriteLine("Person class initialized");
        totalPersons = 0;
    }
    
    // Default constructor
    public Person()
    {
        Console.WriteLine("Default constructor called");
        name = "Unknown";
        age = 0;
        birthDate = DateTime.MinValue;
        totalPersons++;
    }
    
    // Parameterized constructor
    public Person(string name, int age)
    {
        Console.WriteLine($"Parameterized constructor called for {name}");
        this.name = name;
        this.age = age;
        this.birthDate = DateTime.Now.AddYears(-age);
        totalPersons++;
    }
    
    // Copy constructor
    public Person(Person other)
    {
        Console.WriteLine($"Copy constructor called for {other.name}");
        this.name = other.name;
        this.age = other.age;
        this.birthDate = other.birthDate;
        totalPersons++;
    }
    
    // Constructor chaining using 'this'
    public Person(string name) : this(name, 0)
    {
        Console.WriteLine("Constructor chaining - calling parameterized constructor");
    }
    
    // Properties
    public string Name
    {
        get => name;
        set => name = value ?? throw new ArgumentNullException(nameof(value));
    }
    
    public int Age
    {
        get => age;
        set => age = value >= 0 ? value : throw new ArgumentException("Age cannot be negative");
    }
    
    public static int TotalPersons => totalPersons;
    
    // Methods
    public void DisplayInfo()
    {
        Console.WriteLine($"Name: {name}, Age: {age}, Born: {birthDate:yyyy-MM-dd}");
    }
    
    // Destructor (Finalizer) - called by garbage collector
    ~Person()
    {
        Console.WriteLine($"Destructor called for {name}");
        totalPersons--;
    }
}

// Advanced example with resource management
public class FileManager : IDisposable
{
    private string fileName;
    private FileStream fileStream;
    private bool disposed = false;
    
    // Constructor with file validation
    public FileManager(string fileName)
    {
        if (string.IsNullOrEmpty(fileName))
            throw new ArgumentException("File name cannot be null or empty");
        
        this.fileName = fileName;
        Console.WriteLine($"FileManager created for: {fileName}");
    }
    
    // Method to open file
    public void OpenFile()
    {
        if (fileStream != null)
            throw new InvalidOperationException("File is already open");
        
        try
        {
            fileStream = File.Open(fileName, FileMode.OpenOrCreate);
            Console.WriteLine($"File opened: {fileName}");
        }
        catch (Exception ex)
        {
            throw new InvalidOperationException($"Failed to open file: {ex.Message}");
        }
    }
    
    // Method to write data
    public void WriteData(string data)
    {
        if (fileStream == null)
            throw new InvalidOperationException("File is not open");
        
        byte[] bytes = Encoding.UTF8.GetBytes(data);
        fileStream.Write(bytes, 0, bytes.Length);
        fileStream.Flush();
        Console.WriteLine($"Data written to {fileName}");
    }
    
    // Destructor - backup cleanup (not guaranteed to be called)
    ~FileManager()
    {
        Console.WriteLine($"Destructor called for {fileName}");
        Dispose(false);
    }
    
    // IDisposable implementation for proper resource cleanup
    public void Dispose()
    {
        Dispose(true);
        GC.SuppressFinalize(this); // Prevents destructor from being called
    }
    
    protected virtual void Dispose(bool disposing)
    {
        if (!disposed)
        {
            if (disposing)
            {
                // Dispose managed resources
                fileStream?.Dispose();
                Console.WriteLine($"File closed: {fileName}");
            }
            
            // Dispose unmanaged resources (if any)
            disposed = true;
        }
    }
}

Key Points:

Constructors:

• Must have the same name as the class
• Cannot have a return type
• Can be overloaded
• Can call other constructors using this or base
• Static constructors cannot have access modifiers

Destructors:

• Cannot be called explicitly
• Cannot be overloaded or inherited
• Cannot have access modifiers
• Should not be relied upon for critical cleanup
• Use IDisposable pattern for proper resource management

Best Practices:

• Use constructors for initialization
• Use IDisposable instead of destructors for resource cleanup
• Implement proper exception handling in constructors
• Use constructor chaining to avoid code duplication
• Prefer using statements for automatic disposal

Method hiding uses the new keyword to hide a base class method, while method overriding uses the override keyword to replace a virtual method. The key difference is in when the method resolution occurs and how polymorphism behaves.

Key Differences:

Example:

public class Animal
{
    // Virtual method - can be overridden
    public virtual void MakeSound()
    {
        Console.WriteLine("Animal makes a sound");
    }
    
    // Regular method - can be hidden
    public void Move()
    {
        Console.WriteLine("Animal moves");
    }
    
    // Virtual method for demonstration
    public virtual void Sleep()
    {
        Console.WriteLine("Animal sleeps");
    }
}

public class Dog : Animal
{
    // Method Overriding - runtime polymorphism
    public override void MakeSound()
    {
        Console.WriteLine("Dog barks: Woof!");
    }
    
    // Method Hiding - compile-time polymorphism
    public new void Move()
    {
        Console.WriteLine("Dog runs on four legs");
    }
    
    // Method Hiding with new keyword (explicit)
    public new void Sleep()
    {
        Console.WriteLine("Dog sleeps in a dog bed");
    }
}

public class Cat : Animal
{
    // Method Overriding
    public override void MakeSound()
    {
        Console.WriteLine("Cat meows: Meow!");
    }
    
    // Method Hiding
    public new void Move()
    {
        Console.WriteLine("Cat walks gracefully");
    }
    
    // Method Hiding
    public new void Sleep()
    {
        Console.WriteLine("Cat sleeps on a windowsill");
    }
}

// Demonstration of the differences
public class MethodHidingVsOverridingDemo
{
    public static void Demonstrate()
    {
        Console.WriteLine("=== Method Hiding vs Overriding Demo ===");
        
        // Create objects
        Animal animal1 = new Dog();
        Animal animal2 = new Cat();
        
        Dog dog = new Dog();
        Cat cat = new Cat();
        
        Console.WriteLine("\n--- Runtime Polymorphism (Override) ---");
        // Method resolution based on ACTUAL object type
        animal1.MakeSound(); // Calls Dog.MakeSound() - runtime polymorphism
        animal2.MakeSound(); // Calls Cat.MakeSound() - runtime polymorphism
        
        Console.WriteLine("\n--- Compile-time Polymorphism (Hiding) ---");
        // Method resolution based on REFERENCE type
        animal1.Move(); // Calls Animal.Move() - compile-time polymorphism
        animal2.Move(); // Calls Animal.Move() - compile-time polymorphism
        
        animal1.Sleep(); // Calls Animal.Sleep() - compile-time polymorphism
        animal2.Sleep(); // Calls Animal.Sleep() - compile-time polymorphism
        
        Console.WriteLine("\n--- Direct Object Access ---");
        // When accessing directly, the hidden method is called
        dog.Move();  // Calls Dog.Move()
        cat.Move();  // Calls Cat.Move()
        
        dog.Sleep(); // Calls Dog.Sleep()
        cat.Sleep(); // Calls Cat.Sleep()
        
        Console.WriteLine("\n--- Casting to Access Hidden Methods ---");
        // To call the hidden method through base reference, cast to derived type
        ((Dog)animal1).Move();  // Calls Dog.Move()
        ((Cat)animal2).Move();  // Calls Cat.Move()
    }
}

When to Use Method Hiding:

• When you want to provide a completely different implementation
• When you don't want polymorphic behavior
• When you need to break the inheritance chain for a specific method

When to Use Method Overriding:

• When you want to extend or modify base class behavior
• When you want polymorphic behavior
• When you want to maintain the inheritance relationship

Best Practices:

• Prefer override over new for better object-oriented design
• Use new only when you intentionally want to hide a method
• Always document when using method hiding
• Consider if the base class method should be virtual instead

Partial classes allow you to split a single class definition across multiple files, while partial methods allow you to declare a method in one part and optionally implement it in another part. This is particularly useful for code generation, designer files, and organizing large classes.

Partial Classes:

Benefits:

• Split large classes across multiple files
• Separate generated code from hand-written code
• Organize related functionality
• Enable multiple developers to work on the same class

Example:

// File: Person.cs
public partial class Person
{
    private string firstName;
    private string lastName;
    
    public Person(string firstName, string lastName)
    {
        this.firstName = firstName;
        this.lastName = lastName;
    }
    
    public string GetFullName()
    {
        return $"{firstName} {lastName}";
    }
}

// File: Person.Properties.cs
public partial class Person
{
    public string FirstName
    {
        get => firstName;
        set => firstName = value ?? throw new ArgumentNullException(nameof(value));
    }
    
    public string LastName
    {
        get => lastName;
        set => lastName = value ?? throw new ArgumentNullException(nameof(value));
    }
    
    public int Age { get; set; }
    public string Email { get; set; }
}

// File: Person.Methods.cs
public partial class Person
{
    public void DisplayInfo()
    {
        Console.WriteLine($"Name: {GetFullName()}");
        Console.WriteLine($"Age: {Age}");
        Console.WriteLine($"Email: {Email}");
    }
    
    public bool IsAdult()
    {
        return Age >= 18;
    }
    
    public void SendEmail(string subject, string body)
    {
        if (string.IsNullOrEmpty(Email))
            throw new InvalidOperationException("Email address is not set");
        
        Console.WriteLine($"Sending email to {Email}");
        Console.WriteLine($"Subject: {subject}");
        Console.WriteLine($"Body: {body}");
    }
}

// File: Person.Validation.cs
public partial class Person
{
    public bool Validate()
    {
        return !string.IsNullOrEmpty(firstName) &&
               !string.IsNullOrEmpty(lastName) &&
               Age >= 0 &&
               IsValidEmail(Email);
    }
    
    private bool IsValidEmail(string email)
    {
        return !string.IsNullOrEmpty(email) && email.Contains("@");
    }
}

Advanced Example - Code Generation Scenario:

// File: User.cs (Hand-written code)
public partial class User
{
    private int id;
    private string username;
    private string email;
    
    public User(string username, string email)
    {
        this.username = username;
        this.email = email;
    }
    
    // Hand-written business logic
    public bool IsActive()
    {
        return !string.IsNullOrEmpty(username) && !string.IsNullOrEmpty(email);
    }
    
    public void UpdateProfile(string newEmail)
    {
        if (IsValidEmail(newEmail))
        {
            email = newEmail;
            OnProfileUpdated(); // Partial method call
        }
    }
    
    // Partial method declaration - implemented in generated code
    partial void OnProfileUpdated();
    
    // Partial method for validation - implemented in generated code
    partial void ValidateUser();
    
    private bool IsValidEmail(string email)
    {
        return !string.IsNullOrEmpty(email) && email.Contains("@");
    }
}

// File: User.Generated.cs (Generated code - e.g., from Entity Framework)
public partial class User
{
    // Generated properties
    public int Id
    {
        get => id;
        set => id = value;
    }
    
    public string Username
    {
        get => username;
        set => username = value;
    }
    
    public string Email
    {
        get => email;
        set => email = value;
    }
    
    // Generated methods
    public override string ToString()
    {
        return $"User: {username} ({email})";
    }
    
    public override bool Equals(object obj)
    {
        if (obj is User other)
            return id == other.id;
        return false;
    }
    
    public override int GetHashCode()
    {
        return id.GetHashCode();
    }
    
    // Partial method implementations
    partial void OnProfileUpdated()
    {
        Console.WriteLine($"Profile updated for user: {username}");
        // Could trigger events, update database, etc.
    }
    
    partial void ValidateUser()
    {
        if (string.IsNullOrEmpty(username))
            throw new InvalidOperationException("Username is required");
        
        if (string.IsNullOrEmpty(email))
            throw new InvalidOperationException("Email is required");
    }
}

Partial Methods:

Key Characteristics:

• Must be declared with partial keyword
• Must return void
• Cannot have access modifiers (implicitly private)
• Cannot be virtual, override, sealed, or extern
• Can have ref and out parameters
• If not implemented, the compiler removes the method call

Example:

public partial class DataProcessor
{
    public void ProcessData(string data)
    {
        Console.WriteLine("Processing data...");
        
        // Partial method call - only executed if implemented
        OnDataProcessingStarted(data);
        
        // Processing logic here
        var result = data.ToUpper();
        
        // Partial method call - only executed if implemented
        OnDataProcessingCompleted(result);
        
        Console.WriteLine($"Result: {result}");
    }
    
    // Partial method declarations
    partial void OnDataProcessingStarted(string data);
    partial void OnDataProcessingCompleted(string result);
}

// In another file, you can optionally implement the partial methods
public partial class DataProcessor
{
    partial void OnDataProcessingStarted(string data)
    {
        Console.WriteLine($"Starting to process: {data}");
    }
    
    partial void OnDataProcessingCompleted(string result)
    {
        Console.WriteLine($"Processing completed: {result}");
    }
}

Use Cases:

Partial Classes:

• Code generation (Entity Framework, WPF designers)
• Large classes that need organization
• Separating generated code from custom code
• Team development on the same class

Partial Methods:

• Code generation scenarios
• Optional customization points
• Performance optimization (unused methods are removed)
• Template method pattern implementation

Best Practices:

• Use partial classes to organize large classes logically
• Keep related functionality together in the same partial class
• Use partial methods for optional customization points
• Document when partial methods are expected to be implemented
• Be careful with partial classes in inheritance hierarchies