SOLID yazı dizisinin sonuncusu olan Dependency Inversion yazısından merhabalar! Bu yazıda sıklıkla Dependency Injection (DI) ile karıştırılan Dependency Inversion (DIP) prensibini inceleyeceğiz. Temelde “soyutlamaya bağlı olma” felsefesine dayanan bu prensip, sınıflar arasındaki sıkı bağımlılıkları (tight coupling) kırmayı hedefler. Yüksek bağımlılık; kodun bir parçasını diğerlerinden izole edememek ve değişime karşı direnç gösteremeyen bir yapı kurmak demektir.
Dependency Inversion Nedir?
Bu prensibi daha somut bir örnekle ele alalım: Bir lambayı evin elektrik tesisatına bağlamak istediğinizi hayal edin. Lambanın kablolarını duvarın içindeki elektrik hattına doğrudan bağlarsak, lambayı değiştirmek istediğimizde tüm duvarı kırmamız, kabloları kesmemiz ve yeni lambayı tekrar bağlamamız gerekir. Bu durum da aslında ‘Sıkı Bağımlılık’ (Tight Coupling) dediğimiz durumdur.
Oysa gerçek hayatta duvara bir priz (interface) koyuyoruz. Lamba, elektriğin kaynağına değil, o prize uyumlu olan fişe (abstraction) bağımlı oluyor. Dependency Inversion tam olarak budur:
- Üst Seviye Modül (Lamba): Alt seviye modülün detaylarıyla (duvarın içindeki kablo tipi) ilgilenmez.
- Alt Seviye Modül (Elektrik Tesisatı): Doğrudan lambaya bağlı değildir.
- Soyutlama (Priz/Fiş): Her iki tarafın da üzerinde anlaştığı ortak standarttır.
Böylece priz standart kaldığı sürece, istersek lamba veya bilgisayarı şarja takabiliriz. Aynı şekilde kodunuzda bir değişikliğe gittiğinizde tüm sistemi bağımlılıklarından sökmenize gerek kalmaz.
Örnek olarak DIP kurallarına uymayan şu yapıyı inceleyelim;
internal class Order
{
public Guid Id { get; set; }
}
internal class FileLogger
{
public void Log(string message)
{
// Simulate logging to a file
StreamWriter writer = new StreamWriter("log.txt");
writer.WriteLine(message);
writer.Flush();
writer.Close();
}
}
internal class DBLogger
{
public void Log(string message)
{
SqlConnection conn = new SqlConnection();
SqlCommand cmd = new SqlCommand("Insert", conn);
conn.Open();
cmd.ExecuteNonQuery();
conn.Close();
}
}
internal class OrderManager
{
FileLogger fileLogger;
DBLogger dbLogger;
public OrderManager()
{
fileLogger = new FileLogger();
dbLogger = new DBLogger();
}
public void Add(Order order)
{
// Add the order
fileLogger.Log($"Order {order.Id} added.");
dbLogger.Log($"Order {order.Id} added.");
}
public void Update(Order order)
{
// Update the order
fileLogger.Log($"Order {order.Id} updated.");
dbLogger.Log($"Order {order.Id} updated.");
}
public void Delete(Order order)
{
// Delete the order
fileLogger.Log($"Order {order.Id} deleted.");
dbLogger.Log($"Order {order.Id} deleted.");
}
}
Örneğin bir sipariş yönetim sistemimiz olsun. Bu sistemde loglama işlemini iki farklı seviyede yapıyor olalım. Burada yaşayacağımız en büyük sorun, soyutlama (interface) olmadığı için OrderManager sınıfının loglama araçlarının somut detaylarına göbekten bağlı olmasıdır. Bu durum loglama kısmında yapılacak ufacık bir değişikliğin bile sistemi bozmasına neden olabilir. Öte yandan projenin ilerleyen fazlarında ADO.NET yerine Entity Framework’e geçiş yapılmak istediğimizde tüm DBLogger referanslarının düzenlenmesi gerekebilir.
Oysa ILogger şeklinde bir interface’e sahip olsaydık, bu interface’e loglama görevinin verildiği net bir şekilde anlardık. Loglama işleminin nasıl olacağına FileLogger ve DBLogger sınıfları içerisinde detaylandırabilirdik.
Dependency Inversion Nasıl Çalışır?
DIP’nin temel fikri; karmaşık bir mantık içeren üst seviye modülleri kolayca yeniden kullanılabilir olması ve alt seviyedeki modüllerde olabilecek değişikliklerden etkilenmemesidir. Bunu oluşturmak için üst ve alt seviye modülleri arasında bağımlılığı azaltacak bir soyutlama gerekir. Buna bağlı olarak DIP 2 aşamadan oluşur.
- Üst seviyede modüller alt seviye modüllere bağlı olmamalıdır; her ikisi de soyutlamalara bağlı olmalıdır.
- Soyutlamalar detaylara bağımlı olmamalıdır; detaylar soyutlamaya bağımlı olmalıdır.
internal class Order
{
public Guid Id { get; set; }
}
internal interface ILogger
{
void Log(string message);
}
internal class FileLogger : ILogger
{
public void Log(string message)
{
StreamWriter writer = new StreamWriter("log.txt");
writer.WriteLine(message);
writer.Flush();
writer.Close();
}
}
internal class DBLogger : ILogger
{
public void Log(string message)
{
SqlConnection conn = new SqlConnection();
SqlCommand cmd = new SqlCommand("Insert", conn);
conn.Open();
cmd.ExecuteNonQuery();
conn.Close();
}
}
internal class OrderManager
{
public ILogger _logger;
public OrderManager(ILogger logger)
{
_logger = logger;
}
public void Add(Order order)
{
// Add the order
_logger.Log($"Order {order.Id} added.");
}
public void Update(Order order)
{
// Update the order
_logger.Log($"Order {order.Id} updated.");
}
public void Delete(Order order)
{
// Delete the order
_logger.Log($"Order {order.Id} deleted.");
}
}
OrderManager artık hangi loglama metodunun çağırıldığını ve o metodun nasıl çalıştığını bilmiyor sadece bir ILogger istiyor. Bu sayede hem manager sınıf içerisindeki tekrar eden kod yapısını azalttık, hem de ileride yeni bir loglama metodu eklenir veya varolan metot güncellenirse bu sınıf içerisinde bir değişiklik yapılmasını engelledik.
Bu yaklaşımla 3 önemli kazanım elde etmiş olduk.
- Esneklik: İlerleyen fazlarda farklı bir loglama metodu eklemek istersek OrderManager’a dokunmamıza gerek kalmayacak. (Open/Closed)
- Test Edilebilirlik: Unit test yazarken gerçek bir veri tabanı yerine kolayca mock bir logger entegre edebiliriz.
- Güven: Tüm logger sınıflarımız ILogger interface’ine bağlı kaldığı için birbirlerinin yerine kullanılabilirler. (Liskov Substition)
SOLID serimin bu son yazısıyla, daha sürdürülebilir ve esnek kod temelleri atmanın yollarını incelemiş olduk. SOLID’in diğer kurallarını blog yazılarımdan okuyabilir, kullandığım örnekleri Github hesabımdan inceleyebilirsiniz. Bir sonraki yazıya kadar kendinize çok iyi bakın! 😊
