DEV Community: Nawaf Mahsoun

🚀 Exploring the Power of init and private set in .NET Development 💎🔒

Nawaf Mahsoun — Sat, 27 Sep 2025 09:32:16 +0000

In my .NET journey, I’ve explored the subtle yet impactful world of property setters, where the choice between init and private set can make your domain models safer and your code cleaner. These concepts highlight the balance between immutability and controlled flexibility.

🔍 Understanding the Basics:

init 💎 allows setting a property only during initialization (constructor or object initializer). After that, it’s read-only.

private set **🔒 allows the property to change, but only within the **class, not from outside.

Why does it matter?
Using the right setter pattern prevents accidental mutations and enforces your design intent — crucial for building robust and maintainable applications.

🎯 Let’s Illustrate with an Example:
`
public class Asset
{
public Guid Id { get; init; }
public DateTime CreatedAt { get; init; }
public string? CreatedBy { get; init; }

public DateTime? UpdatedAt { get; private set; }
public string? UpdatedBy { get; private set; }

public void MarkUpdated(string user)
{
    UpdatedAt = DateTime.UtcNow;
    UpdatedBy = user;
}

}
`

💡 Expert Insight:

Use

init

for values that should never change after creation (Id, CreatedAt).

Use private

set

domain methods for values that evolve (UpdatedAt, Status).

EF Core still works seamlessly with init properties during materialization thanks to reflection.

🤔 Share Your Experience:
How do you handle immutability vs flexibility in your .NET domain models? Any tips or patterns that improved your design? Join the conversation below! 👇

DotNET #CSharp #SoftwareDevelopment #CleanArchitecture #BestPractices #CodingTips

🚀 Unleash the Power of Delegates in C# 🚀

Nawaf Mahsoun — Tue, 29 Apr 2025 17:10:00 +0000

Delegates act as “remote controls” for methods in C#, letting you treat behavior as a first-class object. Pass them around, invoke them anywhere, and swap implementations at runtime—without tightly coupling your components.

🔧 Decoupling Components

By depending on a delegate instead of calling a specific method directly, your code becomes far more flexible and testable. You can inject custom logic, swap out implementations, or mock callbacks—all without touching the original source.
🎯 Simplifying Events & Callbacks

Events in C# are built on multicast delegates—subscribe, unsubscribe, and broadcast with ease. -Callbacks empower consumers to decide “what happens next,” ideal for asynchronous workflows, progress reporting, and more.

💡** Built-In Delegate Shortcuts**

No need to define your own delegate types every time. The BCL gives you:

`Action<T…>` for methods that return `void`

`Func<T…, TResult>` for methods that return a value

`Predicate<T>` for methods that return a `bool`

Action<string> log       = msg => Console.WriteLine($"📢 {msg}");
Func<int, int, int> add  = (a, b) => a + b;
Predicate<int> isEven    = n => n % 2 == 0;

🛠️ Real-World Example

// 1) Define a custom delegate
public delegate void IntAction(int x);

// 2) Bind it to any matching method or lambda
IntAction printer  = x => Console.WriteLine($"Number: {x}");
IntAction doubler  = x => Console.WriteLine($"Double: {x * 2}");

// 3) Compose multiple methods
printer += doubler;

// 4) Invoke all subscribers
printer(5);

// ▶️ Output:
// Number: 5
// Double: 10

Key Takeaway:
Leveraging delegates transforms your C# code into a more expressive, extensible, and maintainable design. Master them, and watch your software architectures evolve! 💪✨

CSharp #DotNet #CleanCode #Delegates #SoftwareCraftsmanship

When a Tiny Bug in C# Breaks Everything: London vs. Classical Testing

Nawaf Mahsoun — Tue, 22 Apr 2025 15:15:21 +0000

Ever had a tiny bug in your C# code crash your entire test suite? 😩 Let’s break down why that happens—and how your testing style (London vs. Classical) changes your debugging experience.

Inspired by “Unit Testing: Principles, Practices, and Patterns” by Vladimir Khorikov, here’s a relatable C# example to highlight the difference!

🛒 The Scenario: A Simple Shopping Cart System

Imagine an e-commerce setup with:

Cart– Manages items, calculates totals
OrderProcessor– Handles orders (depends on Cart)
PaymentService– Processes payments (depends on OrderProcessor)

Now suppose you accidentally break the Cartclass. How does each testing style react?

1️⃣ London-Style Tests (Isolated with Mocks)

In London-style testing, dependencies are mocked, so only tests for the broken component (Cart) fail.

