Yöntem adlarında bağlaçların kullanımı neden kötü bir adlandırma kuralıdır? [kapalı]

Ekibimde birkaç yazılım mimarıyla yakın çalışıyoruz. Projelerimizin tüm tasarım kararlarını onaylıyor, bazı kod incelemeleri yapıyorlar vb.

Projelerimiz esas olarak Symfony 2 çerçevesi kullanılarak PHP'de uygulanan arka uç işlevlerinden oluşmaktadır. Sözdizimsel olarak, kod, adlandırma kuralları ve proje yapısı Java'nın nasıl görüneceğiyle neredeyse aynı görünmektedir (Symfony 2 bu yapıyı teşvik eder). Bu durumdan bahsediyorum çünkü Java'ya özgü kurallar da bizim durumumuzda geçerlidir (mümkünse).

Son zamanlarda, çok garip bulduğum bir şey önerdiler: tüm yöntemlerin kendi adlarında bağlaçları olmalıdır getEntityOrNull, setValueOrExceptionvb.

Böyle bir adlandırma kuralı benim için çok yanlış geliyor, ancak özellikle buna meydan okuyan somut argümanlar veya çevrimiçi makaleler / sayfalar bulamıyorum.

Ortaya koyduğum tek şey:

• bu tür bilgiler, yöntemin ek açıklamalarında @returnveya@throws
• yöntem adlarında bağlaçların ("ve", "veya" vb.) kullanılması genellikle Tek Sorumluluk İlkesine tam olarak uyulmadığını gösterir

Bu adlandırma kuralına karşı başka somut argümanlar nelerdir?

Muhtemelen çatışmaları adlandırmaktan dolayı yapıyorlar. getEntityBiri bir istisna atar ve bir döndüren adlı iki yöntem olamaz varsayalım null. Bu nedenle, onları buna göre adlandırmanız gerekir.

Birincisi, sadece belirli bir sınıfın gerçekleştirebileceği bir değişiklik yapmadıkça, aynı yöntemi çağırmanın birçok farklı yoluna sahip olmanın pratiğinden hoşlanmıyorum.

Başka bir deyişle, getValueOrNullsadece çağırıyorsa getValueOrException, istisnayı yakalarsa ve bu durumda geri dönüyorsa null, bu arayan tarafından yapılabilir. Sınıfı, faydalı hiçbir şeye gerçekten katkıda bulunmayan yöntemlerle doldurur. Daha ziyade tercih ediyorum getValueve bunun istisnayı attığını biliyorum. Daha da iyisi, tüm alma yöntemlerinin potansiyel olarak istisnalar attığını ve nullbunun yerine hiçbirinin geri dönmediğini bilmeliyim, böylece davranışlarım projem boyunca tekdüze veya tersine, tümüyle geri dönebilir nullve arayan kişinin bir istisna atması gerektiğini bilir. istendi.

Ancak, bundan sorumlu olmadığınız da doğrudur. Benim tavsiyem onu ​​büyütmek, ama küçük şeyleri terlemeyin. Nihayetinde, bu tür adlandırma sözleşmelerinin sorumluluğu, tavsiyelerinizi alıp almamalarına bakılmaksızın omuzlarına düşer ve bu da onların kıçları olduğu için, alçakgönüllü görüşüme göre hayır demenin ayrıcalığı olduğuna inanıyorum.

Bağlaçların kullanımı genellikle SRP'nin ihlali anlamına gelmekle birlikte, bu durumda sadece fakir bir adamın iki değerden biri nullveya bir "başarı" değeri olabilen cebirsel veri türünün dönüş değerini gösterir .

Tip sistemindeki zayıflıkları telafi etmek için bir tür Macar Notasyonu kullanıyorlar , yani null edilemeyen türlerin eksikliği. Başka bir deyişle, @returnek açıklamanızda işlevin hiçbir zaman geri dönmeyeceğini nullbelirtmenin bir yolu yoktur ve tersine @returnek açıklamanızda işlevin geri dönebileceğini belirtmenin bir yolu yoktur null.

Ayrıca, @throwsphp'de ek açıklamaların zorunlu olmadığına inanıyorum , bu nedenle ek açıklamanın yokluğu bir istisna olmadığını göstermez, ancak stil rehberinizdeki ek açıklamayı zorunlu hale getirerek daha iyi çözülür.

Kullandığınız dilin bu sınırlamaları göz önüne alındığında, bu tamamen mantıksız bir stil değildir.

Benim kod bazen bazen getEntity () ve getEntityOrNull () gibi adlarla yöntem çiftleri oluşturmak. Ad, beklenen davranışı netleştirir. GetEntity () öğesi bir varlık bulamazsa, bir istisna atılır. getEntityOrNull () bir null döndürür.

Bunu yaparak arama kodu biraz daha netleşir. Çağıran kodun bir varlığı varsa, getEntity hile yapar. Varlık bir tür isteğe bağlı şeyse, getEntityOrNull tercih edilen yöntemdir.

Aynı şey tek bir yöntemle de gerçekleştirilebilir, ancak bu yükün bir kısmını çağıran programa kaydırır. Her zaman bir null değeri test etmeniz veya bir try / catch bloğuna ihtiyacınız vardır. Her iki durumda da, yöntem her çağrıldığında çoğaltılması gereken ekstra koddur.

Mimarlarınız bu tür yöntem çiftlerini kullanmıyorsa, evet, sonek ihtiyacını sorgularım.

Gerçekten bir setValueOrException yöntemi görmedim. Bunun için iyi bir ortak kullanım durumu düşünemiyorum.

Mimarlara nedenini sormayı düşünebilirsiniz. Bildiklerim kararlarını açıklamaktan her zaman memnun olurlar. Genellikle büyük (ve bazen dayanılmaz) ayrıntılarda.

İki argümanınız sağlam. Ancak, adlandırma kuralına karar vermekten sorumlu olanlar, kabul etmediğiniz bir şey olduğu için çok kötü hissetmemeye çalışın.

Siz oradayken, bu yöntemler gerçekten doğrudan bir üye değişkeni ayarlamadığı veya almadığı sürece onları "get" ve "set" bölümlerini kullanmamaya ikna etmelisiniz.