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

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 tanımlamak için bir anti-patern var mı?

26
Bunun için resmi bir isim bilmiyorum ama bu, tanınmayan bir antipattern olmayı hak ediyor, çünkü aynı şeyi yapan programcıları biliyorum ... anlamsız sarma katmanından sonra katman oluşturuyor. Belki "sarmalayıcı soğan" iyi bir uyum olur mu?
katma yazar Bloodhound, kaynak
Bağlı. Günlük kitaplığı için bir sarıcı mı? Daha önce değiştirilme şansı olsaydı, bu aslında iyi bir uygulama.
katma yazar Peter S Magnusson, kaynak
@Keith - Bıraktı. Kaçan ve kovboyların yaptığı şeyi yapan bir kovboydu. Arada bir koduna baktık, ama o kadar karmaşıktı ki, nereden başlayacağımızı bile bilmiyorduk. Şimdi içeri girip bıraktığı pisliği temizliyorum.
katma yazar Jason Hutchinson, kaynak
"Kötü kodlama" onu kapsar;)
katma yazar Codes with Hammer, kaynak
@lortabac: "Baklava kodu" ile ilgili sorun, aslında iyi ve lezzetli görünmesi ve bu nedenle istenmesi.
katma yazar FrustratedWithFormsDesigner, kaynak
Bunun lehine argümanlar olabilir. Örneğin. "Bob Amca" (Robert Martin) sınırlı sayıda modüldeki bağımlılıkların merkezileştirilmesi lehine, onları kodun içine saçmak yerine.
katma yazar tim, kaynak
Hmm. Siyah beyaz smalltalk'te hilight yönteminin tanımı kendi kendine ters çevir idi. Ancak bu, aynı nesnede anlambilim için yeniden adlandırmadır. my.log => other.log yalnızca bir atıktır.
katma yazar Sean McMillan, kaynak
Bunları eklediğinizde bu programcı neden bu yöntemleri eklediklerini söylüyor? Akıl yürütmelerini anlamak, onları eğitmeyi kolaylaştırmalıdır.
katma yazar user11187, kaynak
Log saf sanal mı? Bir sınıfın özelliklerini, sınıfın özelliklerini çıkarmak için işleci << tarafından bir sınıfın çağrıldığı, ancak hiçbir zaman Class.print() olarak adlandırılmadığını, bunun yerine işleci << içinde çağrıldığını gördüm.
katma yazar kingchris, kaynak
SomeClass.log’un yaptığı şeyin bir parçasını gönderebilir misiniz? Kayıt defterine bir sınıf adı veya durumu gibi bir şey mi geçiyor?
katma yazar gertvdijk, kaynak
SomeClass bir kayıt dekoratörü mü? İşlevselliği bir arayüze mi bağlıyor, yoksa bir miras zinciri için ortak bir uygulama sağlıyor mu? Testi kolaylaştırmak için yararlı bir dikiş sağlıyor mu? Yani doğrudan ErrorLog.Log() 'i çağırmak yerine herhangi bir ek değer sağlıyor mu? Herhangi bir değer katmazsa, o zaman sadece bir refactor için bir hedef. Eğer bir miktar değer sağlarsa, varlığını haklı çıkarmak için yeterince bir değer sağlarsa, bir yargılama çağrısı yapar.
katma yazar Richard Klassen, kaynak
Kendinize iyi gelebilecek bir indirme seviyesine benziyor @Rig in işaret ettiği gibi iki sınıf arasında eşleşmekten kaçınmak istiyorum. Belki de yalnızca patternitis 'den muzdarip bir kodlayıcıydı. Orada olmayan bir sorunu çözmek için desen, KISS ihlal ediyor.
katma yazar davidbak, kaynak
Sanırım TheDailyWTF adresine gelecekteki bir gönderi görüyoruz.
katma yazar ack, kaynak
Belki baklava kodu ?
katma yazar Bill Rosmus, kaynak

12 cevap

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

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


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

54
katma
Her zaman "Dolayection Hell" i kullandım.
katma yazar Eloy, kaynak

Hayır, bu bir anti örüntü değil, 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.

is-a ilişkisinin 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.

27
katma
@ xxcdw: evet. Teşekkürler
katma yazar Mercfh, kaynak
"Tek Sorumluluk sorunu"? SRP? Belki de Tek Sorumluluk Prensibi yazmak istedin? Sadece ikisini burada birleştiriyorum. :)
katma yazar Jamie Thomas, kaynak

Bunun kabul edilebilir kılması değil, ancak bu bitmemiş bir yeniden düzenleme olabilir. Belki de SomeClass.log() 'nin ilk önce uygulanmış bir mantığı vardı. Daha sonra 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 düşünülmesi gereken bir şey.

8
katma

"Lazanya Kodu" tabiri aklıma geliyor, anlaşılan açıkçası farklı insanlar için farklı şeyler ifade ediyor . Benim yorumum daima "katmanlı olma uğruna katmanlı" olmuştur.

7
katma
Aynı şeyi açıklamak için "Soğan Kodunu" da duydum.
katma yazar Dave, kaynak

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.

Açıkça burada kalıtım kullanmak için bir yol var (ya da bir kayıt arayüzü oluşturmak için kayıt tutmaya ihtiyaç duyan sınıflar yapmak).

4
katma
Yine de kötü bir uygulama çünkü: 1) değiştirilmemesi muhtemeldir 2) eğer değişirse, aynı isimde bir sarmalayıcı sınıfı oluşturabilir ve ithalatı değiştirebilirler.
katma yazar miguel.de.icaza, kaynak

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.

3
katma

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üğe kaydetme işlemini yapmak için kullanabilirsiniz; SomeClass kodu ise günlük mesajına nesneye özel 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.

3
katma

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öntem/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. Ardından 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 adlandırdılar. Bu bunun bir problem olduğu yer.

2
katma

Accidental complexity is complexity that arises in computer programs or their development process which is non-essential to the problem to be solved. While essential complexity is inherent and unavoidable, accidental complexity is caused by the approach chosen to solve the problem.

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

2
katma

Cephe Deseni 'nin 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.

1
katma

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 faydalı olmadığı, çok fazla bilgi olmadan aynı fikirde ve fikirde olmayan sizin fikrinizdir.)

Bunun altına girebilecek desenler Proxy , Temsilci , Dekoratör , Kompozit veya bunlarla ilgili olanlardır. çağrıları gizleme, gizleme veya dağıtma. Eksik bir gelişme durumunda bu tür şeylerden biri olabilir.

1
katma

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. İçimdeki Python programcısı hala kötü olduğunu söylüyor, çünkü " Bir tane olmalı ... ve tercihen sadece bir - bunu yapmanın açık bir yolu. ", ancak bazı Perl adamları" Bunu yapmanın birden fazla yolu var ".

0
katma
Belki de bu kod, başlangıçta (ab) artış olarak kullanılan bir prototip anlamına geliyordu. Bu durumda, ilk yazma için optimizasyon geçerli olurdu, bence.
katma yazar Batuta, kaynak
İlk yazma kolaylığı kopyalamanın iyi bir nedeni değildir. Kötü kod ilk kez etrafta yazmak daha kolay olabilir, ancak bu uzun vadede kod yazmayı kolaylaştırmaz. Yeni gelenler çoğaltılmış işlevsellik ile ne yapıyor? Hangi yöntemi çağırıyor? Onları ararken ve okuyarak, sadece aynı şeyleri bulmak için zaman harcıyor.
katma yazar Kazark, kaynak