Soyut sınıflar / yöntemler eski midir?

Bir sürü soyut sınıf / yöntem yaratırdım. Sonra arayüzleri kullanmaya başladım.

Şimdi, arayüzlerin soyut sınıfları modası geçmiş kılmadığından emin değilim.

Tamamen soyut bir sınıfa mı ihtiyacınız var? Bunun yerine bir arayüz oluşturun. İçinde bazı uygulamalar olan soyut bir sınıfa mı ihtiyacınız var? Bir arayüz oluşturun, bir sınıf oluşturun. Sınıfı devralın, arayüzü uygulayın. Ek bir fayda, bazı sınıfların üst sınıfa ihtiyaç duymayabileceği, ancak sadece arayüzü uygulayacağıdır.

Peki soyut sınıflar / yöntemler eski midir?

Hayır.

Arayüzler varsayılan uygulama sağlayamaz, soyut sınıflar ve metotlar sağlayabilir. Bu, özellikle çoğu durumda kod çoğaltılmasını önlemek için kullanışlıdır.

Bu aynı zamanda sıralı kuplajı azaltmanın gerçekten güzel bir yoludur. Soyut yöntem / sınıflar olmadan, şablon yöntem desenini uygulayamazsınız. Bu wikipedia makalesine bakmanı öneriyorum: http://en.wikipedia.org/wiki/Template_method_pattern

Soyut bir yöntem var, böylece onu temel sınıfınızdan arayabilir, ancak türetilmiş bir sınıfta uygulayabilirsiniz. Yani temel sınıfınız bilir:

public void DoTask()
{
    doSetup();
    DoWork();
    doCleanup();
}

protected abstract void DoWork();

Kurulum ve temizleme faaliyetleri hakkında türetilmiş bir sınıf olmadan orta kalıpta bir delik açmanın oldukça iyi bir yolu. Soyut yöntemlerle olmadan, türetilmiş sınıf uygulamak güvenmek zorunda kalacak DoTaskve aramaya hatırlamak base.DoSetup()ve base.DoCleanup()her zaman.

Düzenle

Ayrıca, yukarıda açıkladığım şekliyle ismini bilmeden Şablon Metodu Örüntüsüne bir bağlantı gönderdiği için deadalnix'e teşekkürler . :)

Hayır, onlar eski değil.

Aslında, Soyut Sınıflar / Yöntemler ve Arayüzler arasında belirsiz fakat temel bir fark vardır.

bunlardan birinin kullanılması gereken sınıflar kümesinin paylaştıkları ortak bir davranışları varsa (ilgili sınıflar, yani), Soyut sınıflar / yöntemler için gidin.

Örnek: memur, Memur, Yönetmen -Tüm bu sınıfların hepsinde ortak olarak CalculateSalary () vardır, soyut temel sınıfları kullanın.

Sınıflarınızın aralarında ortak bir şey yoksa (İlişkili olmayan sınıflar, seçilen bağlamda) aralarında ama uygulamada oldukça farklı bir eylem varsa, Arayüz'e gidin.

Örnek: İnek, tezgah, araba, teleskopla ilgili olmayan sınıflar ancak Sıralanabilir onları bir dizide sıralamak için orada olabilir.

Polimorfik bir perspektiften yaklaşıldığında bu fark genellikle göz ardı edilir. Ancak şahsen, yukarıda açıklanan nedenden dolayı birinin diğerinden daha uygun olduğu durumlar olduğunu hissediyorum.

Diğer iyi cevaplara ek olarak, arayüzler ve kimsenin özel olarak bahsetmediği soyut sınıflar arasında temel bir fark vardır, yani arayüzlerin çok daha az güvenilir olması ve bu nedenle soyut sınıflardan çok daha büyük bir test yükü getirmesi . Örneğin, bu C # kodunu göz önünde bulundurun:

public abstract class Frobber
{
    private Frobber() {}
    public abstract void Frob(Frotz frotz);
    private class GreenFrobber : Frobber
    { ... }
    private class RedFrobber : Frobber
    { ... }
    public static Frobber GetFrobber(bool b) { ... } // return a green or red frobber
}

public sealed class Frotz
{
    public void Frobbit(Frobber frobber)
    {
         ...
         frobber.Frob(this);
         ...
    }
}

Test etmem gereken yalnızca iki kod yolu olduğunu garanti ediyorum. Frobbit'in yazarı, frobberın kırmızı veya yeşil olduğu gerçeğine güvenebilir.

Öyleyse deriz ki:

public interface IFrobber
{
    void Frob(Frotz frotz);
}
public class GreenFrobber : IFrobber
{ ... }
public class RedFrobber : Frobber
{ ... }

