Arayüz adları bir “I” önekiyle mi başlamalı?

Daha iyi bir programcı olmak için Robert Martin tarafından " Temiz Kod " u okudum . Şimdiye kadar hiçbiri gerçekten çığır açmazken, uygulamaları tasarlama ve kod yazma konusunda farklı düşünmeme neden oldu.

Kitabın yalnızca hem kabul etmediğim hem de özellikle arabirim adlandırma kuralları ile ilgili olarak anlam ifade etmeyen bir kısmı var. İşte doğrudan kitaptan alınan metin. Bunun kargaşasını bulduğum ve netleşmek istediğim yönünü cesaretlendirdim.

Arayüzleri süslemeden bırakmayı tercih ederim. Bir önceki I, bugünün mirasıyla dolu tomarlarda çok yaygındır, en iyi ihtimalle en çok dikkat dağıtıcı ve en kötüsü de çok fazla bilgidir. Kullanıcılarımın onlara bir arabirim verdiğimi bilmelerini istemiyorum .

Belki de sadece öğrenciyim çünkü ya da hiç profesyonel veya takım tabanlı bir programlama yapmadığım için ama kullanıcının bir arayüz olduğunu bilmesini isterim. Bir arayüz uygulamak ve bir sınıfı genişletmek arasında büyük bir fark var.

Öyleyse benim sorum, “Kodun bir kısmının bir arayüz bekliyor olduğu gerçeğini neden gizlemeliyiz?

Düzenle

Bir cevaba cevap olarak:

Türünüz bir arabirim veya bir sınıfsa, işletmeniz, kodunuzu kullanan birinin işi değil. Bu nedenle, bu üçüncü taraf kodunda kodunuzun ayrıntılarını sızdırmamalısınız.

Belirli bir türün bir arabirim mi yoksa bir üçüncü şahıs koduna mı sınıf olduğunun ayrıntılarını neden "sızdırmamalıyım"? Üçüncü taraf geliştiricinin, bir arabirim uygulayacaklarını veya bir sınıfı genişleteceklerini bilmek için kodumu kullanan önemli değil mi? Farklar sadece aklımda olmaları için yaptığım kadar önemli değil mi?

Düşünmeyi bırakırsanız, bir arayüzün gerçekten soyut bir sınıftan anlamsal olarak farklı olmadığını göreceksiniz:

• Her ikisinde de yöntemler ve / veya özellikler var (davranış);
• Hiçbirinde özel olmayan alanlar (veriler) olmamalıdır;
• Hiçbiri doğrudan başlatılamaz;
• Birinden türetmek, türetilmiş tür de soyut olmadığı sürece, sahip olduğu herhangi bir soyut yöntemi uygulamak anlamına gelir.

Aslında, sınıflar ve arayüzler arasındaki en önemli farklar şunlardır:

• Arayüzlerin özel verileri olamaz;
• Arayüz üyeleri erişim değiştiricilere sahip olamaz (tüm üyeler "genel" dir);
• Bir sınıf birden fazla arayüz uygulayabilir (genellikle sadece bir temel sınıftan miras alabilmenin aksine).

Sınıflar ve arayüzler arasındaki tek anlamlı anlamlı ayrım, (a) özel veriler ve (b) tip hiyerarşisi etrafında döndüğü için - ikisi de bir arayan için en ufak bir fark yaratmaz - genellikle bir türün bir arayüz olup olmadığını bilmek gerekmez Bir sınıf. Görsel gösterime kesinlikle ihtiyacınız yok .

Ancak, dikkat edilmesi gereken bazı köşe davaları vardır. Özellikle, yansıma, durdurma, dinamik proxy'ler / karışımlar, bayt kodlu dokuma, kod oluşturma veya ortamın yazma sistemiyle veya kodun kendisiyle doğrudan bulaşmayı içeren herhangi bir şey kullanıyorsanız - o zaman çok yararlı ve bazen derhal bilmeniz gerekir. Bir arayüz veya bir sınıfla uğraşırken yarasa olun. Kodunuzun gizemli bir şekilde başarısız olmasını istemiyorsunuz çünkü bir arayüz yerine bir sınıf eklemeye çalıştınız.

Tipik olarak, vanilya, öğütülmüş işletme iş mantığı kodu, ancak, soyut sınıflar ve arayüzler arasındaki farkların, reklamların yayınlanmasına gerek kalmayacak çünkü hiçbir zaman devreye girmeyecekler.

Bunların hepsi söyleniyor, Iyine de C # arayüzlerimi önekleme eğilimindeyim çünkü Microsoft tarafından kullanılan ve savunulan .NET kuralları. Kodlama sözleşmelerini yeni bir geliştiriciye açıklarken, neden kendi "özel" kurallarımıza sahip olduğumuzu açıklamak yerine Microsoft kurallarını kullanmak çok daha az güçtür.

