IoC ve Dependency Injection

Modern yazılım geliştirme dünyasında, uygulamaların karmaşıklığı giderek artmakta ve bu karmaşıklığı yönetmek için çeşitli mimari prensipler ve tasarım desenleri kullanılmaktadır. Bu prensipler arasında en önemlilerinden ikisi, Inversion of Control (IoC) ve onun bir uygulaması olan Dependency Injection (DI)’dir. Bu makalede, bu kavramları detaylı olarak inceleyecek, pratikte nasıl uygulandıklarını görecek ve yazılım geliştirme süreçlerine sağladıkları faydaları ele alacağız.

Inversion of Control (IoC) Prensibi

Inversion of Control, yazılım mühendisliğinde geleneksel kontrol akışını tersine çeviren bir tasarım prensibidir. Geleneksel programlamada, bir sınıf kendi kullandığı bağımlılıkları oluşturur ve yönetir. IoC ile bu sorumluluk tersine çevrilir ve bağımlılıkların oluşturulması ve yönetilmesi sorumluluğu başka bir bileşene (genellikle bir framework veya container) devredilir.

Geleneksel Kontrol Akışı vs IoC

Geleneksel yaklaşımda, bir sınıf ihtiyaç duyduğu diğer sınıfların nesnelerini kendisi oluşturur:

public class CustomerService
{
    private readonly DatabaseRepository _repository;
    private readonly Logger _logger;

    public CustomerService()
    {
        _repository = new DatabaseRepository();
        _logger = new Logger();
    }
    
    public Customer GetCustomer(int id)
    {
        _logger.Log($"Getting customer with id: {id}");
        return _repository.GetById(id);
    }
}

IoC prensibi ile, sınıf bu bağımlılıkları dışarıdan alır:

public class CustomerService
{
    private readonly IRepository _repository;
    private readonly ILogger _logger;

    public CustomerService(IRepository repository, ILogger logger)
    {
        _repository = repository;
        _logger = logger;
    }
    
    public Customer GetCustomer(int id)
    {
        _logger.Log($"Getting customer with id: {id}");
        return _repository.GetById(id);
    }
}

IoC’nin Temel İlkeleri

1. Yüksek Seviyeli Modüller Düşük Seviyeli Modüllere Bağımlı Olmamalıdır: Her ikisi de soyutlamalara bağımlı olmalıdır.
2. Soyutlamalar Detaylara Bağımlı Olmamalıdır: Detaylar soyutlamalara bağımlı olmalıdır.
3. Hollywood Prensibi: “Bizi aramanın, biz sizi ararız.” Bir framework’ün kodunuzu nasıl çağıracağını anlatır.

IoC’nin Avantajları

1. Gevşek Bağlantı (Loose Coupling): Sınıflar arasındaki sıkı bağımlılıklar azalır, kod daha modüler hale gelir.
2. Test Edilebilirlik: Bağımlılıklar dışarıdan verildiği için, test sırasında gerçek nesneler yerine mock nesneler kullanılabilir.
3. Kodun Yeniden Kullanılabilirliği: Bileşenler daha az bağımlı olduğu için başka bağlamlarda da kullanılabilir.
4. Paralel Geliştirme: Farklı ekipler, ortak arayüzler üzerinde anlaştıktan sonra bağımsız çalışabilirler.
5. Bakım Kolaylığı: Bağımlılıkların merkezi yönetimi, kodun bakımını kolaylaştırır.

IoC Container Kavramı

IoC Container (veya DI Container), bağımlılıkların oluşturulması ve yönetilmesi işlemlerini otomatikleştiren bir yazılım bileşenidir. Container, uygulamanın ihtiyaç duyduğu nesneleri oluşturur, bu nesnelerin yaşam döngülerini yönetir ve bağımlılıkları doğru şekilde enjekte eder.

Popüler IoC Container örnekleri:

• .NET: Autofac, Unity, Ninject, Microsoft.Extensions.DependencyInjection
• Java: Spring Framework, Google Guice, Dagger
• PHP: PHP-DI, Symfony DI
• JavaScript/TypeScript: InversifyJS, TSyringe, NestJS

Dependency Injection (DI)

Dependency Injection, IoC prensibini uygulamanın bir yoludur. DI, bir sınıfın bağımlılıklarının dışarıdan sağlanması anlamına gelir. Bu sayede sınıflar, ihtiyaç duydukları bağımlılıkları oluşturmak yerine, bu bağımlılıkları bir kaynaktan (genellikle bir IoC container) alırlar.

DI Nedir ve Neden Kullanılır?

DI, bir nesnenin diğer nesnelere olan bağımlılıklarını, nesne oluşturma zamanında veya çalışma zamanında sağlayan bir tekniktir. Bu, kodun daha temiz, daha modüler ve daha test edilebilir olmasını sağlar.

DI’nin Temel Faydaları

