Sadece tek (genel) bir metoda sahip sınıflar bir problem midir?

Şu anda video izleme görüntülerinde sıkıştırma ve indeksleme yapan bir yazılım projesi üzerinde çalışıyorum. Sıkıştırma, arka plan ve ön plan nesnelerini bölerek, ardından arka planı statik bir görüntü olarak ve ön planı bir hareketli grafik olarak kaydederek çalışır.

Son zamanlarda, proje için tasarladığım bazı dersleri incelemeye başladım.

Sadece tek bir kamu yöntemine sahip birçok sınıf olduğunu fark ettim. Bu sınıflardan bazıları:

• VideoCompressor (türünde compressbir giriş videosu alan ve türünde RawVideobir çıkış videosu döndüren bir yöntemle CompressedVideo).
• VideoSplitter (türünde splitbir giriş videosu alan RawVideove her biri türünde 2 çıkış videosu vektörü döndüren bir yöntemle RawVideo).
• VideoIndexer (türünde indexbir giriş videosu alan ve türünde RawVideobir video dizini döndüren bir yöntemle VideoIndex).

Kendimi gibi arama yapmak için her sınıf başlatmasını bulmak VideoCompressor.compress(...), VideoSplitter.split(...), VideoIndexer.index(...).

Yüzeyde, sınıf adlarının amaçlanan fonksiyonlarını yeterince açıklayıcı olduğunu düşünüyorum ve aslında isimlerdir. Buna bağlı olarak, onların yöntemleri de fiiller.

Bu gerçekten bir sorun mu?

Hayır, bu tam tersi bir problem değil. Modülerliğin ve sınıfın açık sorumluluğunun bir işaretidir. Yalın arabirimin, bu sınıftaki bir kullanıcının bakış açısından anlaşılması kolaydır ve gevşek bağlantıyı teşvik edecektir. Bunun birçok avantajı var ama neredeyse hiçbir sakıncası yok. Keşke daha fazla bileşen bu şekilde tasarlansaydı!

Artık nesne yönelimli değil. Bu sınıflar hiçbir şeyi temsil etmediğinden, sadece işlevler için gemilerdir.

Bu yanlış olduğu anlamına gelmez. İşlevsellik yeterince karmaşıksa veya genelse (yani, argümanlar somut son türler değil, arabirimlerdir), bu işlevi ayrı bir modüle koymak mantıklı olur .

Oradan diline bağlı. Dil serbest fonksiyonlara sahipse, fonksiyonları veren modüller olmalıdır. Neden böyle bir sınıf olmadığını iddia ediyorsun. Dil, örneğin Java gibi ücretsiz fonksiyonlara sahip değilse, o zaman tek ortak yöntemle sınıflar yaratırsınız. Bu sadece nesne yönelimli tasarımın sınırlarını gösterir. Bazen işlevsel, sadece daha iyi bir eşleşmedir.

