Soru Bir sınıf ne zaman çok büyük veya çok küçük?
Son zamanlarda şirketimde üst düzey bir geliştirici tarafından kodumu inceledim. Tasarımımı çok fazla sınıf kullanmayı eleştirdi. Tepkilerinizi duymakla ilgileniyorum.
Diğer 3 xml dosyasını manipüle ederek bir xml dosyası üreten bir hizmet oluşturmakla görevlendirildim. Bunları adlandıralım aaa.xml, bbb.xml ve ccc.xml. Servis iki aşamada çalışır. Birinci aşamada ovalar aaa.xml karşısında bbb.xml. İkinci aşamada, birinci fazın ürününü birleştirir. ccc.xml nihai bir sonuç üretmek için.
Üç sınıfla bir tasarım seçtim: iki başka sınıf, bir yıkayıcı sınıfı ve birleşme sınıfı kullanan bir XmlService sınıfı. Her iki sınıf da geniş ve farklı mantık özelliklerine sahip olduğundan, ovalama ve sınıfları ayrı tutmayı sürdürdüm.
Benim yaklaşımımın iyi olduğunu düşündüm çünkü sınıflarımı küçük ve uyumlu tutuyordum. Benim yaklaşımım da test sınıfımın büyüklüğünü kontrol etmeye yardımcı oldu.
Üst düzey geliştirici, fırçalama ve birleştirme sınıflarının sadece XmlService sınıfı tarafından kullanılacağını ve bu nedenle de bunun bir parçası olması gerektiğini iddia etti. Bunun XMLService'i uyumlu kılacağını ve ona göre yapışıklığın ne anlama geldiğini hissettiğini hissetti. Ayrıca sınıfları bu şekilde kırmanın, onları gevşek bir yapışma haline getirdiğini düşünüyor.
İroni, bu sınıfları bir arada tutmayı başarmak için kırmaya çalıştım. Ne düşünüyorsun? Kim doğru ya da yanlış? İkimiz de haklı mıyız? Önerileriniz için teşekkür ederim.
18
2017-07-21 20:19
Menşei
Cevaplar:
Eğer takip ederseniz tek sorumluluk ilkesi (ve sorunuzun tonuna dayanarak, bunu takip ettiğinizi düşünüyorum), o zaman cevap açıktır:
- Bir sınıf, birden fazla şey yaptığında çok büyük; ve
- Amacı, amacını yerine getiremediği zaman çok küçüktür.
Bu çok geniş ve gerçekten öznel - dolayısıyla meslektaşınız ile mücadele. Senin yanında tartışabilirsin:
- Ek sınıflar oluştururken kesinlikle sorun yoktur - Sorun değil, derleme ve çalışma zamanıdır.
- mevcut uygulama Hizmet, bu sınıfların ona "ait olduğunu" öne sürebilir, ancak bu değişebilir.
- Her işlevselliği ayrı ayrı test edebilirsiniz.
- Bağımlılık enjeksiyonunu uygulayabilirsiniz.
- Kodun daha küçük ve daha iyi organize edilmiş olmasından dolayı hizmetin iç işleyişini anlamak için bilişsel yükü hafifletirsiniz.
Dahası, patronunuzun yanlış anlaşılmış bir anlayışa sahip olduğunu düşünüyorum. birleşme. Bunu düşünün odak: Programınızın odağı ne kadar dar olursa, uyum da o kadar yüksek olur. Uydu sınıflarınızdaki kod, hizmet sınıfı içinde birleştirilirse, ikincisi daha az odaklanır (daha az uyumlu). Genel olarak daha düşük kohezyona göre daha yüksek kohezyonun tercih edildiği kabul edilir. Onun hakkındaki görüşünü aydınlatmaya çalışın.
13
2017-07-21 20:35
Uyum, bir kod gövdesindeki işlevin ne kadar güçlü bir şekilde ilişkili olduğunun bir ölçüsüdür. Bununla birlikte, eğer birleştirme ve fırçalama, güçlü bir şekilde ilişkili değilse, bunların ikisi de aynı sınıfta dahil olmak üzere, birleşmeyi azaltır.
Tek Sorumluluk İlkesi ayrıca burada bahsetmeye değer. Tek kullanımlık amaç için ovma ve bir diğeri için bir sınıf oluşturma, bu ilkeyi izler.
Yaklaşımın ikisinden de daha iyi olduğunu söyleyebilirim.
8
2017-07-21 20:31
Derslere ne dersin?
ScrubXml ve
MergeXml güzel isimler.
ProcessXML ve
ScrubAndMergeXml değil, ilk çok genel ve ikinci bir birleşme. Sınıfların hiçbiri birinin ya da diğerlerinin içlerine hiç güvenmediği sürece (yani, düşük bağlanma), orada iyi bir tasarıma sahip olursunuz.
İsimler uyumun belirlenmesinde çok faydalıdır. Bir yapışkan modül bir şey yapar ve bu nedenle basit bir özel adı vardır. Birden fazla şey yapan bir modül daha az uyumludur ve daha genel veya daha karmaşık bir isme ihtiyaç duyar.
X yalnızca Y tarafından kullanıldığında X'in Y'ye birleştirilmesiyle ilgili bir sorun, reductio ad absurdam: eğer arama grafiğiniz çevrimsel değilse, tüm işlevlerinizle tek bir sınıfa sarılırsınız.
2
2017-07-21 21:01
GodClass'ın birkaç yıl süren festivale geri dönen biri olarak, şimdi de bu hatadan kaçınmak için çok uğraşırken; tek bir sınıfa sahip 6000'den 10000'e kadar tek hatlı bir ünite, 250'den fazla metot, 200 veri alanı ve 100'den fazla hat üzerinde bazı yöntemler yapma hatası, tek sorumluluk ilkesi, aydınlanmamış süpervizörünüzün tercihlerine karşı savunmaya değer bir şey gibi görünüyor.
Ancak, amiriniz ve eğer 2000 satırlık kodun bir sınıfa mı, yoksa 3'e mi ait olduğu konusunda bir fikir ayrılığınız varsa, o zaman sanırım ikinizin de aklı başında olduğunuzu düşünüyorum. Belki de bir ölçek ve perspektif meselesidir. Bazı nesne yönelimli programlama meraklıları, sınıfın belli bir “Bağımsız Katsayısı” gibi, uyumun nasıl geliştirileceği ve bağışıklığın en aza indirilmesiyle ilgili genel olarak anlaşılmış fikirlerin doğrudan ihlali anlamına gelir.
Birlikte iyi çalışan 3 sınıftan oluşan bir dizi, nesnel olarak, aynı şeyi yapan tek bir sınıftan ziyade, nesne yönelimli bir sistemdir. Bir uygulama, sadece bir sınıf kullanarak bir uygulama yazarsanız, uygulamanın gerçekten nesne odaklı olmadığını iddia edebilir.
2
2017-07-22 02:58
Eğer yıkayıcı ve birleşme ana sınıfın bağlamı dışında anlamlı değilse, özellikle bu ayrışmaya izin vermek için herhangi bir uygulama detayını ortaya çıkarmanız gerekiyorsa, gözden geçiricinize katılıyorum. Yuvalanmış özel sınıfları destekleyen bir dili veya benzer bir dili kullanıyorsanız, uygulama ayrıntılarını ana sınıfın dış tüketicilerine göstermeden mantıksal ayrımı sürdürmek için makul bir alternatif olabilir.
1
2017-07-21 21:15
Bu çok öznel bir alan ve kodlama ve stil kurallarına bağlı olarak farklı olacak ve kodunuzu kimin onaylayacağı.
Bu, eğer tasarımınızın savunmasını sağlamış olsaydı ve kıdemli takım üyeniz hala sınıflarınızı birleştirmek için ısrar ettiyse, o zaman uzlaşmanız gerekir:
Zaten mantığı ayırdınız. Bir hizmet sınıfını yazın ve diğer iyi tasarımlar gibi yöntemleri ayrı tutun ve daha sonra bir tutkal yöntemi yazın. İhtiyaç duyulması halinde, birden fazla sınıfa nasıl kolayca ayrılabileceğini açıklayan her yöntemin üzerine bazı yorumlar ekleyin.
0
2017-07-21 20:26