Fayda sınıfları kötü mü? [kapalı]

Bu konuyu gördüm

Bir "Utilities" sınıfı kötüyse, genel kodumu nereye koymalıyım?

ve neden sınıflar kötüdür diye düşündünüz mü?

Diyelim ki düzinelerce sınıf derinliğinde bir alan modelim var. Örnekleri xml-ify yapabilmem gerekiyor. Ebeveyn üzerinde bir toXml yöntemi yapmalı mıyım? MyDomainXmlUtility.toXml yardımcı sınıfı yapmalı mıyım? Bu, iş ihtiyacının tüm etki alanı modelini kapsadığı bir durumdur - gerçekten bir örnek yöntemi olarak mı ait? Peki ya uygulamanın xml işlevselliğinde bir dizi yardımcı yöntem varsa?

Fayda sınıfları tam olarak kötü değildir, ancak iyi bir nesne yönelimli tasarım oluşturan ilkeleri ihlal edebilirler. İyi bir nesne yönelimli tasarımda, çoğu sınıf tek bir şeyi ve tüm niteliklerini ve işlemlerini temsil etmelidir. Bir şey üzerinde çalışıyorsanız, o yöntem muhtemelen o şeyin bir üyesi olmalıdır.

Ancak, bir dizi yöntemi bir arada gruplamak için yardımcı sınıfları kullanabileceğiniz zamanlar vardır - bir örnek java.util.Collections, herhangi bir Java Koleksiyonunda kullanılabilecek bir dizi yardımcı program sağlayan sınıftır. Bunlar, belirli bir Koleksiyon türüne özgü değildir, bunun yerine herhangi bir Koleksiyonda kullanılabilen algoritmaları uygular.

Gerçekten yapmanız gereken, tasarımınız hakkında düşünmek ve yöntemleri nereye koymanın en mantıklı olduğunu belirlemektir. Genellikle, bir sınıfın içindeki işlemler gibidir. Bununla birlikte, bazen, gerçekten de bir fayda sınıfıdır. Bununla birlikte, bir fayda sınıfı kullandığınızda, içine rastgele yöntemler atmayın, bunun yerine yöntemleri amaca ve işlevselliğe göre düzenleyin.

Bence genel fikir birliği, fayda sınıflarının kendiliğinden kötü olmadığıdır . Sadece onları mantıklı bir şekilde kullanmanız gerekir:

• Statik fayda yöntemlerini genel ve yeniden kullanılabilir olacak şekilde tasarlayın. Vatansız olduklarından emin olun; yani statik değişken yok.

• Çok sayıda yardımcı yönteminiz varsa, geliştiricilerin bulmasını kolaylaştıracak şekilde bunları sınıflara ayırın.

• Bir etki alanı sınıfındaki statik veya örnek yöntemlerin daha iyi bir çözüm olacağı yardımcı program sınıflarını kullanmayın. Örneğin, soyut bir temel sınıftaki veya başlatılabilir bir yardımcı sınıftaki yöntemlerin daha iyi bir çözüm olup olmayacağını düşünün.

• Java 8'den itibaren, bir arayüzdeki "varsayılan yöntemler", yardımcı program sınıflarından daha iyi bir seçenek olabilir. ( Örneğin , Java 8'deki Abstract sınıfına karşı varsayılan yöntemlerle arabirim bölümüne bakın .)

Bu Soruya bakmanın diğer yolu, alıntılanan Soru'da "Fayda sınıfları" kötü "ise" saman adam argümanı " olduğunu gözlemlemektir. Benim sorduğum gibi:

"Domuzlar uçabiliyorsa şemsiye taşımalı mıyım?"

Yukarıdaki soruda aslında domuzlar uçabilir söylemiyorum ... yoksa o anlayışını kabul olduğunu olabilir uçarlar.

Tipik "xyz kötüdür" ifadeleri, aşırı bir bakış açısı sunarak sizi düşündürmeyi amaçlayan retorik araçlardır. Nadiren (varsa) gerçek gerçeklerin beyanları olarak tasarlanırlar.

Hizmet sınıfları sorunludur çünkü sorumlulukları kendilerini destekleyen verilerle gruplandırmada başarısız olurlar.