// London-style test for OrderProcessor (using Moq)
[Fact]
public void OrderProcessor_CreatesInvoice_ReturnsCorrectTotal()
{
    var mockCart = new Mock<ICart>();
    mockCart.Setup(c => c.GetTotal()).Returns(100); // Mocked Cart
    var processor = new OrderProcessor(mockCart.Object);

    var result = processor.CreateInvoice();    
    Assert.Equal(100, result); // ✅ Passes—even if the REAL Cart is broken!
}

✅ Pros: Fast, focused tests. Easy to pinpoint failures (e.g., Cart only).
❌ Cons: Can give false confidence—misses integration bugs.

In classical testing, real dependencies are used. So if Cartis broken, tests for OrderProcessorand even PaymentServicestart failing too.

// Classical test for OrderProcessor
[Fact]
public void OrderProcessor_CreatesInvoice_ReturnsCorrectTotal()
{
    var cart = new Cart(); // Real Cart instance
    cart.AddItem("Book", 50);
    var processor = new OrderProcessor(cart);

    var result = processor.CreateInvoice();    
    Assert.Equal(50, result); // ❌ FAILS if Cart.GetTotal() is broken!
}

✅ Pros: Detects integration issues early.
❌ Cons: One bug can trigger a failure avalanche 🌊

🧠 Why This Matters

London-style tests are precise and fast—but can miss real-world breakages.
Classical tests offer stronger guarantees—but debugging them can feel like “whack-a-mole.” 🔨

📘 Khorikov’s Insight

Classical tests align better with the Test Pyramid, emphasizing integration and reducing over-reliance on mocks.
A failure avalanche often points to mission-critical code. If breaking Cartcauses 50 failures? That’s a signal—it’s important!

✅ Silver Linings

Run tests frequently: If things break, you’ll know you broke it 😅
Volume of failure = Importance: Failures are feedback, not frustration

💬 Final Thought

Which testing style do you lean toward?

🔍 *London *– for precision and speed?
🌊 *Classical *– for real-world system feedback?

Let’s discuss below—and if you haven’t read Khorikov’s book yet, seriously, it’s a game-changer. 🎯

SoftwareEngineering #Testing #DotNet #CSharp #CleanCode #TDD

Understanding Boxing and Unboxing in .NET 🥊📦

Nawaf Mahsoun — Mon, 31 Mar 2025 16:33:00 +0000

As a .NET developer, I’ve come to appreciate how small coding decisions can ripple into significant performance impacts. Today, let’s unpack boxing and unboxing—subtle operations that balance convenience with efficiency.
What are Boxing and Unboxing?
Boxing
Boxing is the process of converting a value type (such as an intor struct) into a reference type (object). This operation involves:

1.Heap Allocation: Allocates memory on the heap.
2.Data Copy: Copies the value type’s data from the stack to the heap.
3.Reference Creation: Creates a reference to the new heap-allocated
object..

Unboxing
Unboxing is the reverse process—extracting the value type from the heap-stored object back to the stack. Key points include:

1.Explicit Casting: An explicit cast is required, for example (int)boxedNumber.
2.Type Safety: Incorrect casts result in an InvalidCastException.

Why Should You Care?

Boxing and unboxing introduce several performance overheads:

.Memory Pressure: Heap allocations increase garbage collection workload.
.CPU Cost: Copying data between the stack and the heap consumes extra CPU cycles.
.Type Safety Risks: Unboxing mandates precise casting, increasing the risk of runtime exceptions.

Code Example

// Value type on the stack  
int number = 42;  

// Boxing: converting int to object (heap allocation)
object boxedNumber = number;  

// Unboxing: extracting int from the object (requires explicit cast)
int unboxedNumber = (int)boxedNumber;

The Danger Zone

// Incorrect cast: throws InvalidCastException!
double invalidUnbox = (double)boxedNumber;

Best Practices to Avoid Unnecessary Boxing

Prefer Generics Over Non-Generic Collections

 // Using ArrayList causes boxing
 ArrayList list = new ArrayList();
  list.Add(42); // Boxing happens here!

 // Using List<T> avoids boxing
 List<int> genericList = new List<int>();
 genericList.Add(42);  // No boxing occurs

Avoid Object Parameters Avoid passing value types as objectin performance-critical code.

3.Be Cautious with Interfaces
Casting a value type to an interface (e.g., IFormattable) will trigger boxing.
Performance Impact

In a loop of 10 million iterations:

Without boxing: ~50 ms
With boxing: ~500 ms (10x slower!)

Tools like BenchmarkDotNet or the IL Disassembler can help identify hidden boxing in your code.

Have you encountered unexpected boxing/unboxing issues?

What strategies do you use to minimize heap allocations?
Any war stories or optimization tricks? Share below! 👇