Soyut bir sınıfta arayüzler

İş arkadaşım ve ben, temel sınıflar ve arayüzler arasındaki ilişki hakkında farklı görüşler var. Bir sınıfın, bir arayüzün uygulanması gerektiğinde kullanılabiliyorsa, bir sınıfın bir arayüz uygulamaması gerektiğine inanıyoruz. Başka bir deyişle, böyle bir kod görmeyi seviyorum:

interface IFooWorker { void Work(); }

abstract class BaseWorker {
    ... base class behaviors ...
    public abstract void Work() { }
    protected string CleanData(string data) { ... }
}

class DbWorker : BaseWorker, IFooWorker {
    public void Work() {
        Repository.AddCleanData(base.CleanData(UI.GetDirtyData()));
    }
}

DbWorker, IFooWorker arayüzünü alan şeydir, çünkü arayüzün hızlı bir şekilde uygulanmasıdır. Sözleşmeyi tamamen yerine getiriyor. İş arkadaşım neredeyse aynı olanı tercih ediyor:

interface IFooWorker { void Work(); }

abstract class BaseWorker : IFooWorker {
    ... base class behaviors ...
    public abstract void Work() { }
    protected string CleanData(string data) { ... }
}

class DbWorker : BaseWorker {
    public void Work() {
        Repository.AddCleanData(base.CleanData(UI.GetDirtyData()));
    }
}

Temel sınıfın arayüzü aldığı ve bundan dolayı temel sınıfın tüm mirasçıları da bu arayüzdendir. Bu beni rahatsız ediyor, ancak “temel sınıfın dışında arayüzün bir uygulaması olarak tek başına duramaz” gibi somut nedenlerle gelemiyorum.

Metodunun lehine ve aleyhte olanlar benimkine göre neler ve neden biri diğerine karşı kullanılmalı?

Bir sınıfın, bir arayüzün uygulanması gerektiğinde kullanılabiliyorsa, bir sınıfın bir arayüz uygulamaması gerektiğine inanıyoruz.

BaseWorkerbu gereksinimi yerine getirir. Sırf bir BaseWorkernesneyi doğrudan somutlayamıyor olmanız , sözleşmeyi yerine getiren bir BaseWorker işaretçiye sahip olamayacağınız anlamına gelmez . Gerçekten de, bu soyut sınıfların bütün mesele budur.

Ayrıca, gönderdiğiniz basitleştirilmiş örnekten söylemek zordur, ancak sorunun bir kısmı, arabirimin ve soyut sınıfın gereksiz olması olabilir. Eğer uygulayan diğer sınıflar yoksa IFooWorkeranlamına değil kaynaklanıyor BaseWorker, hiç bir arayüze gerek yoktur. Arayüzler, çoklu kalıtımı kolaylaştıran ek sınırlamaları olan sadece soyut sınıflardır.

Yine basitleştirilmiş bir örnekten söylemek zor olmak gerekirse, açıkça türetilmiş bir sınıftan tabana atıfta bulunarak korunan bir yöntemin kullanılması ve arayüz uygulamasını açıklamak için açık bir yerin bulunmaması, miras yerine uygun olmayan bir miras kullandığınızın uyarı işaretleridir. bileştirme, kompozisyon. Bu miras olmadan, bütün sorunuz tartışılmaz hale geliyor.

İş arkadaşınla aynı fikirdeyim.

Her iki örnekte de BaseWorker, soyut yöntem Work () 'i tanımlar; bu, tüm alt sınıfların IFooWorker'ın sözleşmesini karşılayabileceği anlamına gelir. Bu durumda, BaseWorker'ın arayüzü uygulaması gerektiğini ve bu uygulamanın alt sınıfları tarafından miras alınacağını düşünüyorum. Bu, her bir alt sınıfın gerçekten bir IFooWorker (DRY ilkesi) olduğunu açıkça belirtmek zorunda kalmanızı önler.

Work () 'ı bir BaseWorker yöntemi olarak tanımlamıyorsanız ya da IFooWorker, BaseWorker'ın alt sınıflarının istemeyeceği veya ihtiyaç duymayacağı başka yöntemlere sahip olsaydı, o zaman (açıkça) aslında hangi alt sınıfların IFooWorker'ı uyguladığını belirtmeniz gerekirdi.

Genel olarak iş arkadaşınızla aynı fikirdeyim.

Modelinizi ele alalım: Arayüz, temel sınıf ayrıca IFooWorker yöntemlerinin ortaya çıkmasını zorlasa da, sadece çocuk sınıfları tarafından uygulanır. Öncelikle, gereksiz; alt sınıfın arayüzü uygulayıp uygulamaması, BaseWorker'in maruz kalan yöntemlerini geçersiz kılmaları gerekir ve aynı şekilde herhangi bir IFooWorker uygulamasının da BaseWorker'dan herhangi bir yardım alıp almadıklarını göstermesi gerekir.