1. Gevşek Bağlantı: Sınıflar, somut uygulamalar yerine soyutlamalar üzerinden iletişim kurar.
2. Test Edilebilirlik: Bağımlılıklar mock edilebilir, bu da birim testlerini kolaylaştırır.
3. Bakım Kolaylığı: Bağımlılıkların değiştirilmesi merkezi bir yerden yapılabilir.
4. Kodun Okunabilirliği: Sınıfın gereksinimleri constructor’da açıkça belirtilir.
5. Endişelerin Ayrılması (Separation of Concerns): Her sınıf sadece kendi sorumluluğundaki işi yapar.

Dependency Injection Türleri

DI’nin dört temel uygulama türü vardır:

1. Constructor Injection

En yaygın ve önerilen DI türüdür. Bağımlılıklar, sınıfın constructor’ı aracılığıyla sağlanır.

public class OrderService
{
    private readonly IOrderRepository _orderRepository;
    private readonly IPaymentService _paymentService;
    private readonly INotificationService _notificationService;

    public OrderService(IOrderRepository orderRepository, 
                       IPaymentService paymentService, 
                       INotificationService notificationService)
    {
        _orderRepository = orderRepository;
        _paymentService = paymentService;
        _notificationService = notificationService;
    }
    
    public void PlaceOrder(Order order)
    {
        _orderRepository.Save(order);
        _paymentService.ProcessPayment(order);
        _notificationService.NotifyCustomer(order);
    }
}

Avantajları:

• Sınıfın bağımlılıkları açıkça bellidir
• Sınıf her zaman geçerli durumda başlatılır
• Değişmezlik (immutability) sağlar

Dezavantajları:

• Çok fazla bağımlılık olduğunda constructor karmaşıklaşabilir (bu genellikle Single Responsibility Principle’ın ihlal edildiğini gösterir)

2. Setter Injection

Bağımlılıklar, setter metodları aracılığıyla sağlanır.

public class UserService {
    private UserRepository userRepository;
    private EmailService emailService;
    
    public void setUserRepository(UserRepository userRepository) {
        this.userRepository = userRepository;
    }
    
    public void setEmailService(EmailService emailService) {
        this.emailService = emailService;
    }
    
    public void registerUser(User user) {
        userRepository.save(user);
        emailService.sendWelcomeEmail(user);
    }
}

Avantajları:

• Opsiyonel bağımlılıklar için uygundur
• Çalışma zamanında bağımlılıkları değiştirmek kolaydır

Dezavantajları:

• Sınıf, geçerli durumda başlamayabilir (bağımlılıklar null olabilir)
• Bağımlılıkların setter ile ayarlanıp ayarlanmadığını kontrol etmek gerekebilir

3. Interface Injection

Sınıf, bağımlılıkların nasıl enjekte edileceğini belirten bir arayüzü uygular.

interface ServiceInjector {
    injectDependencies(container: Container): void;
}

class ProductService implements ServiceInjector {
    private productRepository: ProductRepository;
    private logger: Logger;
    
    injectDependencies(container: Container): void {
        this.productRepository = container.resolve(ProductRepository);
        this.logger = container.resolve(Logger);
    }
    
    getProductDetails(id: number): Product {
        this.logger.log(`Getting product details for ${id}`);
        return this.productRepository.findById(id);
    }
}

Avantajları:

• Sınıfın bağımlılıklarını nasıl alacağı standartlaştırılmıştır
• Framework’ler için uygundur

Dezavantajları:

• Daha karmaşık bir yapıdır
• Sınıfların ekstra arayüzler uygulamasını gerektirir

4. Method Injection

Bağımlılıklar, sınıfın metodlarına parametre olarak sağlanır.

class ReportGenerator {
    public function generateReport(ReportData $data, PDFFormatter $formatter): string {
        $reportContent = $this->processData($data);
        return $formatter->format($reportContent);
    }
    
    private function processData(ReportData $data): array {
        // Process data
        return $processedData;
    }
}

Avantajları:

• Bağımlılık sadece ihtiyaç duyulduğu metoda verilir
• Farklı çağrılarda farklı bağımlılıklar kullanılabilir

Dezavantajları:

• Metod imzaları karmaşıklaşabilir
• Her seferinde bağımlılıkları manuel olarak geçmek gerekebilir

DI ile İlgili Tasarım Kalıpları

Servis Bulucu (Service Locator)

Servis Bulucu, bağımlılıkların merkezi bir yerden alınmasını sağlar, ancak DI’nin tersine, bağımlılıklar sınıf tarafından istenir.

public class OrderProcessor {
    public void ProcessOrder(Order order) {
        var paymentService = ServiceLocator.Resolve<IPaymentService>();
        var notificationService = ServiceLocator.Resolve<INotificationService>();
        
        paymentService.ProcessPayment(order);
        notificationService.NotifyCustomer(order);
    }
}

Not: Service Locator genellikle anti-pattern olarak kabul edilir çünkü bağımlılıkları gizler ve kodun test edilebilirliğini azaltır.

Factory Pattern