Bununla birlikte, son derece kullanışlıdırlar ve onları her zaman kalıcı yapılar olarak veya daha kapsamlı bir yeniden düzenleme sırasında basamak taşları olarak inşa ediyorum.

Bir itibaren Temiz Kod perspektifinden yarar sınıfları Tek Sorumluluk ve Açık-Kapalı prensibi ihlal. Değiştirmek için pek çok nedenleri vardır ve tasarım gereği genişletilemezler. Gerçekten yalnızca yeniden düzenleme sırasında orta düzeyde bir hamle olarak var olmalıdırlar.

Sanırım kötü olmaya başladığında

1) Çok büyüyor (bu durumda onları anlamlı kategorilere ayırmanız yeterli).
2) Statik olmaması gereken yöntemler mevcut

Ama bu şartlar sağlanmadığı sürece çok faydalı olduklarını düşünüyorum.

Başparmak kuralı

Bu soruna iki açıdan bakabilirsiniz:

• Genel *Utilyöntemler genellikle kötü kod tasarımının veya tembel adlandırma kurallarının bir önerisidir.
• Yeniden kullanılabilir alanlar arası durum bilgisi içermeyen işlevler için yasal bir tasarım çözümüdür. Lütfen hemen hemen tüm yaygın sorunlar için mevcut çözümler olduğunu unutmayın.

Örnek 1. utilSınıfların / modüllerin doğru kullanımı . Harici kitaplık örneği

Kredileri ve kredi kartlarını yöneten bir uygulama yazdığınızı varsayalım. Bu modüllerden gelen veriler, web servisleri aracılığıyla jsonformatta sunulur. Teoride, nesneleri manuel olarak dizelere dönüştürebilirsiniz json, ancak bu tekerleği yeniden icat eder. Doğru çözüm, java nesnelerini istenen formata dönüştürmek için kullanılan her iki modüle de harici kitaplığı dahil etmek olacaktır. (örnek resimde gson'u gösterdim )

Örnek 2. utilSınıfların / modüllerin doğru kullanımı . utilDiğer ekip üyelerine bahane olmadan kendi yazınızı yazmak

Bir kullanım örneği olarak, iki uygulama modülünde bazı hesaplamalar yapmamız gerektiğini varsayalım, ancak her ikisinin de Polonya'da resmi tatiller olduğunda bilmesi gerekir. Teorik olarak bu hesaplamaları modüller içinde yapabilirsiniz, ancak bu işlevi ayrı modüle çıkarmak daha iyi olacaktır.

İşte küçük ama önemli detay. Yazdığınız sınıf / modül çağrılmaz HolidayUtilama PolishHolidayCalculator. İşlevsel olarak bir utilsınıftır, ancak genel kelimeden kaçınmayı başardık.

Yardımcı sınıflar kötüdür çünkü sınıf için daha iyi bir isim bulamayacak kadar tembel olduğunuzu gösterir :)

Olduğu söyleniyor, ben tembelim. Bazen sadece işi halletmeniz gerekir ve zihniniz boştur .. İşte o zaman "Fayda" dersleri içeri girmeye başlar.

Şimdi bu soruya dönüp baktığımda, C # genişletme yöntemlerinin, yardımcı sınıflara olan ihtiyacı tamamen ortadan kaldırdığını söyleyebilirim. Ancak tüm dillerin böyle dahice bir yapısı yoktur.

Ayrıca, mevcut nesneye doğrudan yeni bir işlev ekleyebileceğiniz JavaScript'e de sahipsiniz.

Ama bu sorunu C ++ gibi eski bir dilde çözmenin gerçekten zarif bir yolu olduğundan emin değilim ...

İyi OO kodunu yazmak biraz zordur ve bulmak zordur, çünkü İyi OO yazmak, düzgün işlevsel kod yazmaktan çok daha fazla zaman / bilgi gerektirir.

Ve bütçeniz kısıtlı olduğunda, patronunuz bütün günü bir sürü dersle geçirdiğinizi görmekten her zaman mutlu olmaz ...

Fayda sınıflarının kötü olduğuna tamamen katılmıyorum.

Bir fayda sınıfı, OO ilkelerini bazı şekillerde ihlal etse de, her zaman kötü değildir.

Örneğin, değerle eşleşen tüm alt dizelerden oluşan bir dizeyi temizleyecek bir işlev istediğinizi düşünün x.

