Bağımlılığın tersine çevrilmesi ilkesi - Vikipedi
İçeriğe atla
Ana menü
Gezinti
  • Anasayfa
  • Hakkımızda
  • İçindekiler
  • Rastgele madde
  • Seçkin içerik
  • Yakınımdakiler
Katılım
  • Deneme tahtası
  • Köy çeşmesi
  • Son değişiklikler
  • Dosya yükle
  • Topluluk portalı
  • Wikimedia dükkânı
  • Yardım
  • Özel sayfalar
Vikipedi Özgür Ansiklopedi
Ara
  • Bağış yapın
  • Hesap oluştur
  • Oturum aç
  • Bağış yapın
  • Hesap oluştur
  • Oturum aç

İçindekiler

  • Giriş
  • 1 Bağımlılığın soyutlama ile azaltılması
    • 1.1 Kod Örnekleri
      • 1.1.1 Kötü Tasarım (DIP'yi İhlal Eden)
      • 1.1.2 İyi Tasarım (DIP Uyumlu)
    • 1.2 Faydalar
  • 2 Geleneksel katmanlı yapı
  • 3 Bağımlılığı tersine çevirme deseni
  • 4 Genellemenin dezavantajları
  • 5 Kullanım örnekleri
    • 5.1 Soybilim (genealoji) modülü
    • 5.2 Uzak dosya sunucusu istemcisi
    • 5.3 Model-Görünüm-Denetleyici (MVC)
  • 6 İlgili tasarım desenleri
  • 7 Tarihçe
  • 8 Dış bağlantılar
  • 9 Kaynakça

Bağımlılığın tersine çevrilmesi ilkesi

  • Català
  • Deutsch
  • English
  • Español
  • فارسی
  • Français
  • Magyar
  • İtaliano
  • 日本語
  • 한국어
  • Português
  • Русский
  • Українська
  • 中文
Bağlantıları değiştir
  • Madde
  • Tartışma
  • Oku
  • Değiştir
  • Kaynağı değiştir
  • Geçmişi gör
Araçlar
Eylemler
  • Oku
  • Değiştir
  • Kaynağı değiştir
  • Geçmişi gör
Genel
  • Sayfaya bağlantılar
  • İlgili değişiklikler
  • Kalıcı bağlantı
  • Sayfa bilgisi
  • Bu sayfayı kaynak göster
  • Kısaltılmış URL'yi al
  • Karekodu indir
Yazdır/dışa aktar
  • Bir kitap oluştur
  • PDF olarak indir
  • Basılmaya uygun görünüm
Diğer projelerde
  • Vikiveri ögesi
Görünüm
Vikipedi, özgür ansiklopedi
(DIP sayfasından yönlendirildi)
SOLID
  • Tek sorumluluk ilkesi
  • Açıklık-kapalılık ilkesi
  • Liskov'un yerine geçme ilkesi
  • Arayüz ayrımı ilkesi
  • Bağımlılığın tersine çevrilmesi ilkesi
  • g
  • t
  • d

Bağımlılıkların tersine çevrilmesi ilkesi (İngilizce: Dependency Inversion Principle - DIP), nesne yönelimli programlamada kullanılan temel tasarım örüntülerinden biridir. Bu ilkeye göre:

Üst düzey modüller, karmaşık iş mantığını içeren bileşenler olup, kolayca yeniden kullanılabilir olmalı ve alt düzey modüllerdeki (yardımcı işlevleri sağlayan detaylar) değişikliklerden doğrudan etkilenmemelidir.

Bu bağımsızlığı sağlamak için, her iki modül seviyesi de soyutlamalara (abstract interface’ler veya temel sınıflar) bağlı olmalı, böylece modüller arasındaki doğrudan bağımlılık ortadan kaldırılmalıdır.

Bu yaklaşım, sistemlerin esnekliğini artırır ve sürdürülebilir kod yazımını destekler.[1]

Bağımlılıkların tersine çevrilmesi ilkesi şu iki ana maddeyle özetlenir:

  1. Yüksek seviyeli modüller, düşük seviyeli modüllerden hiçbir şey ithal etmemelidir. Her ikisi de soyutlamalara (örneğin arayüzlere) bağımlı olmalıdır.
  2. Soyutlamalar alt seviye modüllere bağlı olmamalıdır. Bunun tersine, alt seviye modüller soyutlamalara(arayüzlere) bağlı olmalıdır.

Bu prensip, hem yüksek hem de düşük seviyeli modüllerin aynı soyutlamaya dayanmasını gerektirerek, geleneksel nesne yönelimli programlamaya farklı bir bakış sunar.[2]

Bağımlılığın soyutlama ile azaltılması

[değiştir | kaynağı değiştir]

Yüksek seviyeli ve düşük seviyeli modüller arasındaki etkileşim bir soyutlama üzerinden tasarlandığında, hem bağımlılık azalır hem de sistemin yeniden kullanılabilirliği ve sürdürülebilirliği artar. Bu yaklaşım aynı zamanda iç içe geçmiş karmaşık bağımlılıkları da soyutlama sayesinde sadeleştirir.

Kod Örnekleri

[değiştir | kaynağı değiştir]

Kötü Tasarım (DIP'yi İhlal Eden)

[değiştir | kaynağı değiştir]

Aşağıdaki örnekte, üst seviye `ReportService` sınıfı, alt seviye `PDFReportGenerator` sınıfına doğrudan bağımlıdır:

// Alt seviye modül
class PDFReportGenerator {
    public void generatePDF(String content) {
        System.out.println("PDF oluşturuluyor: " + content);
    }
}
// Üst seviye modül (DIP ihlali)
class ReportService {
    private PDFReportGenerator pdfGenerator = new PDFReportGenerator();
    
    public void createReport(String data) {
        pdfGenerator.generatePDF(data);
    }
}

Bu tasarımda, rapor formatı değiştiğinde (örneğin HTML formatında bir rapor eklenmesi gerekirse) ReportService sınıfı değiştirilmek zorunda kalacaktır.

İyi Tasarım (DIP Uyumlu)

[değiştir | kaynağı değiştir]

DIP uygulamak için bir arayüz tanımlayalım:

// Soyutlama (Arayüz)
interface ReportGenerator {
    void generate(String content);
}

// Alt seviye modül - 1
class PDFReportGenerator implements ReportGenerator {
    @Override
    public void generate(String content) {
        System.out.println("PDF oluşturuluyor: " + content);
    }
}

// Alt seviye modül - 2
class HTMLReportGenerator implements ReportGenerator {
    @Override
    public void generate(String content) {
        System.out.println("HTML oluşturuluyor: " + content);
    }
}

// Üst seviye modül (DIP uyumlu)
class ReportService {
    private ReportGenerator reportGenerator;
    
    public ReportService(ReportGenerator generator) {
        this.reportGenerator = generator;
    }
    
    public void createReport(String data) {
        reportGenerator.generate(data);
    }
}

// Kullanım
public class Main {
    public static void main(String[] args) {
        ReportService pdfService = new ReportService(new PDFReportGenerator());
        pdfService.createReport("Satış verileri");
        
        ReportService htmlService = new ReportService(new HTMLReportGenerator());
        htmlService.createReport("Satış verileri");
    }
}

Bu tasarımda:

ReportService, sadece ReportGenerator arayüzüne bağlıdır

Yeni rapor formatları eklemek için mevcut kod değiştirilmez (Açıklık-kapalılık ilkesi)

Bağımlılıklar constructor üzerinden enjekte edilir (Bağımlılık enjeksiyonu)

Faydalar

[değiştir | kaynağı değiştir]

Değişime direnç: Alt seviye modüller değişse bile üst seviye etkilenmez

Test edilebilirlik: Mock nesnelerle kolay test imkanı

Esneklik: Yeni implementasyonlar sisteme kolayca eklenebilir

Geleneksel katmanlı yapı

[değiştir | kaynağı değiştir]
Geleneksel bağımlılık ilişkileri

Geleneksel mimaride düşük seviyeli bileşenler (örneğin, yardımcı kütüphaneler) doğrudan yüksek seviyeli bileşenler (örneğin, politika katmanı) tarafından kullanılır. Bu yapı, yüksek seviyeli bileşenlerin yeniden kullanımını sınırlar.[1]

Bağımlılığı tersine çevirme deseni

[değiştir | kaynağı değiştir]
Soyutlama ile tersine çevrilmiş bağımlılık ilişkileri

Bu desende, hem yüksek hem de düşük seviyeli katmanlar ortak bir soyutlama katmanına bağımlıdır. Somut uygulamalar bu soyutlamaları uygular ve böylece yüksek seviyeli modüller doğrudan alt seviyelere bağlı olmadan çalışabilir.

Genellemenin dezavantajları

[değiştir | kaynağı değiştir]

Bağımlılığı tersine çevirme prensibi çoğu zaman tüm modüller arasında uygulanması gereken genel bir prensip olarak görülür. Ancak bu genellemenin bazı sınırlamaları vardır:

  • Yalnızca soyutlama oluşturmak, bağımlılığı azaltmaz.
  • Gereksiz soyutlamalar kodun anlaşılabilirliğini azaltır.
  • Her yerde arayüz kullanmak, fazladan fabrika sınıfları ve bağımlılık enjeksiyonu araçları gerektirir.
  • Bu durum, dili etkin kullanmayı da sınırlandırabilir.

Kullanım örnekleri

[değiştir | kaynağı değiştir]

Soybilim (genealoji) modülü

[değiştir | kaynağı değiştir]

Bir soybilim sistemi, bireyler arasındaki ilişkileri bir grafik yapısında saklayabilir. Ancak bazı uygulamalar, bu ilişkileri daha soyut ve basit yollarla sorgulamak isteyebilir. Bu nedenle, soybilim modülü, karmaşık iç yapıyı gizleyip yüksek seviyeli modüllere sade bir arayüz sağlayarak daha az bağımlı hale gelir.

Uzak dosya sunucusu istemcisi

[değiştir | kaynağı değiştir]

Bir istemci uygulaması, yerel veya uzak dosya sistemleriyle aynı soyut arayüzü kullanarak çalışacak şekilde tasarlanabilir. Böylece, uygulama belgeleri hem yerel hem uzak ortama aynı arayüzle kaydedebilir.

Model-Görünüm-Denetleyici (MVC)

[değiştir | kaynağı değiştir]

Model-Görünüm-Denetleyici yapısı, görünüm ve iş mantığı katmanlarını soyut arayüzler üzerinden bağlayarak bağımlılığı azaltır. Denetleyici katman yalnızca arayüzlere bağlıdır ve uygulamanın başka bir kısmına doğrudan bağlılık içermez.

İlgili tasarım desenleri

[değiştir | kaynağı değiştir]
  • Adaptör deseni
  • Bağımlılık enjeksiyonu
  • Servis bulucu deseni
  • Strateji deseni
  • Fabrika metot deseni

Tarihçe

[değiştir | kaynağı değiştir]

Bağımlılığı tersine çevirme prensibi, Robert C. Martin tarafından önerilmiş ve 1996 tarihli "The Dependency Inversion Principle" makalesiyle geniş kitlelere tanıtılmıştır.[3]

Dış bağlantılar

[değiştir | kaynağı değiştir]
  • The Dependency Inversion Principle – Robert C. Martin
  • DIP in the Wild – Brett L. Schuchert

Kaynakça

[değiştir | kaynağı değiştir]
  1. ^ a b Martin, Robert C. (2003). Agile Software Development, Principles, Patterns, and Practices. Prentice Hall. ss. 127-131. ISBN 978-0135974445. 
  2. ^ Freeman, Eric; Freeman, Elisabeth; Sierra, Kathy; Bates, Bert (2004). Head First Design Patterns. 1. O'Reilly. ISBN 978-0-596-00712-6. 
  3. ^ Martin, Robert C. (Haziran 1996). "The Dependency Inversion Principle" (PDF). 14 Temmuz 2011 tarihinde kaynağından (PDF) arşivlendi. Erişim tarihi: 4 Mayıs 2025. 
"https://tr.wikipedia.org/w/index.php?title=Bağımlılığın_tersine_çevrilmesi_ilkesi&oldid=35437200" sayfasından alınmıştır
Kategoriler:
  • Yazılım tasarımı
  • Programlama deyimleri
  • SOLID ilkeleri
  • Sayfa en son 23.44, 4 Haziran 2025 tarihinde değiştirildi.
  • Metin Creative Commons Atıf-AynıLisanslaPaylaş Lisansı altındadır ve ek koşullar uygulanabilir. Bu siteyi kullanarak Kullanım Şartlarını ve Gizlilik Politikasını kabul etmiş olursunuz.
    Vikipedi® (ve Wikipedia®) kâr amacı gütmeyen kuruluş olan Wikimedia Foundation, Inc. tescilli markasıdır.
  • Gizlilik politikası
  • Vikipedi hakkında
  • Sorumluluk reddi
  • Davranış Kuralları
  • Geliştiriciler
  • İstatistikler
  • Çerez politikası
  • Mobil görünüm
  • Wikimedia Foundation
  • Powered by MediaWiki
Bağımlılığın tersine çevrilmesi ilkesi
Konu ekle