Factory Pattern, nesnelerin oluşturulması sorumluluğunu ayrı bir sınıfa veya metoda devreder.

public interface NotificationServiceFactory {
    NotificationService createNotificationService(Customer customer);
}

public class OrderService {
    private final NotificationServiceFactory notificationServiceFactory;
    
    public OrderService(NotificationServiceFactory notificationServiceFactory) {
        this.notificationServiceFactory = notificationServiceFactory;
    }
    
    public void placeOrder(Order order) {
        NotificationService notificationService = 
            notificationServiceFactory.createNotificationService(order.getCustomer());
        notificationService.sendOrderConfirmation(order);
    }
}

Decorator Pattern

Decorator Pattern, DI ile birlikte kullanıldığında, bağımlılıkları dinamik olarak genişletme imkanı sağlar.

interface ILoggingService {
    log(message: string): void;
}

class ConsoleLogger implements ILoggingService {
    log(message: string): void {
        console.log(message);
    }
}

class LoggingDecorator implements ILoggingService {
    constructor(private logger: ILoggingService, private prefix: string) {}
    
    log(message: string): void {
        this.logger.log(`${this.prefix}: ${message}`);
    }
}

// Kullanım
const container = new Container();
container.register('ILoggingService', ConsoleLogger);

// Decorating
const baseLogger = container.resolve<ILoggingService>('ILoggingService');
const decoratedLogger = new LoggingDecorator(baseLogger, '[INFO]');

DI Containerların Derinlemesine İncelenmesi

Modern DI Container’lar, basit bağımlılık enjeksiyonunun ötesinde birçok özellik sunarlar:

Yaşam Döngüsü Yönetimi

Container’lar, nesnelerin yaşam döngülerini yönetebilir:

1. Singleton: Tek bir nesne tüm uygulama boyunca kullanılır
2. Transient: Her istendiğinde yeni bir nesne oluşturulur
3. Scoped: Belirli bir kapsam içinde (örn. HTTP isteği) tek bir nesne kullanılır
4. Pooled: Nesneler bir havuzdan alınır ve tekrar kullanılır

// ASP.NET Core'da kayıt örneği
services.AddSingleton<IConfiguration, AppConfiguration>();
services.AddScoped<IUserContext, UserContext>();
services.AddTransient<IOrderProcessor, OrderProcessor>();

Otomatik Kayıt

Birçok container, bağımlılıkları otomatik olarak tarayabilir ve kaydedebilir:

// Autofac ile assembly'deki tüm servisleri kaydetme
var builder = new ContainerBuilder();
builder.RegisterAssemblyTypes(Assembly.GetExecutingAssembly())
    .Where(t => t.Name.EndsWith("Service"))
    .AsImplementedInterfaces();

İsimlendirilmiş ve Şartlı Kayıt

Aynı arayüz için farklı uygulamalar kaydedilebilir:

// InversifyJS örneği
container.bind<IPaymentProcessor>("creditCardProcessor").to(CreditCardProcessor);
container.bind<IPaymentProcessor>("paypalProcessor").to(PaypalProcessor);

// Çözümleme
const processor = container.getNamed<IPaymentProcessor>(
    "creditCardProcessor", 
    payment.type === "creditCard" ? "creditCardProcessor" : "paypalProcessor"
);

Lazy Loading

Bağımlılıklar, gerçekten ihtiyaç duyulduğunda yüklenebilir:

// .NET örneği
public class ExpensiveService
{
    private readonly Lazy<IHeavyDependency> _heavyDependency;
    
    public ExpensiveService(Lazy<IHeavyDependency> heavyDependency)
    {
        _heavyDependency = heavyDependency;
    }
    
    public void DoSomethingRarely()
    {
        // Sadece bu metod çağrıldığında bağımlılık oluşturulur
        _heavyDependency.Value.PerformHeavyOperation();
    }
}

Interceptor’lar

Bazı container’lar, metod çağrılarını araya girerek izleme, loglama veya önbelleğe alma gibi çapraz kesit endişelerini uygulamaya olanak tanır:

// Spring AOP örneği
@Aspect
public class LoggingAspect {
    @Around("execution(* com.company.service.*.*(..))")
    public Object logExecutionTime(ProceedingJoinPoint joinPoint) throws Throwable {
        long start = System.currentTimeMillis();
        Object proceed = joinPoint.proceed();
        long executionTime = System.currentTimeMillis() - start;
        
        System.out.println(joinPoint.getSignature() + " executed in " + executionTime + "ms");
        return proceed;
    }
}

Dependency Injection Anti-Patterns

1. Servis Bulucu (Service Locator)

Daha önce bahsedildiği gibi, Servis Bulucu genellikle bir anti-pattern olarak kabul edilir:

public class CustomerController {
    public ActionResult Details(int id) {
        var customerService = ServiceLocator.Current.GetInstance<ICustomerService>();
        var customer = customerService.GetById(id);
        return View(customer);
    }
}

