Tag: coding

Good software design isn’t just about writing code that works — it’s about writing clean, maintainable, and scalable code.
To achieve this, developers follow a set of guiding principles that help keep complexity low and quality high.
Here’s a consolidated list of the most important software design principles with explanations and C# examples.

---

1. 🧩 KISS (Keep It Simple, Stupid)

The KISS principle reminds us to keep software as simple as possible. Avoid unnecessary complexity, write clear code, and focus only on what’s needed.

// ❌ Bad: Over-engineered
if (user.Age > 18 && (user.Country == "US" || user.Country == "UK" || user.Country == "CA"))
{
    AllowAccess();
}
else
{
    DenyAccess();
}

// ✅ Good: Simple and clear
if (user.IsAdult())
{
    AllowAccess();
}

---

2. 🔁 DRY (Don’t Repeat Yourself)

The DRY principle means you should avoid code duplication.
Instead, encapsulate common logic in functions, classes, or constants.

// ❌ Bad: Duplicate logic
Console.WriteLine("Welcome, John");
Console.WriteLine("Welcome, Mary");

// ✅ Good: Reusable method
void Greet(string name)
{
    Console.WriteLine($"Welcome, {name}");
}

Greet("John");
Greet("Mary");

---

3. 🚫 YAGNI (You Aren’t Gonna Need It)

Don’t implement features “just in case.” Only build what you need now to keep the system simple and maintainable.

// ❌ Bad: Adding unnecessary parameters for future features
decimal CalculateDiscount(decimal price, string type = "standard", int loyaltyPoints = 0, bool seasonal = false, bool futureFeature = false)
{
    // Too much complexity
    return price;
}

// ✅ Good: Only what is needed now
decimal CalculateDiscount(decimal price, string type = "standard")
{
    return price;
}

---

4. 📐 SOLID Principles

SOLID is a collection of five principles for building maintainable and extensible object-oriented software:

• Single Responsibility Principle (SRP): A class should have only one reason to change.
• Open/Closed Principle (OCP): Classes should be open for extension but closed for modification.
• Liskov Substitution Principle (LSP): Subclasses should be usable in place of their base classes.
• Interface Segregation Principle (ISP): Clients shouldn’t be forced to depend on methods they don’t use.
• Dependency Inversion Principle (DIP): Depend on abstractions, not concrete implementations.

// ✅ Example: Dependency Inversion
public interface IMessageService
{
    void Send(string message);
}

public class EmailService : IMessageService
{
    public void Send(string message) 
    {
        Console.WriteLine($"Email sent: {message}");
    }
}

public class Notification
{
    private readonly IMessageService _service;

    public Notification(IMessageService service)
    {
        _service = service;
    }

    public void Notify(string message)
    {
        _service.Send(message);
    }
}

// Usage
var emailService = new EmailService();
var notification = new Notification(emailService);
notification.Notify("Hello, World!");

---

5. 🤔 Principle of Least Astonishment (POLA)

Software should behave in a way that is consistent with user expectations.
Use familiar terminology, intuitive design, and clear error messages.

// ❌ Bad: Confusing error
throw new Exception("ERR_451_USER_FAIL");

// ✅ Good: Clear error
throw new UnauthorizedAccessException("User authentication failed. Please check your password.");

---

6. 🧱 Principle of Modularity

Design software as independent, reusable modules. This makes it easier to maintain, test, and scale.

// Example project structure
- Auth/
- Payment/
- Notifications/

---

7. 🎭 Principle of Abstraction

Hide unnecessary details and expose only essential features.
Abstraction helps simplify usage and prevents users from depending on internal complexity.

public class EmailSender
{
    public void SendEmail(string to, string subject, string body)
    {
        // Hides SMTP details
        Console.WriteLine($"Sending email to {to}: {subject}");
    }
}

---

8. 🔒 Principle of Encapsulation

Encapsulation hides the internal state of an object and exposes behavior only through well-defined interfaces.

public class BankAccount
{
    private decimal _balance;

    public void Deposit(decimal amount)
    {
        _balance += amount;
    }

    public decimal GetBalance()
    {
        return _balance;
    }
}

---

9. 📉 Principle of Least Knowledge (Law of Demeter)

A module should know as little as possible about other modules. This reduces coupling and increases flexibility.

// ❌ Bad: Too much knowledge
var creditLimit = order.Customer.Account.CreditLimit;

// ✅ Good: Ask the object directly
var creditLimit = order.GetCustomerCreditLimit();

---

10. 🔗 Low Coupling & High Cohesion

– Low Coupling: Modules should have minimal dependencies on each other.
– High Cohesion: Each module should serve a single, well-defined purpose.

// ✅ Example: High cohesion, low coupling
public class InvoiceGenerator
{
    public string Generate(Order order)
    {
        return $"Invoice for {order.Id}";
    }
}

public class EmailService
{
    public void SendInvoice(string invoice)
    {
        Console.WriteLine($"Invoice sent: {invoice}");
    }
}

---

🎯 Conclusion

These principles are not strict rules but guidelines to help you write clean, scalable, and maintainable software.
By applying KISS, DRY, YAGNI, SOLID, and others consistently, you’ll reduce bugs, simplify maintenance, and build systems that are easier to extend as requirements evolve.