stl c ++ (şu an itibariyle) bunu doğrudan desteklemiyor.

İçin polimorfik bir uzantı oluşturabilirsiniz std::string.

Ama sorun şu ki, projenizde kullandığınız HER dizenin sizin genişletilmiş dizge sınıfınız olmasını gerçekten istiyor musunuz?

OO'nun gerçekten mantıklı olmadığı zamanlar vardır ve bu onlardan biridir. Programımızın diğer programlarla uyumlu olmasını istiyoruz, bu yüzden bağlı kalacağız std::stringve bir sınıf StringUtil_(veya başka bir şey) oluşturacağız.

Sınıf başına bir kullanımda kalmanızın en iyisi olduğunu söyleyebilirim. Tüm sınıflar için tek bir kullanımın veya bir sınıf için birçok programın olması aptalca olduğunu söyleyebilirim.

Tasarımcı, kodu yerleştirmek için uygun bir yer düşünemediği için bir şeyi bir yardımcı program olarak markalamak çok kolaydır. Genellikle birkaç gerçek "yardımcı program" vardır.

Genel bir kural olarak, kodu genellikle ilk kullanıldığı pakette tutarım ve daha sonra yalnızca daha genel bir yere yeniden düzenleme yaparım eğer daha sonra gerçekten başka bir yerde gerekli olduğunu anlarsam. Tek istisna, benzer / ilgili işlevselliği gerçekleştiren bir paketim olması ve kodun oraya en iyi şekilde uymasıdır.

Durumsuz statik yöntemler içeren yardımcı sınıflar yararlı olabilir. Bunların birim testi genellikle çok kolaydır.

Java 8 ile arayüzlerde statik yöntemler kullanabilirsiniz ... problem çözüldü.

Util sınıflarının çoğu kötüdür çünkü:

1. Yöntemlerin kapsamını genişletirler. Aksi takdirde özel olacak olan kodu herkese açık hale getiriyorlar. Eğer yararlan yöntemi, farklı sınıflardaki birden çok arayan tarafından gerekliyse ve kararlıysa (yani güncellenmesi gerekmiyorsa), özel yardımcı yöntemleri kopyalayıp çağıran sınıfa yapıştırmak benim görüşüme göre daha iyidir. Bir API olarak ortaya çıkardığınızda, bir jar bileşenine genel giriş noktasının ne olduğunu anlamayı zorlaştırırsınız (yöntem başına bir ebeveyn ile hiyerarşi adı verilen bir ağaç yapısına sahip olursunuz. Bu, bileşenlere zihinsel olarak ayrılmak daha kolaydır, birden çok ana yöntemden çağrılan yöntemleriniz var).
2. Ölü kodla sonuçlanırlar. Zamanla, uygulamanız geliştikçe Util yöntemleri kullanılmaz hale gelir ve sonuçta kod tabanınızı kirleten kullanılmayan kodlar ortaya çıkar. Özel kalsaydı, derleyiciniz size yöntemin kullanılmadığını söylerdi ve onu kaldırabilirdiniz (en iyi kod hiç kod olmamasıdır). Böyle bir yöntemi özel olmayan bir yöntem haline getirdiğinizde, bilgisayarınız kullanılmayan kodu kaldırmanıza yardımcı olmak için güçsüz kalacaktır. Tüm bilgisayarın bildiği için farklı bir jar dosyasından çağrılabilir.

Statik ve dinamik kitaplıklar arasında bazı benzerlikler vardır.

Bir sınıfa bir yöntem ekleyemediğimde (örneğin, AccountJr. Geliştiriciler tarafından yapılan değişikliklere karşı kilitlendiğinde), Utilities sınıfıma şu şekilde birkaç statik yöntem ekliyorum:

public static int method01_Account(Object o, String... args) {
    Account acc = (Account)o;
    ...
    return acc.getInt();
}  

Fayda sınıfları her zaman kötü değildir. Ancak yalnızca geniş bir işlevsellik yelpazesinde ortak olan yöntemleri içermelidirler. Yalnızca sınırlı sayıda sınıf arasında kullanılabilen yöntemler varsa, ortak bir ebeveyn olarak soyut bir sınıf oluşturmayı düşünün ve içine yöntemleri koyun.