Problem: Sınıfın bağımlılıkları gizlenir, bu da kodun anlaşılmasını ve test edilmesini zorlaştırır.

2. Hizmet Bulma ve Dahil Etme (Locate and Inject)

Container’ı doğrudan kullanarak bağımlılıkları bulma:

class UserService {
    private container: Container;
    
    constructor(container: Container) {
        this.container = container;
    }
    
    getUserDetails(id: string) {
        const userRepository = this.container.resolve<UserRepository>("UserRepository");
        return userRepository.findById(id);
    }
}

Problem: Bu, Servis Bulucu anti-pattern’inin bir varyasyonudur ve benzer sorunlara yol açar.

3. Constrained Construction

Sınıfın bir framework tarafından özel bir yolla oluşturulması gerektiğinde:

public class HomeController : Controller {
    private readonly IUserService _userService;
    
    // Framework tarafından çağrılacak parametre almayan constructor
    public HomeController() : this(ServiceLocator.Current.GetInstance<IUserService>())
    {
    }
    
    // Unit test için kullanılacak constructor
    public HomeController(IUserService userService) 
    {
        _userService = userService;
    }
}

Problem: Gereksiz karmaşıklık ekler ve bağımlılıkları bulanıklaştırır.

4. Kontrolsüz Nesneler ve Sınıf Kalıntıları

Doğru kaydedilmeyen veya kullanım sonrası düzgün şekilde temizlenmeyen nesneler:

public class DocumentProcessor {
    public void process(Document document) {
        // Bu nesne container tarafından yönetilmiyor
        var converter = new DocumentConverter();
        var result = converter.convert(document);
        
        // converter'ın kullanılan kaynakları serbest bırakılmıyor
    }
}

Problem: Bellek sızıntılarına ve performans sorunlarına yol açabilir.

Gerçek Dünya Uygulamaları ve Örnekler

ASP.NET Core Dependency Injection

ASP.NET Core, built-in DI container ile gelir:

// Startup.cs
public void ConfigureServices(IServiceCollection services)
{
    // Service registrations
    services.AddTransient<IEmailService, SmtpEmailService>();
    services.AddScoped<IUserContext, HttpUserContext>();
    services.AddSingleton<IConfiguration>(Configuration);
    
    // Generic repository pattern
    services.AddScoped(typeof(IRepository<>), typeof(EntityFrameworkRepository<>));
    
    services.AddControllers();
}

// Bir Controller'da kullanımı
public class UserController : ControllerBase
{
    private readonly IRepository<User> _userRepository;
    private readonly IEmailService _emailService;
    
    public UserController(IRepository<User> userRepository, IEmailService emailService)
    {
        _userRepository = userRepository;
        _emailService = emailService;
    }
    
    [HttpPost]
    public async Task<IActionResult> Create(UserDto userDto)
    {
        var user = new User { Name = userDto.Name, Email = userDto.Email };
        await _userRepository.AddAsync(user);
        await _emailService.SendWelcomeEmailAsync(user);
        
        return CreatedAtAction(nameof(GetById), new { id = user.Id }, user);
    }
}

Spring Framework

Java dünyasında Spring, güçlü bir DI framework’ü sunar:

// Configuration sınıfı
@Configuration
public class AppConfig {
    
    @Bean
    public DataSource dataSource() {
        DriverManagerDataSource dataSource = new DriverManagerDataSource();
        dataSource.setDriverClassName("com.mysql.cj.jdbc.Driver");
        dataSource.setUrl("jdbc:mysql://localhost:3306/mydb");
        dataSource.setUsername("user");
        dataSource.setPassword("password");
        return dataSource;
    }
    
    @Bean
    public UserRepository userRepository(DataSource dataSource) {
        return new JdbcUserRepository(dataSource);
    }
    
    @Bean
    public UserService userService(UserRepository userRepository) {
        return new UserServiceImpl(userRepository);
    }
}

// Bir serviste kullanımı
@Service
public class UserServiceImpl implements UserService {
    
    private final UserRepository userRepository;
    private final EmailService emailService;
    
    @Autowired
    public UserServiceImpl(UserRepository userRepository, EmailService emailService) {
        this.userRepository = userRepository;
        this.emailService = emailService;
    }
    
    @Override
    public User register(UserRegistrationDto registrationDto) {
        User user = new User();
        user.setUsername(registrationDto.getUsername());
        user.setEmail(registrationDto.getEmail());
        
        User savedUser = userRepository.save(user);
        emailService.sendWelcomeEmail(savedUser);
        
        return savedUser;
    }
}

Angular Dependency Injection

Angular, TypeScript için kapsamlı bir DI sistemi sunar:

// Service tanımı
@Injectable({
  providedIn: 'root'
})
export class ProductService {
  constructor(private http: HttpClient, private logService: LogService) {}
  
  getProducts(): Observable<Product[]> {
    this.logService.log('Fetching products');
    return this.http.get<Product[]>('/api/products');
  }
}

