Sadece bir sınıfın uygulayacağı bir arayüz kullanmam gerekir mi?

Çoklu sınıfların oluşturduğu bir arayüzün amacı bir dizi kural ve uygulamaya uymuyor mu?

Açıkçası, hayır, yapmazsınız , YAGNI uygulanır. Bununla birlikte, arayüzü oluşturmak için harcayacağınız zaman minimumdur, özellikle işin çoğunu sizin için yapan kullanışlı bir kod oluşturma aracınız varsa. Arayüzüne ihtiyacınız olup olmayacağından emin değilseniz, ara yüz tanımını destekleme yönüne doğru yanılmanın daha iyi olacağını söyleyebilirim.

Ayrıca, tek bir sınıf için bile bir arayüz kullanmak, üretimde olmayan, birim testleri için başka bir sahte uygulama sağlayacaktır. Avner Shahar-Kashtan'ın cevabı bu noktada genişliyor.

Sana bir arabirim gerek olup olmadığı anlamına cevap verecek değil birçok sınıfları bunu nasıl uygulayacağınızı bağlıdır. Arabirimler, uygulamanızın birden fazla alt sistemi arasındaki sözleşmeleri tanımlamak için bir araçtır ; Yani asıl önemli olan, başvurunuzun alt sistemlere nasıl bölündüğüdür. Kapsanan altsistemleri ön plana çıkaran, kaç tane sınıf uyguladıklarına bakmadan arayüzler olmalıdır.

İşte çok kullanışlı bir kural:

• FooDersi doğrudan sınıfa yönlendirirseniz BarImpl, Fooher değiştiğinde kendiniz değişmeye kararlısınız BarImpl. Temel olarak, bunları iki sınıfa bölünmüş bir kod birimi olarak görüyorsunuz.
• Eğer yaparsanız Foobakın arayüzüne Bar yapmanız yerine kendinizi işliyorsun önlemek için değişiklikler Foodeğiştirmek zaman BarImpl.

Arayüzleri uygulamanızın kilit noktalarında tanımlarsanız, desteklemeleri gereken ve yapmamaları gereken yöntemler hakkında dikkatli düşünürsünüz ve bir uygulamanın nasıl davranması gerektiğini (ve nasıl yapmaması gerektiğini) açık bir şekilde yorumluyorsunuz, Uygulamanızın anlaşılması çok daha kolay olacaktır, çünkü bu yorumlanmış arayüzler uygulamanın bir tür belirtimini sunacaktır - nasıl davranması amaçlandığının bir açıklaması . Bu, kodu okumayı çok daha kolaylaştırır ("bu kodun ne yapması gerektiğini" sormak yerine, bu kodun yapması gerekeni nasıl yaptığını "sormak yerine").

Tüm bunlara ek olarak (veya aslında bundan dolayı), arayüzler ayrı derlemeyi teşvik eder. Arabirimler derleme için önemsiz ve uygulamalarından daha az bağımlılığa sahip olduklarından, Foobir arabirim kullanmak için sınıf Baryazarsanız, genellikle yeniden derlemeye BarImplgerek kalmadan yeniden derleyebilirsiniz Foo. Büyük uygulamalarda bu çok zaman kazandırabilir.

Arabirimler, bir davranışı, yani bir işlev / yöntem prototip kümesini tanımlayacak şekilde tasarlanmıştır. Arabirimi uygulayan türler bu davranışı uygular; bu nedenle, böyle bir türle uğraşırken ne tür bir davranış olduğunu biliyorsunuzdur.

Tanımladığı davranışın yalnızca bir kez kullanılacağını biliyorsanız, bir arabirim tanımlamanıza gerek yoktur. KISS (basit tut, aptal)

Teoride, sadece bir arayüzün iyiliği için bir arayüzün olmamasına rağmen, Yannis Rizos'un cevabı başka komplikasyonlara işaret ediyor:

Birim testleri yazarken ve Moq veya FakeItEasy gibi sahte çerçeveler kullanırken (kullandığım en yeni iki ismi adlandırmak için), dolaylı olarak arayüzü uygulayan başka bir sınıf yaratıyorsunuzdur. Kod veya statik analizlerde arama yapmak, yalnızca bir uygulama olduğunu iddia edebilir, ancak aslında iç alay uygulaması da vardır. Ne zaman alay yazmaya başlarsanız, arayüzleri ayıklamanın mantıklı olduğunu göreceksiniz.

Fakat bekleyin, dahası var. Örtük arabirim uygulamalarının olduğu daha fazla senaryo vardır. Örneğin, .NET'in WCF iletişim yığını kullanılarak uzak bir servise bir proxy oluşturulur ve bu da arayüzü tekrar uygular.

Temiz bir kod ortamında, cevapların geri kalanına burada katılıyorum. Bununla birlikte, arayüzleri kullanabileceğiniz çerçevelere, kalıplara veya bağımlılıklara dikkat edin.

Hayır, onlara ihtiyacınız yok ve ben her sınıf referansı için otomatik olarak arayüzler yapmayı anti-pattern olarak görüyorum.

Her şey için Foo / FooImpl yapmanın gerçek bir maliyeti var. IDE ücretsiz olarak arayüz / uygulama yaratabilir, ancak koda giderken, istediğiniz foo.doSomething()gerçek uygulamaya değil, sizi arayüz imzasına götürmek için F3 / F12'den ekstra bilişsel yüke sahip olursunuz. Ayrıca her şey için bir dosya yerine iki dosya yığınına sahipsiniz.

Bu yüzden sadece bir şey için gerçekten ihtiyacınız olduğunda yapmalısınız.

Şimdi karşılıkları ele alıyoruz:

Bağımlılık enjeksiyon çerçeveleri için arayüzlere ihtiyacım var

Çerçeveleri destekleyen arayüzler eskidir. Java'da arayüzler, CGLIB öncesi dinamik proxy'ler için bir gereklilikti. Bugün, genellikle ona ihtiyacın yok. EJB3, Spring vb. Artık onlara ihtiyaç duymanıza gerek kalmayacağına, geliştirici üretkenliği için bir ilerleme ve nimet olarak kabul edilir.

Birim testi için alaycılara ihtiyacım var

Kendi alaylarınızı yazıp iki gerçek uygulamanız varsa, o zaman bir arayüz uygundur. Kod tabanınızda bir FooImpl ve bir TestFoo olsaydı muhtemelen bu tartışmayı ilk etapta yapmazdık.

Ancak, Moq, EasyMock veya Mockito gibi alaycı bir çerçeve kullanıyorsanız, sınıflarla alay edebilirsiniz ve arayüzlere ihtiyacınız yoktur. foo.method = mockImplementationYöntemlerin atanabileceği dinamik bir dilde ayarlamaya benzer .

Bağımlılık İnversiyon Prensibi'ni (DIP) takip etmek için arayüzlere ihtiyacımız var.

DIP, sözleşmelere (arayüzler) bağlı kaldığınızı ve uygulamalara bağlı olmadığını söylüyor. Ancak bir sınıf zaten bir sözleşme ve bir soyutlamadır. Genel / özel anahtar kelimeler bunun içindir. Üniversitede kanonik örnek bir Matris veya Polinom sınıfına benzer bir şeydi - tüketicilerin matrisler oluşturmak, eklemek, vb. İçin genel bir API'leri var, ancak matrisin seyrek veya yoğun biçimde uygulanıp uygulanmadığına bakmalarına izin verilmiyor. Bu noktayı kanıtlamak için IMatrix ya da MatrixImpl gerekli değildi.

Ayrıca, DIP genellikle yalnızca ana modül sınırlarında değil, her sınıf / yöntem çağrısı düzeyinde aşırı uygulanır. DIP'yi aşırı uyguladığınızın bir işareti, arabiriminizin ve uygulamanızın kilit adımda değiştiğinden, bir değişiklik yapmak için iki dosyaya dokunmanız gerekeceğidir. DIP uygun şekilde uygulanırsa, arayüzünüzün sık sık değişmemesi gerektiği anlamına gelir. Ayrıca, bir başka işaret, arayüzünüzün yalnızca bir gerçek tüketiciye sahip olduğudur (kendi uygulaması). Farklı bir hikaye, birçok farklı uygulamada tüketim için bir sınıf kitaplığı oluşturuyorsanız.