Birçok yönden tutarlılık, sözleşmeden daha önemlidir. Adlandırma şemalarınızda tutarlı olduğunuz sürece, çalışmak zor olmayacak. İsterseniz önek ile bir arabirim oluşturur, ya da sadece adını değiştirmeden bırakırsanız, bir stil seçip ona sadık kalmanız benim için önemli değil!

Kitap çok güzel şeylerle dolu, ancak yine de arayüz adına "I" eklerdim.

public interface ILogVarsayılan bir uygulamaya sahip olduğunuzu hayal edin public class Log.

Şimdi, anlamaya karar verirseniz public interface Log, birdenbire Log sınıfını public class LogDefaulto satırlarda veya başka bir şeyle değiştirmeniz gerekir . Fazladan bir karaktere sahip olmaktan yedisine gittin - elbette israf.

Teori ve pratik arasında genellikle ince bir çizgi vardır. Teoride bu gerçekten iyi bir fikir, ancak pratikte o kadar iyi değil.

Bu, arayüzü uygulamak veya bir sınıfı genişletmekle ilgili değil. Sıkı durumlarda, ne yaptığını zaten biliyorsun.

Bununla birlikte, üçüncü taraf kodu (örnek uygulama için başka bir modül) verilerinizi manipüle ettiğinde, bu kod, bir arayüz veya bir sınıf sunuyorsanız önem vermemelidir.

Bu soyutlamanın bütün meselesi. Bu üçüncü taraf koduna belirli bir tipte bir nesne sunuyorsunuz. Bu tipte arayabileceğiniz bazı üye fonksiyonu vardır. Bu yeterli.

Türünüz bir arabirim veya bir sınıfsa, işletmeniz, kodunuzu kullanan birinin işi değil. Bu nedenle, kodunuzun ayrıntılarını bu üçüncü taraf koduna sızdırmamalısınız.

Bu arada, arayüzler ve sınıflar sonunda referans türleridir. Ve önemli olan da bu. Demek adlandırma kurallarının vurgulaması gereken şey bu.

Çoğu cevap, programlama dilinin Java veya C # olduğunu varsayar, burada arayüzler / soyut sınıflar için bir kavram (veya anahtar kelime) vardır. Bu gibi durumlarda, iyi bir IDE'de, bir sınıfın hangi public interface IMyClasstiple uğraştığı ve yazmanın gereksiz bir çoğaltma olduğu hemen görülür . Yazmayacağınız gibi public final FinalMyClass- her anahtar kelimeyi sınıf ismine koymayı hayal edin.

Bununla birlikte, C ++ 'a göre bence, durum başlık dosyasına dalmak ve sınıfın soyut bir sınıf olup olmadığını bulmak için herhangi bir sanal yöntemi olup olmadığına bakmak zorunda olduğu için durum biraz farklıdır. Bu durumda, yazı için açıkça bir argüman görebiliyorum class AbstractMyClass.

Yani cevabım şöyle olurdu: Bu programlama diline bağlıdır.

Güncellenme 2016: 2 yıllık C ++ deneyimi sonra muhtemelen sınıf adlarının önüne geçmenin kötü bir uygulama Abstractolduğunu düşünürdüm, ancak mantıklı olabileceği kadar karmaşık olan kod tabanları olduğunu söyleyebilirim.

Kullanmakta olduğunuz dilin deyimlerini takip edin.

Her dilin kendi deyimleri ve kodlama kuralları vardır. Örneğin, C # 'da, I ile arayüzlerin önekini koymak aptalcadır. Go, öyle değil.

(Java) kodumda, bu sözleşmeyi arayanlara maruz kaldığım API'lerde yapma eğilimindeyim:

• İşlevsellik, arayüzler vasıtasıyla ve asla sınıflar tarafından sağlanmaz.
• İşlevsel olmayan parçalar sınıflardır.

İşlevsel olmayan, ben hepsi, numaralandırma ve istisnalar (örneğin XML seri veya ORM köprü olarak hareket sınıfları gibi) saf veri yapıları gibi şeyler ifade edemez arayüzleri olmak (iyi yapabilirsiniz saf veri sınıfları için , ancak bu derslerin veri tutma dışında yaptığı hiçbir şey olmadığı için çok az kazanç için çok iş var ).

Sözleşmelerin isimlendirilmesi açısından, ara yüzler aktör isimlerine (örneğin FooBarWatcher) veya sıfatlara (örneğin FooBarWatchable) ve hem saf veri sınıflarına hem de sayımlarına aktif olmayan isimlerle eşleştirilir (örn. FooBarStatus); IDE, API tüketicisine özel adlandırma kuralları olmadan rehberlik edebilir. İstisnalar zamanki Java kurallarını (izleyin FooBarException, FooBarError, FooBarFaulttabii ki).

Ayrıca sadece kendi kurallarımı çiğnememeyi sağlamak için arayüzleri kendi paketlerine ve hatta kendi kütüphanelerine koyacağım. (Bu ayrıca, kodu WSDL belgeleri gibi harici kaynaklardan alırken yapıyı yönetmeme yardımcı olur.)