Mert Özen Her Satırda Daha İleri

Blog

Mert Özen'in yazılım geliştirme, backend, frontend ve DevOps üzerine blog yazıları.

Seriler
502 yazı bulundu
Adapter Pattern: Third-Party SDK'yı Kendi Interface'ine Uydurmak
Yazılım Tasarımı SERİ 07

Adapter Pattern: Third-Party SDK'yı Kendi Interface'ine Uydurmak

Adapter, değiştiremediğin bir class'ı client'ın beklediği interface'e uydurur; C#'ta neredeyse her zaman object adapter, yani composition ile. İki hayalî ödeme SDK'sını tek IPaymentGateway'e bağlamak, callback'i TaskCompletionSource ile Task'a çevirmek, hata kodlarını domain exception'larına eşlemek ve iki adapter'ı aynı contract test ile doğrulamak.

7 Kas 2026 14 dk 4
Prototype Pattern: record ile with, Shallow ve Deep Copy ve ICloneable'ın Neden Önerilmediği
Yazılım Tasarımı SERİ 06

Prototype Pattern: record ile with, Shallow ve Deep Copy ve ICloneable'ın Neden Önerilmediği

Prototype, yeni object'i sıfırdan kurmak yerine konfigüre edilmiş bir örneği kopyalayarak üretir; C#'ta record'ların with expression'ı bunu runtime tipini koruyarak yapar ama kopya shallow'dur. Prototype registry, copy constructor ile kontrollü deep copy, ICloneable'ın belirsiz sözleşmesi, JSON ile kopyalamanın ölçülmüş bedeli ve with'in doğrulamayı atlayan tuzakları.

7 Kas 2026 16 dk 5
Builder Pattern: Fluent Builder, WebApplicationBuilder ve Object Initializer ile required'ın Yetmediği Yer
Yazılım Tasarımı SERİ 05

Builder Pattern: Fluent Builder, WebApplicationBuilder ve Object Initializer ile required'ın Yetmediği Yer

required, init ve object initializer çok parametreli constructor'ı okunur kılar ama alanlar arası kuralları, adım sırasını ve parça parça biriken değişmez sonucu çözmez; Builder bu kuralları tek bir Build() anında uygular. Record'da with'in kuralı atlaması, GoF'un director'lı Builder'ı ile fluent builder farkı, UriBuilder, connection string builder, ImmutableArray builder, HostApplicationBuilder ve step builder gerçek çıktılarla.

7 Kas 2026 16 dk 6
Abstract Factory: Birbirine Uyumlu Object Ailelerini Birlikte Üretmek
Yazılım Tasarımı SERİ 04

Abstract Factory: Birbirine Uyumlu Object Ailelerini Birlikte Üretmek

Abstract Factory, birbiriyle uyumlu olması gereken ürünleri (blob storage, queue, secret store gibi) tek bir factory'den üreterek geçersiz kombinasyonları imkânsız kılar; bedeli, aileye yeni ürün eklemenin bütün factory'leri değiştirmesidir. Configuration ile aile seçimi, ADO.NET'in DbProviderFactory'si ve CanCreateBatch, keyed services ile tenant başına factory gerçek çıktılarla.

7 Kas 2026 15 dk 4
Factory Method ve Static Factory: Oluşturmayı Alt Class'a ya da Tek Bir Method'a Bırakmak
Yazılım Tasarımı SERİ 03

Factory Method ve Static Factory: Oluşturmayı Alt Class'a ya da Tek Bir Method'a Bırakmak

GoF Factory Method hangi ürünün oluşturulacağını alt class'a bırakır; static factory method ise constructor'ın yerine geçen, adı olan, cache'leyebilen ve gizli alt tip döndürebilen tek bir method'dur. Constructor'dan çağrılan factory method hatası ve CA2214, DbConnection.CreateDbCommand, ILoggerFactory ve IHttpClientFactory, DI'da Func<T>, ActivatorUtilities, keyed services ve IDisposable ürünlerin sahipliği gerçek çıktılarla.

7 Kas 2026 16 dk 5
Singleton Pattern: Thread-Safe Lazy<T>, Static Field ve Neden DI Singleton Lifetime Daha İyi
Yazılım Tasarımı SERİ 02

Singleton Pattern: Thread-Safe Lazy<T>, Static Field ve Neden DI Singleton Lifetime Daha İyi

Tek instance gerekiyorsa en temiz yol klasik Singleton değil, DI container'da AddSingleton ile kaydetmektir: tek instance garantisi aynı kalır, global erişim ve gizli bağımlılık ortadan kalkar. Naif Singleton'daki race, double-checked locking'in tarihi, static readonly ve beforefieldinit, Lazy<T>'nin exception caching'i, captive dependency ve singleton içindeki paylaşılan state gerçek çıktılarla.

