“Sadece neye ihtiyacınız olduğunu sor” arayüz prensibi var mı?

Temel olarak "sadece neye ihtiyacınız olduğunu sorun" diyen arayüzleri tasarlamak ve tüketmek için bir prensip kullanarak büyüdüm.

Örneğin, silinebilecek bir grup türüm varsa, bir Deletablearayüz yapacağım :

interface Deletable {
   void delete();
}

Sonra genel bir sınıf yazabilirsiniz:

class Deleter<T extends Deletable> {
   void delete(T t) {
      t.delete();
   }
}

Kodun başka bir yerinde her zaman müşteri kodunun ihtiyaçlarını karşılamak için mümkün olan en küçük sorumluluğu isteyeceğim. Yalnızca bir silmeniz gerekiyorsa Yani File, hala bir isteyeceğimiz Deletablebir değil File.

Bu ilke, ortak bilgi ve zaten kabul edilmiş bir isme sahip mi? Tartışmalı mı? Ders kitaplarında tartışıldı mı?

Bunun Robert Martin'in Arayüz Ayrışma İlkesi dediği şeyi ifade ettiğine inanıyorum . Arayüzler küçük ve özlü olanlara ayrılır, böylece tüketiciler (müşteriler) sadece kendilerini ilgilendiren yöntemler hakkında bilgi sahibi olurlar. SOLID hakkında daha fazla bilgi edinebilirsiniz .

Vadim'in çok iyi cevabını genişletmek için "tartışmalı mı?" Sorusunu "hayır, gerçekten değil" şeklinde cevaplayacağım.

Genel olarak, arayüz ayrımı, ilgili çeşitli nesnelerin genel "değişim nedenleri" sayısını azaltarak iyi bir şeydir. Temel ilke, çoklu yöntemlere sahip bir arayüzün değiştirilmesi gerektiğinde, arayüz yöntemlerinden birine bir parametre eklemenin dendiği durumlarda, değişen yöntemi kullanmasalar bile , arayüzün tüm tüketicilerinin en azından yeniden derlenmesi gerekir.. “Ama bu sadece bir derleme!” Dediğini duydum; bu doğru olabilir, ancak ikilideki değişiklik ne kadar önemli olursa olsun, tipik olarak yeniden derlediğiniz her şeyin bir yazılım yamasının parçası olarak dışarı itilmesi gerektiğini unutmayın. Bu kurallar, ortalama masaüstü iş istasyonunun cebinizdeki telefondan daha az güçlü olduğu 90'ların başında kavramsallaştırıldı, 14.4k baud çevirmeli bağlantı alevlendi ve 3.5 "1.44MB" disketler "birincil çıkarılabilir medyaydı. 3G / 4G'nin şu andaki döneminde bile, kablosuz internet kullanıcılarının genellikle sınırlarla veri planları vardır, bu nedenle bir yükseltme yayınlanırken, indirilmesi gereken daha az ikili dosya daha iyidir.

Bununla birlikte, tüm iyi fikirler gibi, yanlış bir şekilde uygulandığında arayüz ayrımı kötüleşebilir. Öncelikle, bu arayüzleri uygulayan nesneyi korurken (bağımlılıkları yerine getirerek) nispeten değişmeden arayüzleri ayırarak, bir "Hydra", bir "Hydra" ile karşılaşabilirsiniz. nesnenin her şeyi bilen, her şeyin güçlü doğası, dar arayüzlerden bağımlı olanlardan gizlenir. En azından Tanrı Nesnesi'nin bakımı kadar zor olan çok başlı bir canavarın yanı sıra tüm arayüzlerini korumanın yükü ile sonuçlanırsınız. Aşmamanız gereken çok fazla arabirim yoktur, ancak tek bir nesneye uyguladığınız her arabirimin önüne "Bu arabirim nesneye katkıda bulunuyor mu?"

İkincisi, SRP'nin size söyleyebilmesine rağmen, yöntem başına bir arayüz gerekli olmayabilir. Sonunda "mantı kodu" ile sonuçlanabilir; o kadar çok ısırık boyutu var ki, olayların tam olarak nerede olduğunu bulmak zor. Ayrıca, o arabirimin tüm geçerli kullanıcılarının her iki yönteme de ihtiyacı varsa bir arabirimi iki yöntemle bölmek de gereksizdir. Bağımlı sınıflardan biri sadece iki yöntemden birine ihtiyaç duysa bile, yöntemleri kavramsal olarak çok yüksek bir bütünlüğe sahipse, ara yüzün bölünmemesi genel olarak kabul edilebilirdir (iyi örnekler birbirlerinin tam karşıtları olan "antonimik yöntemlerdir").

Arabirim ayrımı, arabirime bağlı olan sınıflara dayanmalıdır:

• Arabirime bağlı yalnızca bir sınıf varsa, ayırmayın. Sınıf bir veya daha fazla arabirim yöntemini kullanmıyorsa ve arabirimin tek tüketicisi ise, bu yöntemleri ilk etapta ortaya çıkarmamalısınız.

• Arabirime bağlı birden fazla sınıf varsa ve tüm bağımlılar arabirimin tüm yöntemlerini kullanıyorsa, ayırmayın; arayüzü değiştirmek zorundaysanız (yöntem eklemek veya imza değiştirmek için), mevcut tüm tüketiciler ayırıp ayırmamanızdan etkilenecektir (en azından bir bağımlıya ihtiyaç duymayacak bir yöntem ekliyorsanız, Değişikliğin yeni bir arayüz olarak uygulanması gerekiyorsa, muhtemelen mevcut arayüzden devralınmalıdır).

• Orada arabirimde birden fazla sınıf bağımlıdır ve onlar yoksa değil hepsi aynı yöntemleri kullanmak, bu ayrımı için bir aday. Arayüzün “tutarlılığına” bakın; tüm yöntemler tek ve çok özel bir programlama hedefini daha da ileri götürüyor mu? Arayüz (ve uygulayıcıları) için birden fazla temel amaç belirleyebiliyorsanız, daha az "değiştirme nedeni" olan daha küçük arayüzler oluşturmak için arayüzleri bu çizgiler boyunca bölmeyi düşünün.