public sealed class Frotz
{
    public void Frobbit(IFrobber frobber)
    {
         ...
         frobber.Frob(this);
         ...
    }
}

Şimdi buradaki Frob'a olan çağrının etkileri hakkında hiçbir şey bilmiyorum . Frobbit'teki tüm kodların, IFrobber'in olası uygulamalarına karşı sağlam olmasına , hatta beceriksiz (kötü) veya aktif olarak bana veya kullanıcılarına (çok daha kötü) karşı olan kişilerin uygulamalarına karşı emin olmam gerekiyor .

Soyut sınıflar tüm bu sorunlardan kaçınmanıza izin verir; onları kullan!

Sen kendin söyledin:

İçinde bazı uygulamalar olan soyut bir sınıfa mı ihtiyacınız var? Bir arayüz oluşturun, bir sınıf oluşturun. Sınıfı devralmak, arayüzü uygulamak

Bu, 'soyut sınıfa miras' ile karşılaştırıldığında çok fazla iş geliyor. 'Saf' bir bakış açısından koda yaklaşarak kendiniz için çalışabilirsiniz, ancak iş yüküme eklemeye pratik bir fayda sağlamaya çalışmaksızın zaten yapacak kadar işim olduğunu biliyorum.

@Deadnix yazısında yorumda bulunduğum gibi: Kısmi uygulamalar, kalıp deseni onları biçimlendirmiş olmasına rağmen, bir kalıp karşıtıdır.

Şablon şablonunun bu wikipedia örneği için temiz bir çözüm :

interface Game {
    void initialize(int playersCount);
    void makePlay(int player);
    boolean done();
    void finished();
    void printWinner();
}
class GameRunner {
    public void playOneGame(int playersCount, Game game) {
        game.initialize(playersCount);
        int j = 0;
        for (int i = 0; !game.finished(); i++)
             game.makePlay(i % playersCount);
        game.printWinner();
    }
} 
class Monopoly implements Game {
     //... implementation
}

Bu çözüm daha iyidir, çünkü kalıtım yerine kompozisyon kullanır . Şablon kalıbı, Tekel kurallarının uygulanması ile oyunların nasıl yürütüleceği konusunda bir bağımlılık ortaya koymaktadır. Ancak bunlar tamamen farklı sorumluluklardır ve onları birleştirmek için iyi bir sebep yoktur.

Hayır. Önerilen alternatifiniz bile soyut sınıfların kullanımını içerir. Ayrıca, dili belirtmediğiniz için, hemen devam edeceğim ve genel kodun yine de kırılganlık kalıtımından daha iyi bir seçenek olduğunu söyleyeceğim. Soyut sınıfların arayüzlere göre önemli avantajları vardır.

Soyut sınıflar arayüz değildir. Bunlar somutlaştırılamayan sınıflar.

Tamamen soyut bir sınıfa mı ihtiyacınız var? Bunun yerine bir arayüz oluşturun. İçinde bazı uygulamalar olan soyut bir sınıfa mı ihtiyacınız var? Bir arayüz oluşturun, bir sınıf oluşturun. Sınıfı devralın, arayüzü uygulayın. Ek bir fayda, bazı sınıfların üst sınıfa ihtiyaç duymayabileceği, ancak sadece arayüzü uygulayacağıdır.

Ama sonra soyut olmayan işe yaramaz bir sınıfa sahip olacaktınız. Temel sınıftaki işlevselliği doldurmak için soyut yöntemler gerekir.

Örneğin, bu sınıfa verilen

public abstract class Frobber {
    public abstract void Frob();

    public abstract boolean IsFrobbingNeeded { get; }

    public void FrobUntilFinished() {
        while (IsFrobbingNeeded) {
            Frob();
        }
    }
}

Bu temel işlevselliği, ne Frob()de ne olmayan bir sınıfta nasıl uygularsınız IsFrobbingNeeded?

Soyut sınıfların temel rol oynadığı bir servlet çerçevesi yaratıcısıyım. Daha fazlasını söyleyeyim,% 50 durumlarda bir yöntemin geçersiz kılınması gerektiğinde yarı derleyici yöntemlere ihtiyacım var ve derleyiciden bu yöntem hakkında uyarılmadığını görmek istiyorum. Ek açıklama ekleme sorununu çözerim. Sorunuza geri dönersek, iki farklı kullanım soyut sınıf ve arayüz durumu vardır ve şu ana kadar kimse eski değildir.

Arayüzlerin saplantılı olduklarını sanmıyorum, fakat strateji paterni tarafından sapmış olabilirler.

