SOLID-Dependency Inversion Principle

 

SOLID tasarım ilkeleri Robert C. Martin tarafından geliştirildi ve nesne yönelimli yazılım geliştirmede en iyi bilinen tasarım ilkelerinden bazıları. SOLID, aşağıdaki beş prensip için hatırlatıcı bir kısaltmadır:

Bu ilkelerin her biri kendi başına durabilir ve nesne yönelimli uygulamaların ve yazılım bileşenlerinin sağlamlığını ve bakımını iyileştirme hedefine sahiptir. Ancak, birbirlerini de desteklerler; böylece hepsini uygulamak, her ilkenin uygulanmasını daha kolay ve etkili hale getirir.

İlk dört tasarım ilkesini önceki makalelerde açıkladım. Buna, Dependency Inversion  Prensibi'ne odaklanacağım. Open/Closed Prensibi ve Liskov Substitution Prensibi'ne dayanmaktadır . Bu nedenle, bu makaleyi okumadan önce en azından bu iki ilkeye aşina olmalısınız.

Dependency Inversion Prensibinin Tanımı

Bu ilkenin genel fikri önemli olduğu kadar basittir: Karmaşık mantık sağlayan yüksek seviye modülleri, düşük seviye modüllerindeki olası değişikliklerden kolayca tekrar kullanılabilirliği sağlamak  ve değişikliklerden  etkilenmemelidir. Bunu başarmak için, üst ve alt seviye modüllerini birbirinden ayıran bir soyutlama yapmalısınız.

Bu düşünceye dayanarak, Robert C. Martin'in Bağımlılık İnversiyon Prensibi tanımı iki bölümden oluşmaktadır:

1.Yüksek seviye modülleri, düşük seviye modüllerine bağlı olmamalıdır. Her ikisi de soyutlamalar bağlı olmalıdır.

2.Soyutlamalar ayrıntılara bağlı olmamalıdır. Detaylar soyutlamaya bağlı olmalıdır.

Bu tanımın önemli bir detayı, yüksek seviye ve düşük seviye modüllerinin soyutlamaya bağlı olmasıdır. Tasarım prensibi, adını ilk defa okurken beklediğiniz gibi bağımlılığın yönünü değiştirmez. Aralarında bir soyutlama getirerek yüksek ve düşük seviye modülleri arasındaki bağımlılığı böler. Sonuçta iki bağımlılık elde edersiniz.

Diğer SOLID ilkelerine dayanarak

Bu, olduğundan daha karmaşık gelebilir. Sonuç olarak Open/Closed Prensibi ve Liskov Substitution Prensibini kodunuza uygularsanız, Dependency Inversion Prensibi'ni de uygulamanız takip eder.

Open/Closed Prensip bir uzantı için açık, ancak değişiklik için kapalı bir yazılım bileşeni gerektiriyordu. Bunu, farklı uygulamalar sağlayabileceğiniz interface implement ederek başarabilirsiniz. Interface yapısının kendisi değişiklik için kapalıdır ve yeni bir arayüz uygulaması sağlayarak kolayca genişletebilirsiniz.

Uygulamalarınız Liskov Substitution Prensibi'ni izlemelidir, böylece yapınızı bozmadan aynı arabirimin diğer uygulamaları ile değiştirebilirsiniz.

Örnek verecek olursak, Google, GitHub vb. Gibi harici servisler üzerinden kimlik doğrulaması yapan bir sistemimiz var. Her servis için bir sınıfımız olacaktı: GoogleAuthenticationService , GitHubAuthenticationService Diyelim ki, sistemimizdeki bir yerin kullanıcımızı doğrulamamız gerekiyor. Bunu yapmak için, bahsedildiği gibi birkaç hizmetimiz var. Tüm hizmetleri kullanabilmek için iki seçeneğimiz var: Ya her servisi doğrulama sürecine uyarlayan bir kod parçası yazıyoruz ya da doğrulama servislerinin bir özetini tanımlıyoruz. İlk olasılık, gelecekte potansiyel olarak birçok sorun doğurabilecek kirli bir çözümdür; Yeni bir kimlik doğrulama hizmeti sisteme entegre edilecek olması durumda mevcut kodunu değiştirmek gerekecektir  . İkinci olasılık daha temizdir, gelecekteki servislerin eklenmesine olanak tanır ve entegrasyon mantığını değiştirmeden her serviste değişiklik yapılabilir. AuthenticationService  arayüzü ve her bir serviste uygulanması tanımlayarak, daha sonra kimlik doğrulama mantığımızda Bağımlılık Enjeksiyonunu kullanabilir ve kimlik doğrulama yöntemi imzamızın şuna benzer şekilde görünmesini sağlayabiliriz: authenticate (AuthenticationService authenticationService) . Ardından, bunun gibi belirli bir hizmetle kimlik doğrulaması yapabiliriz : kimlik doğrulaması (new  GoogleAuthenticationServis) . Bu, her hizmeti ayrı ayrı entegre etmek zorunda kalmadan kimlik doğrulama mantığını genelleştirmemize yardımcı olur.

 

Daha üst seviyedeki soyutlamalara bağlı olarak, davranışı değiştirmek için bir örneği başka bir örnekle kolayca değiştirebiliriz.