Blog
Mert Özen'in yazılım geliştirme, backend, frontend ve DevOps üzerine blog yazıları.
Design Principles Neden Var? Değişim, Bağımlılık ve SOLID'in Kısa Tarihi
Design principle'lar, değişimi pahalı yapan plansız bağımlılıkları adlandırmak ve onlara sınır çizmek için var: rigidity, fragility, immobility ve viscosity'nin ortak kökü bağımlılıktır. Parnas'ın information hiding'inden Feathers'ın SOLID kısaltmasına uzanan tarih ve serinin Bookstore sipariş-bildirim örneği.
Coupling ve Cohesion: İyi Tasarımın İki Ölçüsü, Connascence ve Law of Demeter
İyi tasarım, parçalar arası bağın (coupling) zayıf, parçanın içindeki bütünlüğün (cohesion) yüksek olmasıdır; connascence bu bağı türüne göre derecelendirir, Law of Demeter ise object'lerin birbirinin içine uzanmasını sınırlar. Coupling türleri ve cohesion seviyeleri, altı parametreli constructor'da connascence of position, TimeSpan(10) tuzağı ve Tell, Don't Ask ile cüzdan bakiyesini korumak.
Single Responsibility Principle: "Tek İş" Değil, Tek Actor
SRP "bir class tek şey yapar" demek değildir; Martin'in tanımıyla bir module tek bir actor'a, yani aynı değişikliği isteyen tek bir kişi ya da gruba karşı sorumlu olmalıdır. Muhasebenin bir değişikliğinin İK raporunu bozduğu Employee örneği, veriyi paylaşıp davranışı ayırmak, Facade, .NET'teki Stream/StreamWriter/Encoding ayrımı ve fragmentation tuzağı.
Open/Closed Principle: Değiştirmeden Genişletmek ve Spekülatif Genellik Tuzağı
OCP, yeni bir davranışı mevcut ve çalışan kodu açmadan, yeni bir implementation olarak ekleyebilmektir; ama her kod yalnızca belirli bir değişim eksenine karşı kapatılabilir. Büyüyen bildirim switch'ini INotificationChannel ve .NET 8 keyed services ile kapatmak, HttpClient'ın DelegatingHandler zinciri, Func ile hafif extension point'ler ve spekülatif genelliğin bedeli.
Liskov Substitution Principle: Behavioral Subtyping ve .NET'teki NotSupportedException'lar
LSP, bir subtype'ın derleyiciyi değil base type'ın contract'ını da karşılamasını ister: precondition güçlenmez, postcondition zayıflamaz, invariant ve history constraint korunur. Bookstore stok modülünde üç gerçek ihlal, T[] ve ReadOnlyCollection'ın IList<T>.Add'de fırlattığı NotSupportedException, Stream.CanSeek ile capability query ve contract'ı abstract bir xUnit test class'ıyla bütün implementation'lara karşı doğrulamak.
Interface Segregation Principle: Şişman Interface'ler ve Role Interface'ler
ISP, hiçbir client'ın kullanmadığı method'lara bağımlı olmaya zorlanmaması, interface'in class'a göre değil client'a göre (role interface) kesilmesidir. 14 method'luk IOrderRepository'ye eklenen tek method'un üç dosyayı kırması, okuma/yazma/rapor rollerine bölmek ve DI'da forwarding, .NET 10'da hâlâ ayrı duran IReadOnlyList<T> ile IList<T>, tek method'luk interface enflasyonu ve default interface method ile ISP'yi delmenin bedeli.
Dependency Inversion Principle: DIP, DI ve IoC Arasındaki Fark ve Composition Root
DIP, compile-time bağımlılığın detaydan abstraction'a doğru akmasını ve abstraction'ın onu kullanan tarafa ait olmasını ister; DI yalnızca bağımlılığı dışarıdan verme tekniğidir, IoC ise akışın framework'e geçmesidir. Interface'in hangi project'te durduğu, Program.cs'in composition root olarak kullanılması ve service locator'ın neden DIP'i boşa çıkardığı.
DRY, KISS ve YAGNI: Tekrar, Basitlik ve "Şimdilik Gerekmiyor"
DRY kodun değil bilginin tek kaynağı olmasıdır; farklı nedenlerle değişen iki kuralı aynı göründükleri için birleştirmek DRY değil, yanlış bir abstraction'dır. Metz'in wrong abstraction'dan geri dönüşü, rule of three, KISS'i CA1502 ile ölçmek ve Fowler'ın YAGNI için saydığı dört maliyet.
Composition over Inheritance: Fragile Base Class, Delegation ve Davranışı Takmak
Inheritance, subclass'ı base class'ın implementation detaylarına bağlar; base class'taki zararsız bir değişiklik subclass'ı sessizce bozabilir, composition ve delegation ise yalnız sözleşmeye bağımlı kalır. Fragile base class'ı gerçek çıktıyla göstermek, iki eksende büyüyen davranışlarda class patlaması ve inheritance'ın doğru olduğu yerler: Collection<T> hook'ları ve sealed.
Daha Az Bilinen Prensipler: Separation of Concerns, Least Astonishment, Fail Fast, CQS ve GRASP
SOLID dışındaki prensipler günlük kararların çoğunu verir: Fail Fast hatayı açılışta yakalar, CQS sorunun cevabı değiştirmesini engeller, GRASP de bir sorumluluğun hangi class'a ait olduğunu sorar. Options validation ile yazım hatasını yakalamak, Math.Round sürprizi, getter'da yan etki, Explicit Dependencies, Persistence Ignorance ve prensipler çatışınca karar vermek.
Component Prensipleri: .NET Solution'ını Project'lere Bölmek (REP, CCP, CRP, ADP, SDP, SAP)
Bir solution'ı project'lere bölerken birlikte değişen class'lar aynı project'te durmalı, bağımlılıklar döngüsüz ve stabil olana doğru akmalı, stabil project'ler de abstract olmalı. Herkesin bağımlı olduğu Common project'inin bedelini ölçmek, instability ve abstractness metriklerini gerçek bir solution'da hesaplamak ve main sequence'i doğru okumak.
Prensiplerin Eleştirisi: CUPID, Over-Engineering ve SOLID'in Gerçekten Gerektiği Yer
SOLID'in değeri bağlama bağlı: çok ekipli, uzun ömürlü ve sık değişen kodda değişim maliyetini düşürür, script, prototip ve küçük CRUD uygulamalarında ise çoğu zaman yalnız katman ekler. Aynı bildirim özelliğinin minimum, dengeli ve aşırı üç tasarımında push kanalı eklemenin ölçülen maliyeti, Dan North'un CUPID önerisi ve Ousterhout'un deep module uyarısı.