// Component'te kullanımı
@Component({
  selector: 'app-product-list',
  templateUrl: './product-list.component.html',
  styleUrls: ['./product-list.component.css']
})
export class ProductListComponent implements OnInit {
  products: Product[];
  
  constructor(private productService: ProductService) {}
  
  ngOnInit() {
    this.productService.getProducts()
      .subscribe(products => this.products = products);
  }
}

DI ve Mikroservis Mimarisi

Mikroservis mimarisi, DI prensiplerinden büyük ölçüde yararlanır:

Servis Keşfi (Service Discovery)

Mikroservislerde, bir servisin diğerlerini bulabilmesi gerekir:

@Service
public class OrderServiceClient {
    private final RestTemplate restTemplate;
    private final ServiceDiscoveryClient discoveryClient;
    
    public OrderServiceClient(RestTemplate restTemplate, ServiceDiscoveryClient discoveryClient) {
        this.restTemplate = restTemplate;
        this.discoveryClient = discoveryClient;
    }
    
    public Order getOrder(String orderId) {
        ServiceInstance serviceInstance = discoveryClient.getInstances("order-service")
            .stream()
            .findFirst()
            .orElseThrow(() -> new ServiceNotFoundException("Order service not available"));
        
        String url = serviceInstance.getUri() + "/orders/" + orderId;
        return restTemplate.getForObject(url, Order.class);
    }
}

Yapılandırma Yönetimi

DI, dağıtık yapılandırma yönetimini kolaylaştırır:

public class PaymentProcessor
{
    private readonly IConfigurationService _configService;
    
    public PaymentProcessor(IConfigurationService configService)
    {
        _configService = configService;
    }
    
    public async Task ProcessPayment(Payment payment)
    {
        var apiKey = await _configService.GetConfigValueAsync("payment:api-key");
        var apiEndpoint = await _configService.GetConfigValueAsync("payment:endpoint");
        
        // İşlem gerçekleştirme
    }
}

Test Edilebilirlik ve DI

DI, kodun test edilebilirliğini büyük ölçüde artırır:

Mock Framework’leri ile Birim Testler

[Fact]
public void OrderService_PlaceOrder_SendsNotification()
{
    // Arrange
    var mockRepository = new Mock<IOrderRepository>();
    var mockPaymentService = new Mock<IPaymentService>();
    var mockNotificationService = new Mock<INotificationService>();
    
    var order = new Order { Id = 1, CustomerEmail = "test@example.com" };
    
    var orderService = new OrderService(
        mockRepository.Object,
        mockPaymentService.Object,
        mockNotificationService.Object);
    
    // Act
    orderService.PlaceOrder(order);
    
    // Assert
    mockNotificationService.Verify(
        x => x.NotifyCustomer(It.Is<Order>(o => o.Id == 1)), 
        Times.Once);
}

Entegrasyon Testleri

@SpringBootTest
public class UserServiceIntegrationTest {
    
    @Autowired
    private UserService userService;
    
    @MockBean
    private EmailService emailService;
    
    @Test
    public void whenRegisterUser_thenUserShouldBeSaved() {
        // Arrange
        UserRegistrationDto registrationDto = new UserRegistrationDto(
            "testuser", "test@example.com", "password");
        
        // Act
        User savedUser = userService.register(registrationDto);
        
        // Assert
        assertNotNull(savedUser.getId());
        assertEquals("testuser", savedUser.getUsername());
        
        verify(emailService).sendWelcomeEmail(any(User.class));
    }
}

Performans ve Ölçeklenebilirlik Kaygıları

DI Container Performans Etkisi

DI container’lar genellikle reflection kullanarak çalışır, bu da bir miktar performans etkisine neden olabilir:

// Container optimizasyonu örneği
public void ConfigureServices(IServiceCollection services)
{
    // Tip bağlamaları yapılandırma zamanında gerçekleşir
    services.AddTransient<IUserService, UserService>();
    
    // Bir fabrika metodu kullanılarak kodun derleme zamanında oluşturulması sağlanabilir
    services.AddTransient<IProductService>(provider => {
        var repository = provider.GetRequiredService<IProductRepository>();
        var cache = provider.GetRequiredService<ICacheService>();
        return new ProductService(repository, cache);
    });
}

Singleton vs Transient Bağımlılıklar

Singleton’ların yanlış kullandığında thread-safety sorunları oluşabilir:

// Tehlikeli singleton kullanımı
public class GlobalCounter
{
    private int _count;
    
    public void Increment()
    {
        _count++; // Thread-safe değil
    }
    
    public int GetCount() => _count;
}

// Düzeltilmiş hali
public class ThreadSafeCounter
{
    private int _count;
    private readonly object _lock = new object();
    
    public void Increment()
    {
        lock(_lock)
        {
            _count++;
        }
    }
    
    public int GetCount()
    {
        lock(_lock)
        {
            return _count;
        }
    }
}

Sonuç