Soyut bir sınıfın birincil kullanımı, uygulamanın bir bölümünü ertelemektir; "Sınıfın uygulanmasının bu kısmı farklı olabilir" demek.

Ne yazık ki, soyut bir sınıf müşteriyi bunu miras yoluyla yapmaya zorlar . Oysaki strateji kalıbı, aynı sonucu herhangi bir kalıtım olmadan elde etmenize izin verecektir. Müşteri, her zaman kendi tanımını yapmak yerine sınıfınıza örnekler verebilir ve sınıfın "uygulaması" (davranışı) dinamik olarak değişebilir. Strateji modeli ek bir artıya sahiptir; bu davranış sadece tasarım zamanında değil aynı zamanda çalışma zamanında da değiştirilebilir ve ayrıca ilgili türler arasında önemli ölçüde daha az birleşme vardır.

Genelde, saf arayüzlerle ilgili, çok sayıda kalıtımda kullanılan ABC'ler bile, ABC'lerden çok daha uzak, çok daha fazla bakım sorunuyla karşı karşıya kaldım. YMMV - bilmiyorum, belki ekibimiz onları yetersiz kullandı.

Bununla birlikte, eğer gerçek bir dünya analojisi kullanırsak, işlevsellik ve durumdan tamamen yoksun olan saf arayüzler için ne kadar faydası var? USB'yi örnek olarak kullanırsam, bu oldukça kararlı bir arayüzdür (bence şimdi USB 3.2'deyiz, ancak geriye dönük uyumluluk da var).

Yine de vatansız bir arayüz değil. İşlevsellikten yoksun değil. Saf bir arayüzden çok soyut bir temel sınıf gibidir. Çok özel fonksiyonel ve devlet gereklilikleri olan somut bir sınıfa daha yakındır; sadece soyutlama, limana takılan tek ikame parçadır.

Aksi taktirde, standart bir form faktörü ve bilgisayarınızda her deliğin bir şey yapması için kendi donanımı olana kadar kendi başına bir şey yapamayan daha gevşek fonksiyonel gereksinimleri olan bilgisayarınızda sadece bir "delik" olacaktır. çok daha zayıf bir standart haline gelir ve bir "delikten" ve ne yapması gerektiğine dair bir spesifikasyondan başka bir şey olmaz, ama nasıl yapılacağına dair merkezi bir hüküm yoktur. Bu arada, tüm donanım üreticileri işlevsellik eklemek ve bu “deliğe” belirtmek için kendi yollarını bulmaya çalıştıktan sonra bunu yapmanın 200 farklı yolunu bulabiliriz.

Ve bu noktada başkalarına göre farklı problemler ortaya çıkaran bazı üreticilerimiz olabilir. Şartnameyi güncellememiz gerekirse, güncellenmesi ve test edilmesi gereken şartnamelerin tamamen farklı yöntemlerle ele alınması için 200 farklı somut USB port uygulaması olabilir. Bazı üreticiler kendi aralarında paylaştığı fiili standart uygulamalar geliştirebilir (bu arayüzü uygulayan analog temel sınıfınız), ancak hepsi değil. Bazı sürümler diğerlerinden daha yavaş olabilir. Bazıları daha iyi verime sahip olabilir, ancak daha kötü gecikme süresi veya bunun tersi olabilir. Bazıları diğerlerinden daha fazla pil gücü kullanabilir. Bazıları sönebilir ve USB bağlantı noktalarıyla çalışması gereken tüm donanımlarla çalışmayabilir. Bazıları, kullanıcılarına radyasyon zehirlenmesi verme eğiliminde olan bir nükleer reaktörün çalışmasına bağlanabilir.

Ve şahsen saf arayüzlerle bulduğum şey buydu. Bir anakartın form faktörünü bir CPU vakasına karşı modellemek gibi, mantıklı oldukları bazı durumlar olabilir. Form faktörü analojileri, aslında, analog "delik" ile olduğu gibi, hemen hemen hiç vatansızdır ve işlevsellikten yoksundur. Ancak çoğu zaman takımların yakın, hatta her durumda bir şekilde daha üstün olduğunu düşünmelerini büyük bir hata olarak görüyorum.

Aksine, takımınız o kadar devasa olmadıkça iki seçenek olsa, ABC'ler tarafından arayüzlerden ziyade daha fazla vakanın daha iyi çözüleceğini düşünüyorum. korumak, sağlamak, sürdürmek. İçinde bulunduğum eski bir takımda, aslında ABC'lerin ve çoklu kalıtımın sağlanması için ve özellikle yukarıda açıklanan bakım sorunlarına cevap olarak kodlama standardını gevşetmek için çok mücadele etmek zorunda kaldım.