Buna pratik olarak bakalım
Obj 3artık Obj 4var olduğunu biliyor . Ne olmuş yani? Neden önemsiyoruz?
DIP diyor
"Yüksek seviyeli modüller, düşük seviyeli modüllere bağlı olmamalı. Her ikisi de soyutlamalara bağlı olmalıdır."
Tamam ama, tüm nesnelerin soyutlamaları değil mi?
DIP ayrıca
"Soyutlamalar detaylara, detaylar soyutlamalara bağlı olmalıdır."
Tamam ama, nesnem düzgün bir şekilde kapsüllenmişse, bu herhangi bir ayrıntıyı gizlemiyor mu?
Bazı insanlar her nesnenin bir anahtar kelime arayüzüne ihtiyaç duyduğunu körü körüne ısrar etmeyi sever. Ben onlardan biri değilim. Eğer onları şimdi kullanmayacaksanız, daha sonra onlar gibi bir şeye ihtiyaç duymak için bir plana ihtiyacınız olduğunu körü körüne ısrar etmek istiyorum.
Kodunuz her sürümde tamamen yeniden oluşturulabiliyorsa, daha sonra ihtiyacınız olduğunda arayüzleri ayıklayabilirsiniz. Yeniden derlemek istemediğiniz bir kod yayınladıysanız ve kendinizi bir arayüz üzerinden konuşmak istediğinizi düşünüyorsanız, bir plana ihtiyacınız olacaktır.
Obj 3Obj 4var olduğunu bilir . Ama somut Obj 3olup olmadığını biliyor Obj 4mu?
İşte bu yüzden, newher yere yayılmaması çok güzel . Eğer somut Obj 3olup olmadığını bilmiyorsa Obj 4, muhtemelen yaratmadığı için, o zaman daha sonra Obj 4sokulur ve soyut bir sınıfa Obj 3dönerseniz umursamazsınız.
Eğer bunu yapabilirseniz, o zaman Obj 4boyunca tamamen soyut oldu. Başından itibaren aralarında bir arayüz oluşturan tek şey, birisinin yanlışlıkla şu Obj 4anda somut olan kodu veren kod eklemeyeceğinin güvencesidir . Korumalı inşaatçılar bu riski azaltabilir, ancak bu başka bir soruya yol açar:
Obj 3 ve Obj 4 aynı pakette mi?
Nesneler genellikle bir şekilde gruplandırılır (paket, ad alanı vb.). Akıllıca gruplandırıldığında, gruplar arasında değil, bir grup içindeki olası etkiler daha olasıdır.
Özelliğe göre gruplamayı seviyorum. Eğer Obj 3ve Obj 4aynı grupta ve katmanda vardır o bir tane yayınlanmış ve sadece diğeri değiştirmeye gerek ederken refactor istiyorum gelmiş olacak çok düşüktür. Bu, bu nesnelerin, açık bir ihtiyacı olmadan aralarına bir soyutlama getirmekten yararlanma olasılıklarının daha düşük olduğu anlamına gelir.
Bir grup sınırını geçiyorsanız, her iki taraftaki nesnelerin bağımsız olarak değişmesine izin vermek iyi bir fikirdir.
Bu kadar basit olmalı, ancak ne yazık ki hem Java hem de C #, bunu karmaşıklaştıran talihsiz seçimler yaptı.
C # 'da her anahtar kelime arabirimini bir Iönekle adlandırmak geleneğidir . Bu, istemcileri bir anahtar kelime arayüzüyle konuştuklarını bilmeye zorlar. Bu yeniden düzenleme planına karışıyor.
Java'da daha iyi bir adlandırma kalıbı kullanmak geleneği vardır: FooImple implements FooAncak, Java yalnızca anahtar kelime arabirimlerini farklı bir ikili dosyaya derlediğinden, bu yalnızca kaynak kodu düzeyinde yardımcı olur. Bu, somuttan Foosoyut kodlara değiştiğinizde, tek bir kod karakterine ihtiyaç duymadığınızda, hala derlenmelidir.
İnsanların gerçekten ihtiyaç duyuncaya kadar resmi soyutlamayı ertelemelerini engelleyen bu belirli dillerde bu HATALAR. Hangi dili kullandığınızı söylemediniz, ancak bu sorunları olmayan bazı diller olduğunu anladınız.
Hangi dili kullandığınızı söylemediniz, bu yüzden her yerde anahtar kelime arayüzleri olacağına karar vermeden önce dilinizi ve durumunuzu dikkatlice analiz etmenizi tavsiye edeceğim.
YAGNI prensibi burada kilit bir rol oynamaktadır. Ama "Lütfen kendimi ayağımı vurmayı zorlaştır".