Inversion of Control ve Dependency Injection, modern yazılım geliştirmenin temel prensipleri haline gelmiştir. Bu prensipler, kodun bakımını, test edilebilirliğini ve ölçeklenebilirliğini büyük ölçüde artırırken, yazılım bileşenleri arasındaki bağımlılıkları yönetmek için güçlü mekanizmalar sunar.

IoC ve DI prensiplerini uygulamak, sadece bir teknik değil, aynı zamanda bir düşünce şeklidir. Bu prensipler, yazılım geliştirme ekiplerinin daha modüler, daha esnek ve daha sürdürülebilir kod yazmasına yardımcı olur.

Bağımlılıkları yönetme konusunda IoC ve DI’nin sunduğu avantajlar şunlardır:

1. Kod Tekrarının Azaltılması: Ortak bileşenlerin merkezi bir yerden yönetilmesi, kod tekrarını azaltır.
2. Bakım Kolaylığı: Sistemdeki değişiklikler, sadece ilgili bileşenlerde ve bağımlılıkların tanımlandığı yerlerde yapılır.
3. Test Edilebilirlik: Bağımlılıklar kolayca mock edilebilir, bu da kapsamlı birim testleri yazmayı mümkün kılar.
4. Esneklik: Uygulamanın davranışı, iç kodunu değiştirmeden, bağımlılıkları değiştirerek değiştirilebilir.
5. Odaklanma: Her bileşen sadece kendi sorumluluğuna odaklanır, bu da daha temiz ve anlaşılır kod sağlar.

Yazılım geliştirmeye olan yaklaşımımız sürekli gelişiyor, ancak IoC ve DI prensipleri, gelecekte de modern yazılım mimarisinin temel yapı taşları olmaya devam edecektir. Bu prensipleri bir dizi teknik olarak değil, yazılım tasarımına yaklaşım şekli olarak görmek, daha yüksek kaliteli yazılımlar geliştirmenin anahtarıdır.

Yaygın Sorunlar ve Çözümleri

Döngüsel Bağımlılıklar (Circular Dependencies)

Döngüsel bağımlılıklar, iki veya daha fazla sınıfın birbirine bağımlı olduğu durumlarda ortaya çıkar:

public class A {
    private readonly B _b;
    public A(B b) { _b = b; }
}

public class B {
    private readonly A _a;
    public B(A a) { _a = a; }
}

Çözüm:

1. Sınıfları Yeniden Düzenlemek: Bağımlılıkları daha iyi yapılandırmak
2. Aracı Sınıf Eklemek: İki sınıf arasına aracı bir sınıf eklemek
3. Method Injection Kullanmak: Constructor yerine metod parametresi olarak bağımlılığı geçmek
4. Event-based Çözümler: Observer pattern kullanarak dolaylı iletişim sağlamak

Aşırı Karmaşıklık

Çok fazla bağımlılık, karmaşık constructor’lara ve bakımı zor koda yol açabilir:

public class OrderService {
    public OrderService(
        IOrderRepository orderRepository,
        ICustomerRepository customerRepository,
        IProductRepository productRepository,
        IInventoryService inventoryService,
        IShippingService shippingService,
        IPaymentService paymentService,
        IEmailService emailService,
        ILogger logger,
        IMetricsCollector metricsCollector,
        ITransactionManager transactionManager) {
        // Çok fazla bağımlılık...
    }
}

Çözüm:

1. Single Responsibility Principle: Sınıfı daha küçük, daha odaklı sınıflara bölmek
2. Facade Pattern: Bir alt sistem için tek bir arayüz sağlamak
3. Composition Root: Bağımlılıkları oluşturma ve bağlama işlemlerini tek bir yerde yapmak
4. Factory Pattern: Karmaşık nesne oluşturma süreçlerini factory sınıflara devretmek

Modern Framework’lerdeki IoC ve DI Uygulamaları

.NET Core ve ASP.NET Core

Microsoft’un modern web framework’ü, built-in DI container ile gelir ve uygulamanın her katmanında bağımlılık enjeksiyonuna izin verir:

// Program.cs (ASP.NET Core 6+)
var builder = WebApplication.CreateBuilder(args);

// Service registrations
builder.Services.AddTransient<IProductService, ProductService>();
builder.Services.AddScoped<ICurrentUser, HttpContextCurrentUser>();
builder.Services.AddSingleton<ICacheService, MemoryCacheService>();

// Controller'da kullanım
[ApiController]
[Route("api/[controller]")]
public class ProductsController : ControllerBase
{
    private readonly IProductService _productService;
    private readonly ICurrentUser _currentUser;
    
    public ProductsController(IProductService productService, ICurrentUser currentUser)
    {
        _productService = productService;
        _currentUser = currentUser;
    }
    
    [HttpGet]
    public async Task<IActionResult> GetProducts()
    {
        if (!_currentUser.HasPermission("ViewProducts"))
        {
            return Forbid();
        }
        
        var products = await _productService.GetAllAsync();
        return Ok(products);
    }
}