Bu ayrıca, hiyerarşinizi belirsizleştirir; "Tüm IFooWorkers BaseWorker'lar" mutlaka doğru bir ifade değildir ve "Tüm BaseWorkers IFooWorker'lar" dır. Bu nedenle, IFooWorker veya BaseWorker'ın herhangi bir uygulaması olabilecek bir örnek değişken, parametre veya dönüş türü tanımlamak istiyorsanız (her ikisinde de kalıtımın nedenlerinden biri olan ortak işlevsellikten yararlanarak) bunların her şeyi kapsayan olması garanti edilir; Bazı BaseWorkers, IFooWorker tipi bir değişkene atanamaz ve bunun tersi de geçerlidir.

İş arkadaşınızın modelini kullanmak ve değiştirmek çok daha kolaydır. "Tüm BaseWorker'lar IFooWorkers'tır" şimdi gerçek bir ifadedir; Herhangi bir BaseWorker örneğini herhangi bir IFooWorker bağımlılığına verebilirsiniz, problem yok. Tersine "Tüm IFooWorkers BaseWorker'lar" ifadesi doğru değil; Bu, BaseWorker'ı BetterBaseWorker ile değiştirmenize izin verir ve tüketen kodunuz (IFooWorker'a bağlıdır) farkı söylemek zorunda kalmazsınız.

Bu cevaplara bir uyarı ekleyeceğim. Temel sınıfın arayüze bağlanması, o sınıfın yapısında bir kuvvet yaratır. Temel örneğinizde, ikisinin birleştirilmesi gereken bir fikir değil, ancak bu her durumda geçerli olmayabilir.

Java'nın koleksiyon çerçeve sınıflarını alın:

abstract class AbstractList
class LinkedList extends AbstractList implements Queue

Aslında Kuyruk sözleşme ile uygulanan LinkedList içine endişe itmedi AbstractList .

İki dava arasındaki fark nedir? BaseWorker'in amacı her zaman (adı ve arayüzü ile bildirildiği gibi) IWorker'da işlemleri gerçekleştirmek içindi . Amacı AbstractList ve bu Kuyruğu ıraksak, ancak eski bir descenant hala ikincisi sözleşme uygulayabilir.

Soruyu soracağım, IFooWorkeryeni bir yöntem eklemek gibi , ne zaman değişiklik yaparsınız ?

Eğer BaseWorkerarayüzü uygularsa, varsayılan olarak soyut olsa bile, yeni yöntemi bildirmek zorunda kalacaktır. Öte yandan, arabirimi uygulamazsa, yalnızca türetilmiş sınıflarda derleme hataları alırsınız.

O nedenle ben temel sınıf arabirimini uygulamak yapmak istiyorum o zamandan beri, belki türetilmiş sınıfları dokunmadan temel sınıfta yeni yöntem için tüm işlevselliğini uygulamak mümkün.

İlk önce soyut bir temel sınıfın ne olduğunu ve bir arayüzün ne olduğunu düşünün. Birini veya diğerini ne zaman ve ne zaman kullanmayacağınızı düşünün.

İnsanların her ikisinin de benzer kavramlar olduğunu düşünmeleri yaygındır, aslında ortak bir röportaj sorusu (ikisi arasındaki fark ??)

