Bu kodlama yöntemini tanımlayan bir antipattern var mı? [kapalı]

Programcının anlam ifade etmeyen alanlara işleri yerleştirme eğiliminde olduğu bir kod tabanına sahibim. Örneğin, bir Hata günlüğü verildiğinde, size

ErrorLog.Log(ex, "friendly message");

Aynı görevi yerine getirmek için çeşitli yollar ekledi. ÖRNEĞİN

SomeClass.Log(ex, "friendly message");

Hangi basitçe döner ve ilk yöntemi çağırır. Bu, ek bir fayda sağlamadan karmaşıklık seviyeleri ekler. Bunu açıklamak için bir anti-patern var mı?

Eğer makul bir şekilde yaygınsa, bazı kötü kodlama alışkanlıklarına Antipattern denmek faydalı olacaktır.

Geri kalanımız sadece "çöp kodu" diyoruz ...

Bu kötü alışkanlık için bir isim önerirsem, "Obsesif Soyutlama Bozukluğu" olur :-)

Hayır, bu bir anti model değildir, ancak aşağıdaki sorunları dile getireceğim.

Tek Sorumluluk İlkesinin İhlali

SRP, bir sınıfın değişmesi için bir neden olması gerektiğini söyledi. Bir günlüğe kaydetme yöntemi eklemek, sınıfın günlüğe kaydetme mantığının değiştirilmesi gerekip gerekmediğini de değiştirmek zorunda olduğu anlamına gelir.

Bir is-ailişkinin ihlali

Temel sınıflar, çeşitli kolaylık yöntemleri ekleyebileceğiniz araç kutuları değildir.

Bunu etkin bir şekilde yapmak, kalıtsal sınıfları, temel sınıfın sahip olduğu uygulamalarla eşleştirir.

Bunu kompozisyonla karşılaştırın.

Bunun kabul edilebilir kılması değil, ancak bu bitmemiş bir yeniden yapılandırma olabilir. Belki de SomeClass.log () 'nin ilk önce uygulanmış bir mantığı vardı. Ve sonra onlar ErrorLog.Log () kullanmaları gerektiğini anladılar. SomeClass.Log () 'un çağrıldığı 100 yeri değiştirmek yerine, sadece ErrorLog.Log ()' a delege verdiler. Şahsen tüm referansları ErrorLog.Log () olarak değiştirirdim veya en azından SomeClass.log () 'a neden yorum yazdığını söyleyeyim.

Sadece dikkate alınması gereken bir şey.

"Lazanya Kodu" terimi aklıma gelir, ancak görünüşe göre farklı insanlar için farklı şeyler ifade eder . Benim yorumum her zaman "katmanlı olma uğruna katmanlı" olmuştur.

Bunu tek bir sorumluluk ilkesine suç olarak tanımlayacağımdan emin değilim, çünkü ErrorLog yöntem imzasında bir değişiklik olursa (SomeClass tarafından adlandırılan yöntem), bu yöntemi çağıran her müşteri kodu başarısız olacaktır.

Miras kullanmanın (ya da bir kayıt ara yüzünü uygulamak için kayıt tutmaya ihtiyaç duyan sınıflar yapmayı) kullanmanın bir yolu olduğu açıktır.

Ya da buna "öğretilebilir bir an" olarak bakabiliriz :)

Geliştiriciniz iyi bir fikir için yarı yolda olabilir. Tüm iş nesnelerinizin akıllı günlüğe kaydetme yeteneğine sahip olması gerekliliğini varsayalım. Tanımlayabilirsiniz:

   public interface IBusinessObjectLogger
   {
       void Log(Exception ex, string logMessage)
   }

Artık nesnelerinizin iç kısmında, ErrorCog nesnesini, günlüğü yapmak için kullanabilirsiniz; SomeClass kodu ise log mesajına özel bir değer ekler. Daha sonra, iş nesnelerine dokunmadan dosya tabanlı, db tabanlı veya mesaj tabanlı günlükleme işlevselliğini uygulamak için günlük API'lerinizi daha da genişletebilirsiniz.

Bunun otomatik olarak kötülük olduğundan emin değilim.

SomeClass'ı çağırıyorsanız, tabi ki bu kesinlikle kötüdür, ancak Log sadece WITHINClass'in içinden kullanılıyorsa kuplajı keser ve ben de bunu kabul edilebilir olarak adlandırabilirim.

Bu aslında bazı kodlama stillerinde oldukça yaygındır ve düşünce çizgisinin temelleri kendi içinde bir anti-kalıp değildir.

Muhtemelen daha geniş kod temeli bilgisi olmadan zorunlu olarak kodlayan birisinin sonucudur: "Tamam, bu kodun bir hata kaydı yapması gerekiyor, ancak bu işlev kodun birincil amacı değil. Bu nedenle, bunu yapacak bir yönteme / sınıfa ihtiyacım var. benim için". Bu iyi bir düşünce tarzı; fakat, ErrorLog'un var olduğunu bilmeden, SomeClass'ı yarattılar. Daha sonra ErrorLog'u daha sonraki bir noktada buldular ve koydukları yöntemin tüm kullanımlarını değiştirmek yerine, kendi yöntemlerini ErrorLog olarak çağırdılar. Bunun bir problem haline geldiği yer burasıdır.

Kaza sonucu ortaya çıkan karmaşıklık , bilgisayar programlarında ortaya çıkan karmaşıklık veya bunların çözülmesi gereken sorun için gerekli olmayan geliştirme süreçleridir. Temel karmaşıklık doğası gereği ve kaçınılmaz olsa da, kazara karmaşıklık sorunu çözmek için seçilen yaklaşımdan kaynaklanır.

http://en.wikipedia.org/wiki/Accidental_complexity

Cephe Örüntüsünün kötüye kullanılması / yanlış anlaşılması olabilir . Çalıştığım bir kod tabanında benzer şeyler gördüm. Geliştiriciler, OO tasarımının genel ilkelerini anlamadan tasarım kalıpları için delirdiklerinde bir aşamadan geçti.

Cephe düzeninin yanlış kullanılması, uygulama katmanları arasında soyutlama seviyelerinin bulanıklaşmasına neden olur.

Bu programcının yaptığı şey bazı kodları sarmalamaktır, böylece günlük modülüne doğrudan bir bağımlılığı olmaz. Daha spesifik bilgi olmadan, daha spesifik bir desen vermek mümkün değildir. (Bu paketleyicilerin kullanışlı olmadığı, çok fazla bilgi olmadan aynı fikirde ve fikirde olmayan sizin fikrinizdir.)

Bunun altına girebilecek desenler Proxy , Delege , Dekoratör , Kompozit veya bazılarının çağrıları sarma, gizleme veya dağıtma ile ilgili olması. Eksik bir gelişme durumunda bu tür şeylerden biri olabilir.

Bunun kültürel bir fark olduğunu hayal edebiliyorum. Belki de bu özel kod tabanında yinelenen işlevselliğe sahip olmanın iyi bir nedeni vardır. Böyle bir nedenden ötürü yazma kolaylığını görüntüleyebilirim. İçimde Python programcısı hala "çünkü, kötü olduğunu söyleyebilirim . Tercihen bunu yapmak için tek --obvious yolu yoktur bölgesi varış olmalı ve ", ancak bazı Perl adamlar "Aslında alışık olduğumuz olabilir Birden fazla var bunu yapmanın yolu ".