Spring Boot (Java)

Spring Boot, güçlü bir DI sistemi ve annotation-driven dependency yönetimi sunar:

@RestController
@RequestMapping("/api/users")
public class UserController {
    
    private final UserService userService;
    private final SecurityService securityService;
    
    // Constructor injection
    @Autowired
    public UserController(UserService userService, SecurityService securityService) {
        this.userService = userService;
        this.securityService = securityService;
    }
    
    @GetMapping("/{id}")
    public ResponseEntity<User> getUserById(@PathVariable Long id) {
        if (!securityService.canAccessUser(id)) {
            return ResponseEntity.status(HttpStatus.FORBIDDEN).build();
        }
        
        return userService.findById(id)
            .map(ResponseEntity::ok)
            .orElse(ResponseEntity.notFound().build());
    }
}

React ve Redux

Frontend dünyasında, Redux ve React Context API, bağımlılıkların ve uygulama durumunun yönetilmesi için IoC prensiplerinden yararlanır:

// Context API kullanımı
const ThemeContext = React.createContext('light');

function App() {
  return (
    <ThemeContext.Provider value="dark">
      <ThemedButton />
    </ThemeContext.Provider>
  );
}

function ThemedButton() {
  const theme = useContext(ThemeContext);
  return <Button theme={theme} />;
}

NestJS (Node.js)

NestJS, Node.js için Angular benzeri bir DI sistemi sunar:

@Injectable()
export class ProductsService {
  constructor(
    @InjectRepository(Product)
    private productsRepository: Repository<Product>,
    private configService: ConfigService,
    private logger: Logger
  ) {}
  
  async findAll(): Promise<Product[]> {
    this.logger.log('Finding all products');
    return this.productsRepository.find();
  }
  
  async create(createProductDto: CreateProductDto): Promise<Product> {
    const product = new Product();
    product.name = createProductDto.name;
    product.price = createProductDto.price;
    
    return this.productsRepository.save(product);
  }
}

DI ve Mimari Desenler

Domain-Driven Design (DDD)

DDD, IoC ve DI prensiplerine dayanır ve domain katmanının bağımsızlığını sağlar:

// Domain Service
public class OrderDomainService
{
    public Order CreateOrder(Customer customer, List<OrderLine> orderLines)
    {
        var order = new Order(customer);
        
        foreach (var line in orderLines)
        {
            order.AddOrderLine(line.Product, line.Quantity);
        }
        
        order.CalculateTotal();
        return order;
    }
}

// Application Service
public class OrderApplicationService
{
    private readonly IOrderRepository _orderRepository;
    private readonly ICustomerRepository _customerRepository;
    private readonly IProductRepository _productRepository;
    private readonly OrderDomainService _orderDomainService;
    
    public OrderApplicationService(
        IOrderRepository orderRepository,
        ICustomerRepository customerRepository,
        IProductRepository productRepository,
        OrderDomainService orderDomainService)
    {
        _orderRepository = orderRepository;
        _customerRepository = customerRepository;
        _productRepository = productRepository;
        _orderDomainService = orderDomainService;
    }
    
    public async Task<OrderDto> CreateOrderAsync(CreateOrderCommand command)
    {
        var customer = await _customerRepository.GetByIdAsync(command.CustomerId);
        
        var orderLines = new List<OrderLine>();
        foreach (var item in command.Items)
        {
            var product = await _productRepository.GetByIdAsync(item.ProductId);
            orderLines.Add(new OrderLine(product, item.Quantity));
        }
        
        var order = _orderDomainService.CreateOrder(customer, orderLines);
        
        await _orderRepository.SaveAsync(order);
        
        return new OrderDto { Id = order.Id, Total = order.Total };
    }
}

Clean Architecture

Clean Architecture, bağımlılıkların iç katmanlardan dış katmanlara doğru akmasını sağlayarak IoC prensibini uygular:

// Domain Entity
export class User {
    constructor(
        public readonly id: string,
        public readonly email: string,
        public readonly name: string,
        private passwordHash: string
    ) {}
    
    validatePassword(password: string): boolean {
        return hashPassword(password) === this.passwordHash;
    }
}

// Use Case / Application Service
export class AuthenticateUserUseCase {
    constructor(
        private userRepository: UserRepository,
        private tokenService: TokenService,
        private logger: Logger
    ) {}
    
    async execute(email: string, password: string): Promise<AuthResult> {
        try {
            const user = await this.userRepository.findByEmail(email);
            
            if (!user || !user.validatePassword(password)) {
                return { success: false };
            }
            
            const token = this.tokenService.generateToken(user.id);
            return { success: true, token, userId: user.id };
            
        } catch (error) {
            this.logger.error('Authentication error', error);
            return { success: false, error: 'An error occurred' };
        }
    }
}

// Controller
export class AuthController {
    constructor(private authenticateUserUseCase: AuthenticateUserUseCase) {}
    
