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


lütfen bunu kapatmayın çünkü subjektif ..... - Gordon Gustafson
Kapatmak için oy kullanmaya başlıyorum. Son derece ilginç olsa da, bu bir tartışma için bir davet olarak neredeyse bir soru değil. Bunu CW olarak işaretlemenin kapanma olasılığını azaltacağını tahmin ediyorum. - Jerry Coffin
Bu soruda yanlış bir şey yok. - Puppy


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:

  1. Bir sınıf, birden fazla şey yaptığında çok büyük; ve
  2. 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



Ek sınıflar oluştururken bir sorun var. Bazı ortamlarda ekstra sınıflar, daha yavaş performansla sonuçlanabilecek daha fazla sorgu anlamına gelen daha fazla tablo anlamına gelir. Web MVC ortamlarında bu en belirgindir. Ayrıca, başka bir sınıf bu "uydu" sınıflarını kullanmıyorsa, uydu sınıflarının aslında orijinal sınıfın ele alması gereken tekil sorumluluğun bir parçası olduğunu ima eder. Daha fazla kod daha az uyum anlamına gelmez. Ayrıca, başka bir geliştiricinin tek bir nesne oluşturmasının ve aşamaları endişe etmeden bir işlevi çağırmasının kolay olması gerektiğini düşünmelisiniz. - Parris
@Parris, veritabanı erişim performansı, OP'nin özel durumunda geçerli olmayan başka bir konudur. Tekil sorumluluğun kapsamı hakkında reductio ad absurdum @David Thornley tarafından cevapta açıklama. Ve geliştirici kolaylığı hakkında, tamamen hizmet tarafından sağlanan kamu arayüzlerine bağlıdır - hem yüksek bir uyum ve hem de kolaylık olabilir. - Humberto
Reductio ad absurdum müdürünü ve kodun evet bölümünün kesinlikle gerekli olduğunu anlıyorum. Bu durumda, bunun bir anlamı olmadığını düşünüyorum. Her şeyden önce, bir OOP perspektifinden bahsetmek gerekirse, bir sınıf bir çeşit gerçek dünya nesnesini taklit etmelidir. ParseXML, MergeXML veya XMLService sınıfı nedir. Ayrıştırma ve birleştirme, sınıflara benzeyen işlev isimleri gibi ses verir. Parse ve Merge, adaptör modelini bir anlamda izleyebilir. Açıklanan yapı zarif görünmüyor: /. Belki de OOP'un sadece paradigmasında en iyi çözüm olduğu söyleniyor. - Parris
@Parris - gerçek dünya olayı OOP dünyasının düşüncesinin erken bir parçasıydı. İyi bir OOP tasarımı, gerçek dünyada hiçbir şeyle kesinlikle hiçbir ilgisi olmayan birçok nesne içerir. Bunlar, bilgi, veri ve cihazları manipüle eden, bazıları gerçek dünyadaki bir şeyi taklit ettiğini söylemek için çok açık bir amaca sahip olabilecek bir program tasarımının öğeleridir. - Warren P
Sanırım hem ben hem de kıdemli devin bir anlaşmaya varılabileceği bir yol buldum. Cevap içsel statik sınıftır. Bu şekilde, hala üç ayrı dersim olabilir ve onları ana sınıfla ilişkilendirebilirim. Gelecekte bu sınıflardan birini yeniden kullanma ihtiyacı varsa, bu çok basit olabilir. Ayrıca, üç sınıf bağımsız olarak test edilebilir. Bütün cevaplarınız için teşekkürler, bu konuyu daha fazla anlamama yardımcı oldu. - Seagull


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



Sağlanan örnek bu prensibi takip ETMEZ. 1 sorumluluk 3'e ayrılmıştır. Fırçalama ve birleştirme, XML dosyasını üreten orijinal sınıfın sorumluluğu olmalıdır. Bunlar basit bir şekilde faydalı operasyonlardır, ancak XML'e yönelik böyle özel bir amaca sahip oldukları için bile bu şekilde sınıflandırılamazlar. OOP'ta bir sınıf programcı olmayan bir tanınabilir olmalıdır. Programcı olmayan bir scrubXML olarak mantıklı değil. en.wikipedia.org/wiki/Object-oriented_programming - Parris


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



Ben bundan bahsetmedim, ama yıkayıcı ve birleşme maruz kalan bir şey değil. - Seagull
İyi nokta Dan. @Safder - bkz. stackoverflow.com/questions/3300051/... İkinizin de nasıl “doğru” olabileceğine dair bir tartışma için. - Sky Sanders
Bu sınıfın 2. sürümünün, sınıfın en üstünde daha fazla işlevsellik eklediğini hayal edin. Scrubber ve Merger, ana sınıfınız bir godclass'a dönüştüğünde, gelecekte bir refactordan kaçınmanıza yardımcı olacak ayrı sınıflar olarak mı yok? Sınıf bölümlemede hevesli iseniz, bu kusuru eleştirmek için kimse biraz ışık tutamaz mı? Çok organize olursun ve ileride çok uzak olduğunu düşünüyorsun. :-) - Warren P


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



ah. Bunu yapmak zorunda olmak acımaz mıydı? Ciddi anlamda. Denetim otoritesi onun fikrini söyleyemez ve onun noktası gerçekten gerçek bir meyve taşıyana kadar düzeltici eylemde bulunamaz mı? Hangi değil. - Warren P