Tek genel yöntemle bir sınıfa ihtiyaç duyabileceğiniz bir durum vardır, çünkü tek genel yöntemle arayüz uygulamak zorundadır. Gözlemci modeli veya bağımlılık enjeksiyonu için ya da her neyse. Burada yine dile bağlı. Birinci sınıf fonksiyonlara sahip dillerde (C ++ ( std::functionveya template parametresi), C # (delege), Python, Perl, Ruby ( proc), Lisp, Haskell, ...) bu modeller fonksiyon tiplerini kullanır ve sınıflara ihtiyaç duymaz. Java (henüz sürüm 8'de bulunmayacak) fonksiyon tiplerine sahip olmadığı için, tek metotlu arayüzleri ve ilgili metot sınıflarını kullanırsınız.

Tabii ki tek bir büyük fonksiyon yazmayı savunmuyorum. Özel alt yordamları olmalıdır, ancak uygulama dosyasına özel olabilir (C + 'da dosya düzeyinde statik veya adsız ad alanı) veya yalnızca genel işlev içinde başlatılmış özel bir yardımcı sınıfta ( Veri depolamak veya değil ).

Belirli bir yöntemi özel bir sınıfa çıkarmak için nedenler olabilir. Bu nedenlerden biri, Bağımlılık Enjeksiyonuna izin vermektir.

VideoExporterSonunda bir videoyu sıkıştırabilecek bir sınıfınız olduğunu hayal edin . Temiz bir yol bir arayüze sahip olmak olacaktır:

interface IVideoCompressor
{
    Stream compress(Video video);
}

bunun gibi uygulanacak olan:

class MpegVideoCompressor : IVideoCompressor
{
    // ...
}

class FlashVideoCompressor : IVideoCompressor
{
    // ...
}

ve böyle kullanılır:

class VideoExporter
{
    // ...
    void export(Destination destination, IVideoCompressor compressor)
    {
        // ...
        destination = compressor(this.source);
        // ...
    }
    // ...
}

Bir kötü alternatif bir var olacaktır VideoExportersıkıştırma dahil tüm iş, kamu yöntemlerin bol ve bağlantıda bulunduğu. Hızla bir bakım kabusu olur ve diğer video formatlarını desteklemeyi zorlaştırır.

Bu, işlevleri diğer işlevlere argüman olarak iletmek istediğiniz bir işarettir. Dilinizi (Java?) Desteklemiyor sanırım; eğer öyleyse, seçtiğiniz dilde bir eksiklik olduğu için tasarımınızda çok fazla bir başarısızlık olmaz. Bu, her şeyin bir sınıf olması gerektiğinde ısrar eden dillerle ilgili en büyük sorunlardan biri.

Bu hata fonksiyonlarını gerçekten geçemiyorsanız, sadece serbest / statik bir fonksiyon istersiniz.

Partiye geç kaldığımı biliyorum ama her biri bunu belirtmek için kaçırmış görünüyor:

Bu iyi bilinen bir tasarım deseni: Strateji Deseni .

Strateji modeli, bir alt problemi çözmek için birkaç olası strateji olduğunda kullanılır. Genelde, tüm uygulamalar için bir sözleşme uygulayan bir arayüz tanımlar ve sonra sizin için somut bir strateji sağlamak için bir tür Bağımlılık Enjeksiyonu kullanırsınız.

Örneğin, bu durumda interface VideoCompressor, örneğin class H264Compressor implements VideoCompressorve için birkaç alternatif uygulamaya sahip olabilirsiniz class XVidCompressor implements VideoCompressor. OP ile ilgili bir arayüz olduğu açık değildir, olmasa da, orijinal yazarın gerektiğinde strateji modelini uygulamak için kapıyı açık bırakması olabilir. İçinde kendi başına da iyi tasarım.

OP'nin sürekli bir yöntemi çağırmak için sınıfları başlatırken kendini bulması problemi, bağımlılık enjeksiyonunu ve strateji modelini doğru kullanmamakla ilgili bir problemdir. İhtiyacınız olan yerde onu örneklemek yerine, içeren sınıfın strateji nesnesine sahip bir üyesi olmalıdır. Ve bu üyeye, örneğin yapıcıya enjekte edilmelidir.

Birçok durumda, strateji kalıbı sadece (tek bir doStuff(...)yöntemle ) arayüz sınıflarına (gösterdiğiniz gibi) neden olur .

public interface IVideoProcessor
{
   void Split();

   void Compress();

   void Index();
}

Sahip olduğunuz modüler ve bu iyi, ancak bu sorumlulukları IVideoProcessor'da gruplandırmak isteseydiniz, muhtemelen DDD açısından daha mantıklı olurdu.

Öte yandan, bölme, sıkıştırma ve dizine ekleme, herhangi bir şekilde ilişkili değilse, bunları ayrı bileşenler olarak tutmaya devam ediyorum.

Bu bir problem - veriden ziyade tasarımın işlevsel yönünden çalışıyorsunuz. Aslında sahip olduğunuz şey, OO-ifed olan 3 bağımsız fonksiyondur.

Örneğin, bir VideoCompressor sınıfınız var. Neden videoyu sıkıştırmak için tasarlanmış bir sınıfla çalışıyorsunuz - neden bu türdeki her nesnenin içerdiği (video) verilerini sıkıştırmak için üzerinde yöntemleri olan bir Video sınıfınız yok?

OO sistemlerini tasarlarken, uygulayabileceğiniz etkinlikleri temsil eden sınıfları değil, nesneleri temsil eden sınıfları oluşturmak en iyisidir. Eski günlerde sınıflara türler deniyordu - OO, yeni veri türlerini destekleyen bir dili genişletmenin bir yoluydu. OO'yu böyle düşünürseniz, sınıflarınızı tasarlamak için daha iyi bir yol elde edersiniz.

DÜZENLE:

Kendimi biraz daha iyi açıklamaya çalışmama izin verin, concat metoduna sahip bir string sınıf hayal edin. Sınıftan başlatılan her nesnenin string verisini içerdiği böyle bir şey uygulayabilirsiniz.

string mystring("Hello"); 
mystring.concat("World");

ancak OP bunun böyle çalışmasını istiyor:

string mystring();
string result = mystring.concat("Hello", "World");

Şimdi bir sınıfın ilgili işlevler koleksiyonunu tutmak için kullanılabileceği yerler var, ancak bu OO değil, kod tabanınızı daha iyi yönetmenize yardımcı olmak için bir dilin OO özelliklerini kullanmanın kullanışlı bir yolu "OO Tasarım". Bu tür durumlarda nesne tamamen yapaydır, basitçe böyle kullanılır çünkü dil bu tür bir sorunu yönetmek için daha iyi bir şey sunmaz. Örneğin. C # gibi dillerde, bu işlevselliği sağlamak için statik bir sınıf kullanırsınız - sınıf mekanizmasını yeniden kullanır, ancak artık üzerinde yalnızca yöntemleri çağırmak için bir nesneyi başlatmanız gerekmez. Sonunda string.IsNullOrEmpty(mystring), benim için karşılaştırıldığında, zayıf olduğunu düşündüğüm yöntemlerle bitiyorsunuz mystring.isNullOrEmpty().

Bu nedenle, herhangi biri "sınıflarımı nasıl tasarlarım" diye soruyorsa, sınıfın içerdiği işlevleri yerine içerecek verileri düşünmesini öneririm. "Bir sınıf bir yöntem yöntemidir" için giderseniz, o zaman "daha iyi" C "stil kodu yazmalısınız. (C kodunu geliştiriyorsanız bu mutlaka kötü bir şey değildir) ancak size en iyi OO tasarımlı programını vermeyecektir.

ISS (arayüz ayrımı prensibi) hiçbir istemci kullanmaz yöntemlere bağlıdır zorunda gerektiğini söylüyor. Avantajları çok ve açıktır. Yaklaşımınız ISS'ye tamamen saygı duyuyor ve bu iyi.

Ayrıca, ISS'ye saygı gösteren farklı bir yaklaşım, örneğin, her bir yöntem için bir arayüz (veya yüksek uyumu olan yöntemler kümesi) oluşturur ve daha sonra tüm bu arayüzleri uygulayan tek bir sınıfa sahiptir. Bunun daha iyi bir çözüm olup olmadığı senaryoya bağlıdır. Bunun yararı, bağımlılık enjeksiyonunu kullanırken, farklı ortak çalışanlarla (her arayüzde bir tane) bir müşteriniz olabilir ancak sonunda tüm ortak çalışanlar aynı nesne örneğine işaret edecektir.

Bu arada dedin ki

Kendimi her sınıfa yerleştirirken buluyorum

bu sınıflar hizmet gibi görünüyor (ve dolayısıyla vatansız). Onları singleton yapmayı düşündün mü?

Evet, bir sorun var. Fakat ciddi değil. Demek istediğim, kodunuzu bu şekilde yapılandırabilirsiniz ve kötü bir şey olmayacak, korunabilir. Ancak bu tür yapılanmada bazı zayıflıklar var. Örneğin, videonuzun gösterimi (sizin durumunda RawVideo sınıfında gruplandırılmışsa) değişirse, tüm işlem sınıflarınızı güncellemeniz gerekir. Veya çalışma zamanına göre değişkenlik gösteren birden fazla video gösterimi olabileceğini düşünün. O zaman temsili belirli "işlem" sınıfıyla eşleştirmeniz gerekir. Ayrıca tabi ki, yapmak istediğiniz her işlem için bir bağımlılığın etrafında sürüklenmek can sıkıcıdır. ve artık operasyona gerek olmadığına veya yeni bir işleme ihtiyacınız olduğuna karar verdiğiniz her seferde geçen bağımlılık listesini güncellemek için.

Ayrıca bu aslında bir SRP ihlalidir. Bazı insanlar SRP'ye sadece sorumlulukları bölmek için bir rehber gibi davranırlar (ve her bir operasyona ayrı bir sorumluluk uygulayarak bunu çok ileri götürürler), ancak SRP'nin de sorumlulukları gruplama konusunda bir rehber olduğunu unuturlar. SRP'ye göre, aynı nedenden ötürü değişen sorumluluklar birlikte gruplandırılmalıdır, böylece değişiklik olursa mümkün olduğu kadar az sınıf / modül yerelleştirilir. Büyük sınıflara gelince, bu algoritmalar ilişkili olduğu sürece aynı sınıfta birden fazla algoritmaya sahip olmak sorun değildir (yani, o sınıfın dışında bilinmemesi gereken bazı bilgileri paylaşın). Sorun, herhangi bir şekilde ilgili olmayan algoritmaları olan ve farklı sebeplerden dolayı değişen / değişen büyük sınıflardır.