    async login(req: Request, res: Response): Promise<void> {
        const { email, password } = req.body;
        
        const result = await this.authenticateUserUseCase.execute(email, password);
        
        if (result.success) {
            res.status(200).json({ token: result.token, userId: result.userId });
        } else {
            res.status(401).json({ message: 'Invalid credentials' });
        }
    }
}

Geleceğe Bakış: IoC ve DI’nin Evrimi

Function Injection ve Hooks

React Hooks ve benzer yaklaşımlar, bağımlılık enjeksiyonuna yeni bir bakış açısı getirir:

function useProductService() {
    const apiUrl = useConfig('api.url');
    const cache = useCache();
    const logger = useLogger();
    
    return {
        async getProducts() {
            try {
                const cachedProducts = cache.get('products');
                if (cachedProducts) return cachedProducts;
                
                logger.info('Fetching products from API');
                const response = await fetch(`${apiUrl}/products`);
                const products = await response.json();
                
                cache.set('products', products);
                return products;
            } catch (error) {
                logger.error('Failed to fetch products', error);
                throw error;
            }
        }
    };
}

function ProductList() {
    const productService = useProductService();
    const [products, setProducts] = useState([]);
    
    useEffect(() => {
        productService.getProducts()
            .then(data => setProducts(data))
            .catch(error => console.error(error));
    }, [productService]);
    
    return (
        <ul>
            {products.map(product => (
                <li key={product.id}>{product.name}</li>
            ))}
        </ul>
    );
}

Serverless ve Dependency Injection

Serverless ortamlarda DI, farklı zorluklar ve çözümler sunar:

// AWS Lambda ile DI örneği
import { Container } from 'inversify';
import { APIGatewayProxyEvent, APIGatewayProxyResult } from 'aws-lambda';

// Container oluşturma
const container = new Container();
container.bind<UserService>(TYPES.UserService).to(UserService);
container.bind<UserRepository>(TYPES.UserRepository).to(DynamoDBUserRepository);

// Lambda handler
export async function handler(event: APIGatewayProxyEvent): Promise<APIGatewayProxyResult> {
    // İsteğe göre servis alma
    const userService = container.get<UserService>(TYPES.UserService);
    
    try {
        const userId = event.pathParameters?.userId;
        if (!userId) {
            return {
                statusCode: 400,
                body: JSON.stringify({ message: 'User ID is required' })
            };
        }
        
        const user = await userService.getUserById(userId);
        if (!user) {
            return {
                statusCode: 404,
                body: JSON.stringify({ message: 'User not found' })
            };
        }
        
        return {
            statusCode: 200,
            body: JSON.stringify(user)
        };
    } catch (error) {
        console.error('Error fetching user:', error);
        return {
            statusCode: 500,
            body: JSON.stringify({ message: 'Internal server error' })
        };
    }
}

Microservices ve Dependency Injection

Mikroservis mimarisinde, DI hem servis içi hem de servisler arası ilişkileri yönetmeye yardımcı olur:

@Service
public class OrderProcessingService {
    private final KafkaTemplate<String, OrderEvent> kafkaTemplate;
    private final OrderRepository orderRepository;
    
    public OrderProcessingService(
            KafkaTemplate<String, OrderEvent> kafkaTemplate,
            OrderRepository orderRepository) {
        this.kafkaTemplate = kafkaTemplate;
        this.orderRepository = orderRepository;
    }
    
    @Transactional
    public Order processOrder(Order order) {
        // Order işlemleri
        Order savedOrder = orderRepository.save(order);
        
        // Event publishing - mikroservisler arası iletişim
        OrderEvent event = new OrderEvent(savedOrder.getId(), OrderStatus.CREATED);
        kafkaTemplate.send("order-events", event);
        
        return savedOrder;
    }
}

Özet

IoC ve DI, modern yazılım geliştirmede temel prensipler haline gelmiştir. Bu prensipler, yazılım tasarımına bir düşünce şekli olarak yaklaşıldığında, daha bakımı kolay, test edilebilir ve ölçeklenebilir kod yazmaya olanak tanır.

• IoC (Inversion of Control): Geleneksel kontrol akışını tersine çevirerek, bağımlılıkların yönetimini dışarıdan bir bileşene devreder.
• DI (Dependency Injection): Bir sınıfın bağımlılıklarının dışarıdan sağlanmasını sağlayarak, sınıflar arası bağımlılıkları azaltır.

Bu prensipler, yazılım geliştirmenin her seviyesinde – küçük uygulamalardan mikroservis mimarilerine, monolitik sistemlerden serverless yapılara kadar – uygulanabilir ve her durumda kod kalitesini artırır.

Yazılım dünyası sürekli evrilirken, IoC ve DI prensipleri de yeni teknolojilere ve yaklaşımlara uyum sağlayarak gelişmeye devam edecektir. Bu prensipleri anlamak ve uygulamak, modern yazılım mimarisi ve tasarımının temel taşlarını kavramak anlamına gelir.