Yani soyut bir temel sınıf size, metotların varsayılan uygulamaları olan arayüzlerin sağlayamayacağı bir şey verir. (Başka şeyler var, C # 'da örneğin bir arabirimde değil, soyut bir sınıfta statik yöntemlere sahip olabilirsiniz).

Örnek olarak, bunun yaygın bir kullanımı ID'yle kullanılabilir. Soyut sınıf, IDisposable'ın Dispose yöntemini uygular; bu, temel sınıfın türetilmiş bir sürümünün otomatik olarak tek kullanımlık olacağı anlamına gelir. Daha sonra çeşitli seçeneklerle oynayabilirsiniz. Elden çıkar, türetilmiş sınıfları uygulamaya zorlayarak soyut yapın. Sanal bir varsayılan uygulama sağlayın; bu nedenle, sanallaştırmazlar ya da sanallaştırmazlar ya da soyutlaştırmazlar ve örneğin BeforeDispose, AfterDispose, OnDispose veya Disposing gibi sanal yöntemler çağırırlar.

Bu nedenle, tüm türetilmiş sınıfların arayüzü desteklemesi gerektiğinde, temel sınıfa girer. Bu arabirime yalnızca bir veya daha fazlasına ihtiyaç duyulursa türetilmiş sınıfa geçilir.

Bunların hepsi aslında basitleştirme üzerine brüt. Diğer bir alternatif, türetilmiş sınıfların arayüzleri bile uygulamaması, aynı zamanda bir adaptör deseni ile sağlamasıdır. Son zamanlarda gördüğüm bir örnek IObjectContextAdapter oldu.

Soyut bir sınıfla bir arayüz arasındaki ayrımı tam olarak kavramaktan hala yıllarım. Ne zaman temel kavramları ele aldığımı düşündüğümde stackexchange'e gidiyorum ve iki adım geri gidiyorum. Ancak konu ve OP'lerin sorusu üzerine birkaç düşünce:

İlk:

Bir arabirimin iki ortak açıklaması vardır:

1. Arabirim, herhangi bir sınıfın uygulayabileceği yöntemlerin ve özelliklerin bir listesidir ve bir arabirim uygulayarak, bir sınıf, bu yöntemleri (ve imzalarını) garanti eder ve bu özellikler (ve türleri), bu sınıfa "müdahale ederken" kullanılabilir o sınıfın bir nesnesi. Arayüz bir sözleşmedir.

2. Arayüzler, hiçbir şey yapamayan / yapamayan soyut sınıflardır. Bunlar yararlıdır çünkü bu ortalama ebeveyn sınıflarının aksine, birden fazla uygulayabilirsiniz. Mesela, BananaBread sınıfının bir nesnesi olabilirim ve BaseBread'den miras kaldım, ama bu hem IWithNuts hem de ITastesYummy arayüzlerini uygulayamayacağım anlamına gelmiyor. IDoesTheDishes arayüzünü bile uygulayabilirim, çünkü sadece ekmek değilim, biliyor musunuz?

Soyut bir sınıfın iki ortak açıklaması vardır:

1. Soyut bir sınıf, bilirsin, yapabileceği şey değil. Bu, öz gibi, aslında gerçek bir şey değil. Bekle, bu yardımcı olacak. Bir tekne soyut bir sınıftır, ancak seksi bir Playboy Yacht, BaseBoat'ın alt sınıfı olacaktır.

2. Soyut sınıflar üzerine bir kitap okudum ve belki de o kitabı okumalısınız, çünkü muhtemelen onu alamazsınız ve eğer o kitabı okumadıysanız yanlış yaparsınız.

Bu arada, Citers kitabı her zaman etkileyici görünüyor, yine de kafam karışmış olsa bile.

İkinci:

SO'da, birileri bu sorunun daha basit bir versiyonunu sordu, klasik, "Neden arayüzleri kullanıyorsunuz? Fark nedir? Neyi özlüyorum?" Bir cevap, basit bir örnek olarak bir hava kuvvetleri pilotunu kullandı. Arazi oldukça iyi değildi, ancak bir tanesi IFOble arayüzünden takeOff, pilotEject, vs. gibi yöntemlerden bahseden harika yorumlar ortaya koydu. Ve bu gerçekten benim için arayüzlerin neden sadece faydalı olmadığının gerçek dünya örneği olduğunu gösterdi. ama çok önemli. Bir arayüz bir nesneyi / sınıfı sezgisel hale getirir veya en azından olduğu hissini verir. Bir arayüz, nesnenin veya verilerin yararına değil, o nesneyle etkileşime girmesi gereken bir şey için değildir. Klasik Meyve-> Elma-> Fuji veya Şekil-> Üçgen-> Eşkenar miras örnekleri, soyundan gelen belirli bir nesneyi taksonomik olarak anlamak için harika bir modeldir. Tüketiciyi ve işlemcileri, genel nitelikleri, davranışları, nesnenin bir şeyler grubu olup olmadığı hakkında bilgilendirir, yanlış bir yere koyarsanız sisteminizi hortumlar veya duyusal verileri, belirli bir veri deposuna bir konektörü açıklar veya Bordro yapmak için gerekli finansal veriler.

Belirli bir Plane nesnesinin acil iniş için bir yöntemi olabilir veya olmayabilir, ancak acil durumEğerini sadece DumbPlane ile kaplanmış uyanmak ve geliştiricilerin quickLand ile gittiğini öğrenmek için diğer tüm değişken nesneler gibi kabul edersem sinirleneceğim çünkü hepsinin aynı olduğunu düşünüyorlardı. Tıpkı her vida imalatçısının kendi hakkını sıkıca yorumlaması olsaydı ya da TV'mde ses azaltma düğmesinin üstünde ses artırma düğmesi yoksa, nasıl sinirleneceğimi.

Soyut sınıflar, herhangi bir iniş nesnesinin o sınıf olarak nitelemesi için gerekenleri belirleyen modeldir. Bir ördeğin tüm özelliklerine sahip değilseniz, sadece tuhaf bir pengueniniz olan IQuack arayüzünü uygulamanız önemli değildir. Arayüzler, başka hiçbir şeyden emin olamadığınızda bile mantıklı olan şeylerdir. Jeff Goldblum ve Starbuck uzaylı uzayları uçurmayı başardılar çünkü arayüz güvenilir bir şekilde birbirine benziyordu.

Üçüncü:

İş arkadaşınızla aynı fikirdeyim, çünkü bazen en başta belirli yöntemleri uygulamanız gerekebilir. Bir Active Record ORM oluşturuyorsanız, bir kaydetme yöntemine ihtiyacı vardır. Bu, başlatılabilecek alt sınıfa bağlı değildir. Ve eğer ICRUD arayüzü sadece bir soyut sınıfa birleştirilmeyecek kadar taşınabilirse, diğer sınıflar tarafından, o soyut sınıfın soyundan gelen herhangi bir sınıfa aşina olan herkes için güvenilir ve sezgisel hale getirmek için uygulanabilir.

Diğer taraftan, soyut sınıfa bir arayüz bağlamak için ne zaman atlamayacağımızın daha önce çok iyi bir örnek vardı, çünkü tüm liste tipleri bir sıra arayüzü uygulayamayacak (ya da vermemeli). Bu senaryonun yarı yarıya gerçekleştiğini söylediniz, bu da sizin ve iş arkadaşınızın her zaman yarı yarıya yanlış olduğu anlamına gelir ve bu nedenle yapılacak en iyi şey tartışmayı, tartışmayı, düşünmeyi ve doğru oldukları ortaya çıktığında eşleştirmeyi kabul ve kabul etmektir. . Ancak eldeki iş için en iyisi olmasa bile bir felsefeyi izleyen bir geliştirici olmayın.

Sizin de önerdiğiniz gibi DbWorker, uygulanması gereken neden başka bir yönü var IFooWorker.

İş arkadaşınızın tarzında, herhangi bir nedenle daha sonra yeniden yapılanma meydana gelirse ve DbWorkersoyut BaseWorkersınıfı genişletmediği kabul edilirse DbWorker, IFooWorkerarayüzü kaybeder . Bu, ancak araları olmasa da, IFooWorkerara yüzünü beklerlerse tüketen müşterileri etkileyebilir .

Başlamak için, arayüzleri ve soyut sınıfları farklı tanımlamayı seviyorum:

Interface: a contract that each class must fulfill if they are to implement that interface
Abstract class: a general class (i.e vehicle is an abstract class, while porche911 is not)

Sizin durumunuzda, tüm işçiler uygular work()çünkü sözleşmenin gerektirdiği şey budur. Bu nedenle, temel sınıfınız Baseworkerbu yöntemi açıkça veya sanal bir işlev olarak uygulamalıdır. Tüm çalışanların ihtiyaç duyduğu basit gerçeklerden dolayı bu yöntemi temel sınıfınıza koymanızı öneririm work(). Bu nedenle, temel sınıfınızın (bu tür bir işaretçi oluşturamasanız bile) onu bir işlev olarak içermesi mantıklıdır.

Şimdi, arayüzü DbWorkertatmin ediyor IFooWorker, ancak bu sınıfın yapması gereken belirli bir yol varsa work(), o zaman gerçekten miras aldığı tanımı aşırı yüklemesi gerekiyor BaseWorker. Arayüzü IFooWorkerdoğrudan uygulamamasının nedeni bunun özel bir şey olmamasıdır DbWorker. O her şey yaptıysak siz benzer sınıfları uygulanacak DbWorkero zaman ihlal olacağını KURU .

İki sınıf aynı işlevi farklı şekillerde uygularsa, en büyük ortak üst sınıfı aramaya başlayabilirsiniz. Çoğu zaman bir tane bulacaksın. Olmazsa, ya bakmaya devam et ya da pes et ve temel bir sınıf yapmak için ortak noktaları olacak ortak şeyleri olmadığını kabul et.

Vay canına, tüm bu cevaplar ve hiçbiri örnekteki arayüzün hiçbir işe yaramadığına işaret etmiyor. Kalıtım ve aynı yöntem için bir arabirim kullanmazsınız, bu anlamsızdır. Birini veya diğerini kullanıyorsun. Bu forumda, birinin veya diğerinin çağrısında bulunan senariosun yararlarını açıklayan cevaplarla ilgili pek çok soru var.