Bu Bob Amca'nın alay konusu ile ilgili noktalarının bir sonucudur - yalnızca büyük mimari sınırlarla alay etmeniz gerekir. Bir webapp'ta HTTP ve DB erişimi ana sınırlardır. Aradaki tüm sınıf / yöntem çağrıları değil. Aynı DIP için de geçerli.

Ayrıca bakınız:

• http://www.adam-bien.com/roller/abien/entry/service_s_new_serviceimpl
• http://martinfowler.com/bliki/InterfaceImplementationPair.html
• https://blog.8thlight.com/uncle-bob/2014/05/10/WhenToMock.html
• http://wrschneider.github.io/2015/07/27/foo-fooimpl-pairs.html

Çitin her iki tarafındaki cevaplar şöyle özetlenebilir:

İyi tasarlayın ve arayüzlerin gerekli olduğu arayüzleri yerleştirin.

Yanni'nin cevabına cevabımda belirttiğim gibi , arayüzler hakkında çok katı ve hızlı bir kuralın olabileceğini düşünmüyorum. Kural, tanım gereği esnek olmalıdır. Arayüzler konusundaki kuralım, bir arayüzün, API oluşturduğunuz her yerde kullanılması gerektiğidir. Ayrıca, sınırı bir sorumluluk alanından diğerine geçtiğiniz her yerde bir API oluşturulmalıdır.

