Laravel’in Facades yapısı, geliştiricilere hızlı ve temiz bir kod yazma imkanı sağlamakla birlikte, dikkat edilmesi gereken bazı yan etkiler de ortaya çıkarır. Facades, genellikle controller’lar, hizmetler, varlıklar ve repository’ler içinde sıkça kullanılır. Başlangıçta sağladığı verimlilik ve basitlik nedeniyle cazip olsa da, özellikle projeler büyüdükçe uzun vadeli sorunlar yaratabilir.
Gerçek bir senaryoyu düşünün:
Bir hizmet sınıfınız var ve bu sınıf çeşitli iç Facades’ları kullanıyor. İlk başta her şey mükemmel çalışırken, bir gün o sınıfın lojiklerini Laravel dışındaki bir script’te yeniden kullanmak istediğinizde sorunlarla karşılaşırsınız. Veya sadece o sınıfı test etmek isterseniz, tüm framework’ü yüklemeden bunu yapmanın imkansız olduğunu göreceksiniz.
Sonuç olarak, sınıfın neye ihtiyaç duyduğunu anlamak zorlaşır; bunun yerine kodu satır satır açmak durumunda kalırsınız. Her bir Facade, Laravel ile bağlı olan görünmez bir ip gibidir.
Facade’lerin yanlış olduğunu söylemiyoruz; aslında hızlı çözüm üretirken başka bir sorunun gölgede kalmasına sebep oluyorlar: acoplamento (bağlantı). Her ekip kendi tercihlerine göre bir denge kurar. Ancak bu güçlü bağı, Clean Architecture kurallarına karşıt olarak görmek mümkündür.
Laravel’deki Facades, servis konteynerinde kayıtlı nesnelere erişim sağlayan “statik proxy” gibi çalışır. Statik bir metod çağrısını gerçek bir nesneye yönlendiren bir “köprü” işlevi görür ve bu çözüm, Laravel’in bağımlılık enjekte etme süresi boyunca gerçekleştirilir.
Facades kullanıp kullanmamaya karar vermenize yardımcı olabilecek bazı avantajlar ve dezavantajlar şu şekildedir:
Avantajlar:
- Kodun daha hızlı yazılması ve okunmasının kolay oluşu; bu da geliştirme ve prototip oluşturma sürecini ciddi şekilde hızlandırır.
shouldReceive()gibi yöntemler kullanarak test etme kolaylığı sağlar. “Not: Ancak, yapay zeka testleri mükemmel bir şekilde oluşturduğundan, bu gerçekten bir fark yaratıyor mu?”- Singleton davranışında çalışarak, her istekte yalnızca bir kez çözülür.
- Her yerde kullanılabilir, bağımlılıkları manuel olarak yapıcıdan geçirmeye gerek kalmadan kullanılabilir.
Dezavantajlar:
- Test edilebilirliği bozmaz; ancak bağımlılıkları kirleterek “değil” açıklanmış bağımlılıklar oluşturuyor. Yani bağımlılık sınırları net değildir ve yalnızca metodun gövdesine bakarak öğrenilir. Bu da bakım ve yeniden kullanımda zorluklar yaratır.
- Bağımlılık ters çevirme kuralını ihlal eder; sınıf doğrudan somut bir uygulamaya ya da Facade tarafından çözülen bir arayüze bağlıdır, bu da alan tarafından tanımlanan bir soyutlamayı dışarıdan enjekte etmez.
- Framework ile bağlantılı olması, Facades’ın sadece Facade Root başlatıldığında çalıştığını gösterir. Eğer o sınıfı bir script’de ya da başka bir PHP paketi veya framework’te yeniden kullanmayı isterseniz, her şeyi yeniden yazmanız gerekecek.
- Çok kullanışlı oldukları için, SRP (Single Responsibility Principle) ihlaline kolaylıkla yol açabiliyor: Geliştiriciler, sınıfın yapıcısının belirttiği sınırları aşarak yeni dolaylı sorumluluklar ekleyebilir.
Ek olarak, doğrudan dezavantaj olmasa da, bilinmesi gereken iki nokta daha var:
- Test edilebilir olmalarına rağmen, mock’lar global olarak uygulanır ve test sırasında Facade’a yapılan tüm çağrıları etkiler. Belirli bir örnek yerine, tüm çağrılar üzerinde etkili olur. Açık bir temizleme yapılmadığı sürece (
clearResolvedInstances()gibi), testler arasında davranış sızıntısı yaşanabilir. Ancak bu sorun aşılabilir. - Facade doğrudan enjekte edilmeden daha hızlı değildir. Her çağrı
__callStatic()ve konteynerdeki anahtarın çözülmesi maliyetini taşır; bu teknik olarak daha yavaştır, ancak pratikte bu farkı asla ölçmeyeceksiniz.
Facades, Controller’lar, Command’lar, İşler (altyapıya daha yakın katmanlar) için harikadır ve prototiplerde, MVP’lerde hızlı bir teslimat sağlamak için mükemmel bir seçimdir. Ancak, alan katmanlarında, uygulama hizmetleri, değer nesneleri ve varlıklar gibi durumlarda, iş mantığınızı ayırmak için bir arayüzün konstructor’a enjekte edilmesi daha mantıklıdır.
Facades kullanmakta bir sakınca yok. Bu yazı kesin bir kural değil, sadece edindiğim bilgileri ve içgörüleri paylaşıyor. Zaman zaman sorgulamama neden oluyor: “Acaba burada bağımlılığı belirtmek değerli mi?”
Sizlerin de bu konuyla ilgili deneyimlerinizi merak ediyorum. Facades’larla test etme, geliştirme ya da lojik yeniden kullanma konusunda zorluk yaşadınız mı? Yoksa Facades’ın iş katmanından çıkarılması gerektiğini mi düşünüyorsunuz?
Kaynak: Orijinal Makale