7 Kas 2026 14 dk 6
Design Pattern Nedir? GoF Kataloğu, Pattern Anatomisi ve Modern Dillerde Kaybolan Pattern'ler
Yazılım Tasarımı SERİ 01

Design Pattern Nedir? GoF Kataloğu, Pattern Anatomisi ve Modern Dillerde Kaybolan Pattern'ler

Design pattern, belli bir bağlamda tekrar eden bir tasarım problemine verilmiş, adı, rolleri ve bedeli (consequences) belli bir çözümdür; ezberlenecek bir diyagram değildir. Alexander'dan GoF'a pattern fikri, GoF'un 13 bölümlük template'i, purpose × scope haritası ve Norvig'in tespitiyle C#'ta yield, event ve lambda'ya dönüşüp görünmez olan pattern'ler.

7 Kas 2026 14 dk 6
Uygulamalı Clean Code: Legacy OrderService'i Adım Adım Temizlemek
Yazılım Tasarımı SERİ 14

Uygulamalı Clean Code: Legacy OrderService'i Adım Adım Temizlemek

Legacy kodu temizlemenin güvenli yolu önce küçük bir seam ve characterization test'lerle mevcut davranışı sabitlemek, sonra her adımı ayrı commit'te yapmak ve davranış değişikliklerini ayrı fix commit'lerine ayırmaktır. Yazıda 609 satırlık OrderService 16 commit'te, her commit'te testler yeşilken temizleniyor; en yüksek Cognitive Complexity 92'den 10'a iniyor, bilinçli bırakılan smell'ler de gerekçesiyle listeleniyor.

7 Kas 2026 14 dk 3
Clean Code Tartışması: Ousterhout, Muratori ve Kuralların Sınırları
Yazılım Tasarımı SERİ 13

Clean Code Tartışması: Ousterhout, Muratori ve Kuralların Sınırları

Ousterhout ve Martin aynı hedefte, okuyucunun yükünü azaltmakta anlaşıyor; ayrıldıkları yer method'ları ne kadar böleceğin, comment'lerin değeri ve TDD. Yazı 2024–25 tartışmasını, Muratori'nin performans eleştirisini (C#'ta BenchmarkDotNet ile tekrarlanmış hâliyle) ve qntm'nin kitap eleştirisini iki tarafın kendi kaynaklarından özetliyor.

7 Kas 2026 13 dk 6
Code Smell Kataloğu: C# Kodunda Kokuyu Tanımak
Yazılım Tasarımı SERİ 12

Code Smell Kataloğu: C# Kodunda Kokuyu Tanımak

Code smell, genellikle daha derin bir tasarım problemine işaret eden yüzeysel bir belirtidir; teşhis değil, bakılacak yeri gösterir. Yazı Fowler'ın 2. baskıdaki 24 smell'ini Mäntylä'nın beş grubuyla haritalıyor, her birini legacy OrderService.cs'te arıyor ve SonarAnalyzer'ın hangilerini yakalayıp hangilerini kaçırdığını gerçek çıktıyla gösteriyor.

7 Kas 2026 12 dk 5
Simple Design'ın Dört Kuralı: Testler Geçer, Niyet Açık, Tekrar Yok, En Az Eleman
Yazılım Tasarımı SERİ 11

Simple Design'ın Dört Kuralı: Testler Geçer, Niyet Açık, Tekrar Yok, En Az Eleman

Kent Beck'in simple design kuralları öncelik sırasıyla şunlar: testler geçer, niyet açıktır, tekrar yoktur, eleman sayısı en azdır. Yazıda bir kupon indirimi hesabı bu dört soruyla adım adım büyütülüyor, tesadüfi benzerlik ile gerçek tekrar ayrılıyor ve aynı testleri geçen aşırı genelleştirilmiş bir versiyonun bedeli gösteriliyor.

7 Kas 2026 13 dk 4
Temiz Test Kodu: F.I.R.S.T., Okunabilir Assert ve Test Data Builder
Yazılım Tasarımı SERİ 10

Temiz Test Kodu: F.I.R.S.T., Okunabilir Assert ve Test Data Builder

Temiz test hızlı, bağımsız, her gün aynı sonucu veren, kendini doğrulayan ve zamanında yazılmış testtir (F.I.R.S.T.); legacy OrderService testleri DateTime.Now yüzünden cumartesi, static Db yüzünden sıraya göre kırılıyor. TimeProvider ve FakeTimeProvider, test data builder, cümle gibi okunan test adları ve kırıldığında sebebi söyleyen assert'lerle aynı kuralları temiz testlere çeviriyoruz.

7 Kas 2026 11 dk 5
Blog Haritası