(Korkunç biçimde tartışılan) bir örnek için, bir Carsınıf oluşturduğunuzu varsayalım. Sınıfınızda kesinlikle bir UI katmanına ihtiyacınız olacak. Bu özel örnekte, bir biçimini alır IginitionSwitch, SteeringWheel, GearShift, GasPedal, ve BrakePedal. Bu araba bir içerdiğinden, bir AutomaticTransmissionihtiyacınız yok ClutchPedal. (Ve bu korkunç bir araba olduğu için, klima, radyo ya da koltuk yok. Aslında, döşeme tahtaları da eksik.

Peki bu sınıflardan hangisinin bir arayüze ihtiyacı var? Cevap, tasarımınıza bağlı olarak hepsi ya da hiçbiri olabilir.

Şuna benzeyen bir arayüze sahip olabilirsiniz:

Interface ICabin
    Event IgnitionSwitchTurnedOn()
    Event IgnitionSwitchTurnedOff()
    Event BrakePedalPositionChanged(int percent)
    Event GasPedalPositionChanged(int percent)
    Event GearShiftGearChanged(int gearNum)
    Event SteeringWheelTurned(float degree)
End Interface

Bu noktada, bu sınıfların davranışı, ICabin Arayüzü / API'sinin bir parçası haline gelir. Bu örnekte, sınıflar (eğer varsa) muhtemelen birkaç özellik ve bir veya iki fonksiyonla basit. Ve tasarımınızla örtük olarak belirttiğiniz şey, bu sınıfların yalnızca sahip olduğunuz herhangi bir ICabin somut uygulamasını desteklemek için var olduğu ve kendi başlarına olamayacakları veya ICabin bağlamı dışında anlamsız olduklarıdır.

Özel üyelerin birim testini yapmamanızın nedeni aynıdır - bunlar yalnızca herkese açık API'yi desteklemek için vardır ve bu nedenle davranışları API'yi test ederek test edilmelidir.

Eğer sınıfınız yalnızca başka bir sınıfı desteklemek için mevcutsa ve kavramsal olarak onu gerçekten kendi etki alanına sahip olmadığını görüyorsanız , o zaman arayüzü atlamak iyi olur. Ancak, sınıfınız kendi etki alanı için yeterince büyüdüğünü düşündüğünüz ölçüde önemliyse, devam edin ve bir arabirim verin.

DÜZENLE:

Sık sık (bu cevaba dahil) 'domain', 'bağımlılık' (sıklıkla 'enjeksiyon' ile birleştiğinde) gibi programlamaya başladığınızda sizin için bir anlam ifade etmeyen şeyleri okuyacaksınız (kesinlikle benim için bir şey ifade). Etki alanı için, tam olarak neye benzediği anlamına gelir:

Egemenliğin veya otoritenin kullanıldığı bölge; egemen veya ortak bir mal varlığına veya benzerlerine sahip olmak. Figüratif olarak da kullanılır. [WordNet sense 2] [1913 Webster]

Benim örneğim açısından - en düşünelim IgnitionSwitch. Bir et otomobilinde, kontak anahtarı şunlardan sorumludur:

1. Kullanıcının kimliğini doğrulama (tanımlama değil) (doğru anahtara ihtiyaçları var)
2. Marş motoru için akım sağlanması, böylece gerçekten aracı çalıştırabilir.
3. Ateşleme sistemine akım sağlanması, çalışmaya devam edebilmesi için
4. Akımın kapatılması, böylece otomobil duracaktır.
5. Nasıl gördüğünüze bağlı olarak, çoğu (hepsinde?) Yeni otomobillerde, şanzıman Park dışındayken anahtarın kontaktan çıkarılmasını önleyen bir anahtar vardır, bu nedenle bu etki alanının bir parçası olabilir. (Aslında sistemimi yeniden düşünmem ve yeniden tasarlamam gerektiği anlamına geliyor ...)

Bu özellikler oluşturan domain arasında IgnitionSwitchveya başka bir deyişle, ne bilir ve sorumludur.

Bu IgnitionSwitchsorumlu değildir GasPedal. Kontak anahtarı her yönden gaz pedalını tamamen görmezden gelir. Her ikisi de birbirinden tamamen bağımsız olarak çalışır (bir araba her ikisi de olmadan oldukça değersizdir!).

İlk başta belirttiğim gibi, tasarımınıza bağlı. IgnitionSwitchİki değeri olan birini tasarlayabilirsiniz : On ( True) ve Off ( False). Veya, kendisine sağlanan anahtarı ve başka bir dizi eylemi doğrulamak için tasarlayabilirsiniz. Bu, geliştirici olmanın zor kısmı, çizgileri kumda nereye çekeceğine karar vermektir - ve dürüst olmak gerekirse, çoğu zaman tamamen görecelidir. Kumdaki bu çizgiler yine de önemlidir - API'nizin olduğu ve dolayısıyla arayüzlerinizin olması gereken yer burasıdır.

Hayır (YAGNI) , bu arayüzü kullanarak diğer sınıflar için testler yazmayı planlamıyorsanız ve bu testler arayüzü alaydan faydalanabilir.

Gönderen MSDN :

Arabirimler, uygulamalarınızın, belirli işlevsellik sağlamak için muhtemelen ilgisiz birçok nesne türü gerektirdiği durumlar için daha uygundur.

Arayüzler temel sınıflardan daha esnektir, çünkü çoklu arayüzleri uygulayabilecek tek bir uygulama tanımlayabilirsiniz.

Arayüzler, uygulamayı bir temel sınıftan devralmanız gerekmediği durumlarda daha iyidir.

Arayüzler, sınıf mirasını kullanamadığınız durumlarda kullanışlıdır. Örneğin, yapılar sınıflardan miras alamazlar fakat arayüzleri uygulayabilirler.

Genel olarak, tek bir sınıf söz konusu olduğunda, bir arayüz uygulamak gerekli olmayacak, ancak projenizin geleceği göz önünde bulundurularak, sınıfların gerekli davranışlarını resmi olarak tanımlamak faydalı olabilir.

Soruyu cevaplamak için: Bundan daha fazlası var.

Bir arabirimin önemli bir yönü niyettir.

Arabirim "veri içermeyen, ancak davranışları ortaya çıkaran soyut bir tür" dür - Arayüz (hesaplama) Eğer bu bir davranış veya bir davranış dizisiyse, sınıfın desteklediği, bir arayüz muhtemelen doğru kalıp olabilir. Bununla birlikte, davranış (lar) sınıf tarafından somutlaştırılan konsepte özgüdürse, muhtemelen bir arayüz istemezsiniz.

Sorulması gereken ilk soru, temsil etmeye çalıştığınız şeyin ya da sürecin niteliğidir. Ardından, bu doğayı belirli bir şekilde uygulamak için pratik sebeplerle devam edin.

Bu soruyu sorduğunuzdan beri, birden çok uygulamayı gizleyen bir arayüze sahip olmanın ilgi alanlarını çoktan gördüğünüzü farz ediyorum. Bu bağımlılık inversiyon ilkesi ile kendini gösterebilir.

Bununla birlikte, bir ara yüze sahip olma ya da olmama zorunluluğu, uygulama sayısına bağlı değildir. Arayüzün asıl rolü, nasıl uygulanması gerektiği yerine hangi hizmetin verilmesi gerektiğini belirten bir sözleşmeyi tanımlamasıdır.

Sözleşme tanımlandıktan sonra iki veya daha fazla ekip bağımsız olarak çalışabilir. Modül A üzerinde çalıştığınızı ve B modülüne bağlı olduğunu, B'de bir arayüz oluşturmanın gerçeğinin, B'nin uygulaması hakkında endişelenmeden çalışmanıza devam etmesini sağladığını gösterir, çünkü tüm detaylar arayüz tarafından gizlenir. Böylece, dağıtılmış programlama mümkün hale gelir.

B modülü, arayüzünün sadece bir uygulaması olmasına rağmen, arayüz hala gereklidir.

Sonuç olarak, bir arayüz uygulama detaylarını kullanıcılarından gizlemektedir. Arayüze programlama daha fazla belge yazmaya yardımcı olur çünkü sözleşme tanımlanmalı, daha modüler yazılımlar yazılmalı, ünite testlerinin teşvik edilmesi ve geliştirme hızının arttırılması sağlanmalıdır.

Buradaki tüm cevaplar çok iyi. Aslında çoğu zaman farklı bir arayüz uygulamanıza gerek kalmaz . Ama durum vardır olabilir yine de yapmak istiyorum. İşte yaptığım bazı durumlar:

Sınıf,
Happen'i sık sık ortaya çıkarmak istemediğim başka bir arabirim uygular ve üçüncü taraf kodunu köprüleyen adaptör sınıfıyla birlikte olur.

interface NameChangeListener { // Implemented by a lot of people
    void nameChanged(String name); 
} 

interface NameChangeCount { // Only implemented by my class
    int getCount();
}

class NameChangeCounter implements NameChangeListener, NameChangeCount {
    ...
}

class SomeUserInterface {
    private NameChangeCount currentCount; // Will never know that you can change the counter
}

Sınıf,
çoğunlukla dış kütüphanelerle etkileşime girdiğinde sızıntı yapmaması gereken belirli bir teknolojiyi kullanır . Tek bir uygulama olsa bile, harici kütüphane ile gereksiz eşleştirme yapmadığımdan emin olmak için bir arayüz kullanıyorum.

interface SomeRepository { // Guarantee that the external library details won't leak trough
    ...
}

class OracleSomeRepository implements SomeRepository { 
    ... // Oracle prefix allow us to quickly know what is going on in this class
}

Çapraz katman iletişimi
Yalnızca bir UI sınıfı etki alanı sınıfından birini uygulasa bile, bu katman arasında daha iyi ayrım yapılmasına izin verir ve en önemlisi döngüsel bağımlılığı önler.

package project.domain;

interface UserRequestSource {
    public UserRequest getLastRequest();
}

class UserBehaviorAnalyser {
    private UserRequestSource requestSource;
}

package project.ui;

class OrderCompleteDialog extends SomeUIClass implements project.domain.UserRequestSource {
    // UI concern, no need for my domain object to know about this method.
    public void displayLabelInErrorMode(); 

    // They most certainly need to know about *that* though
    public UserRequest getLastRequest();
}

Yöntemin yalnızca bir alt kümesi çoğu nesneye uygun olmalıdır.
Çoğunlukla somut sınıfta bazı yapılandırma yöntemlerine sahipsem

interface Sender {
    void sendMessage(Message message)
}

class PacketSender implements Sender {
    void sendMessage(Message message);
    void setPacketSize(int sizeInByte);
}

class Throttler { // This class need to have full access to the object
    private PacketSender sender;

    public useLowNetworkUsageMode() {
        sender.setPacketSize(LOW_PACKET_SIZE);
        sender.sendMessage(new NotifyLowNetworkUsageMessage());

        ... // Other details
    }
}

class MailOrder { // Not this one though
    private Sender sender;
}

Sonunda, özel alan kullanmamla aynı sebepten dolayı arayüzü kullanıyorum: diğer nesnenin erişmemesi gereken şeylere erişimi olmamalı. Böyle bir durum varsa, sadece bir sınıf uygulasa bile bir arayüz tanıtırım .

Arayüzler gerçekten önemlidir, ancak sahip olduğunuz sayısını kontrol etmeye çalışın.

Hemen hemen her şey için arayüz oluşturma yoluna girdikten sonra 'doğranmış spagetti' koduyla bitmek kolaydır. Konuyla ilgili çok akıllıca sözler yazan Ayende Rahien'in bilgeliğini erteliyorum:

http://ayende.com/blog/153889/limit-your-abstractions-analyzing-a-ddd-application

Bu onun bütün dizinin ilk yayınıdır, okumaya devam et!

Bu durumda hala bir arayüz tanıtmak isteyebileceğiniz bir neden, Bağımlılık İnversiyon Prensibi'ni takip etmektir . Yani, sınıfı kullanan modül, somut bir uygulamaya bağlı olmak yerine bunun bir soyutlamasına (yani arayüz) bağlı olacaktır. Yüksek seviye bileşenleri düşük seviye bileşenlerden ayırır.

Hiçbir şey yapmanın gerçek bir nedeni yok. Arayüzler çıktı programını değil size yardımcı olmak içindir. Arayüz bir milyon sınıf tarafından uygulansa bile, bir tane oluşturmanız gerektiğini söyleyen bir kural yoktur. Siz ya da kodunuzu kullanan bir başkası, onun tüm uygulamalarıyla örtüşen bir şeyi değiştirmek istediğinde, bir tane yaratırsınız. Arabirim oluşturmak, onu uygulayacak başka bir sınıf oluşturmak isteyebileceğiniz tüm gelecekteki durumlarda size yardımcı olacaktır.

Bir sınıf için bir arayüz tanımlamaya her zaman gerek yoktur.

Değer nesneleri gibi basit nesnelerin birden fazla uygulaması yoktur. Onların da alay edilmelerine gerek yok. Uygulama kendi başına test edilebilir ve bunlara bağlı diğer sınıflar test edildiğinde gerçek değer nesnesi kullanılabilir.

Bir arayüz oluşturmanın bir maliyeti olduğunu unutmayın. Uygulama boyunca güncellenmesi gerekiyor, fazladan bir dosyaya ihtiyacı var ve bazı IDE arabirimde değil uygulamada yakınlaştırma konusunda sorun yaşayacak.

Bu yüzden arayüzleri sadece uygulamadan bir soyutlama yapmak istediğiniz yüksek seviyeli sınıflar için tanımlayacağım.

Bir sınıfla ücretsiz olarak bir arayüz elde edebileceğinizi unutmayın. Uygulamanın yanı sıra, bir sınıf, kamu yöntem kümesinden bir arayüz tanımlar. Bu arayüz türetilmiş tüm sınıflar tarafından uygulanır. Kesinlikle bir arayüzden bahsetmiyor, fakat aynı şekilde kullanılabilir. Bu yüzden, sınıf adı altında zaten var olan bir arayüzü yeniden yaratmanın gerekli olduğunu düşünmüyorum.