Soru Yanlış tasarım desenleri


Dörtlü kanonik Çete listesinde, sıklıkla yanlış kullanılan, yanlış anlaşılan veya aşırı fazla kullanılan (yüksek derecede tartışılan Tekton dışındaki) tasarım kalıpları var mı? Başka bir deyişle, kullanmadan önce iki kez düşünmenizi önereceğiniz bir tasarım deseni var mı? (Ve neden?)


19
2017-10-30 21:05


Menşei


Hiçbirinin kullanımını cesaretlendirmemen gerektiğini düşünmüyorum (eğer duruma uyuyorlarsa). Bu modeller ortak problemleri çözmek için tasarlanmıştır, problemleri çözen kalıpların kullanılmasını cesaretlendirmeden önce, bunları uygulamadan önce bunları uygulayanları bilgilendirmeniz gerekir. - Chris Missal


Cevaplar:


Singleton modeli .. Küresel durum genellikle test yaparken sorunlara yol açar

Tektona bağlı herhangi bir kodun test edilmesi zorlaşır çünkü bu bağımlılık kolayca alay edilmez.


17
2017-10-30 21:37



Sadece eşzamanlılık yaparken veya uygulama durumunu tamamen sıfırlamanız gereken bir uygulamada (oyunlar gibi) test etmek de sorunludur. - Jasper Bekkers
Herkes hep tekil deseninden nefret eder. Bu listenin en iyisi olmadığına şaşırdım. - Omar Kooheji
Sık sık, sadece bir statik sınıf kullanmayı düşünürlerse, singleton kullanmak isteyen insanlara soruyorum. Hayır derlerse, onlara bir singletonun nasıl, pratik olarak, farklı olduğunu soruyorum. Singletonlar küresel erişim değil, anlık kontrol ile ilgili olmalı. - kyoryu
Singleton'ları statik sınıflar üzerinde kullanmanın bir nedeni, sadece bir yığın işleve değil, gerçek bir nesneye sahip olmanız gerektiğidir. Bir singleton nesnesi başka bir sınıftan türetilebilir veya bir arayüz uygulayabilir. En yaygın kullanılan dillerde, statik bir sınıf olamaz. Tabii ki, bu problemleri Singleton ile çözmez ve kullanmadan önce iki kez düşünmelisiniz. FWIW, ben sadece tamamen vatansız olduklarında singletonları kullanıyorum. Elbette, bu nesnelerden birden fazlasını başlatabilirsin, ama hepsi aynı şeyi yaparlar. - Daniel Yankowsky


Fabrika Kalıpları ...

Her beklemeden önce bir projeye paraşütle girdim MyObject sistemde bir eşdeğer vardı MyObjectFactory yeni örnekler oluşturmak için. Soyutlama veya genişletilmiş sınıf kavramları yoktu ... sadece eski ClassX ve ClassXFactory.

Ve hiç kimse bunun nedenini açıklayamazdı ... "Sadece her zaman yapıldığı gibi oldu"


15
2017-10-30 21:16



Bazen bu, kötü kodun test edilmesini kolaylaştırmak için yapılmalıdır. Fabrikalar ile test kodunuz herhangi bir fabrikayı atabilmekte ve kendi fabrikalarıyla değiştirebilmektedir - ancak bunu uzatmak için yapacaksanız, DI'yi neden kullanmayınız? - Bill K
Kesinlikle. Bir fabrikaya statik olarak bağlanma, yeni operatör üzerinden statik olarak bağlantı kurmaktan çok daha iyi değildir (en azından bazı nesne yeniden kullanım olasılığı hariç). - kyoryu


Tek (yukarıda bahsedilen Singleton ve onun suç ortağı, Fabrika) yanında bir GoF olmayacaktı, bir nesnenin doğal özelliklerine uygulandığında ayarlayıcılar ve alıcılar olurdu.

Üye değişkenlere uygulanan setters ve getters, işlevsel olarak public üye değişkenleri ile aynıdır. Belirleyici olmayan bir alıcı daha çok bir kamu final üyesi değişkeni gibidir - ama bu noktada neden sadece bir kamu final üyesi değişkeni kullanmıyorlar, daha fazla zarar vermezler ...

Tek fark, aramayı kesip atabileceğiniz ve geçersiz kılabileceğiniz, ancak insanların nadiren yaptığıdır. Daha çok, programcı programcıların OO programlamasını engellemek için bir koltuk değneği olarak kullanılır (bu, bir anti-paternin gerçek sebebidir).

Setter ve / veya getter ile hala iç üyelerinizin yapısını dış dünyaya maruz bırakıyorsunuz (örneğin, bir int uzunluğunu değiştirmeniz gerektiğine karar verirseniz diğer dersleri tekrar gözden geçirmeniz gerekecektir) ve neredeyse güvenceye alıyorsunuz. Nesnenin içinde olması gereken bazı kodlar bunun yerine dışarıya yerleştirilir.

Düşünebileceğim birkaç istisna vardır:

Nesnelerin yapısını basitleştirmek için kullanılan setler. Bazen bir nesne oluşturmak ve daha sonra diğer değerleri ayarlamak gerekir. Güvenlik için bu değerler değişmez olmalıdır (iki kez çağrı yapamazsınız).

Getters, içerilen nesnelere erişmek için kullanılır. İçerdiği nesneler genellikle kendi bütünlüğünü güvence altına alabildiğinden, onları paylaşmak harikadır. Bu durumda seterler genellikle kötüdür, burnunuzun hemen altında belirli bir duruma sahip bir nesneyi değiştirmek istemezsiniz, kendi bütünlüğünüzü daha da zorlaştırır.

Ekran bileşenleri için kullanılan Java Fasulyeleri: Evet, bu "özellik topları" nı uygulamak için daha iyi bir yol bulamıyor. Yansıma bu bileşen için kullanışlı hale gelir, kalıplar yararlıdır - bu tür bir hacky ama çalışır.

DAO / DTO Bean nesneleri. Dürüst olmak gerekirse, bunlar desenin işe yaramaz bir kullanımı, ama onlar  Desen. Özelliklerin meta-veri ile manipüle edilmesini, kod yerine yansıtıcı olması gerektiğinden çok daha zor hale getirir. Fasulye özellikleri her zaman bir dış kaynağa (veritabanı formatı, veri aktarım formatı, bileşen özellikleri, ...) bağlıdır. Bu yüzden neden her parçayı tanımlamakla uğraşıyoruz?

Düzenleme: Kyoryu'nun yorumundan çalındı, yazıya getirildi çünkü söylediklerimin mükemmel bir özetidir ve yorumlarda kaçırılabilir. Herkes ihtiyaç duymadığından, dil için erişim sağlayıcıları eklemek sadece kötü bir OO tasarım modelini kodlar:

Kısa versiyon -

if (account1.balance > 1000)
{
    account1.balance = account1.balance - 1000;
    account2.balance = account2.balance + 1000;
}; = BAD CODE. 

account2.deposit(account1.withdraw(1000)); = GOOD CODE. 

İkincisi erişim gerektirmez ... - kyoryu (Fatura k ile biraz değiştirdim çünkü onun yorumunda olduğundan biraz daha fazla yer var).

İkincisi ise, bir aktarım yapabileceğiniz her yerde kodu çoğaltmak yerine, testi ve hesaptaki bazı matematikleri hareket ettirir.

Sadece DAHA FAZLASI noktasında, "İYİ KOD" stili ile .withdraw'in çıktısının, başarısı, kaynağı ve hedefi ve günlüğe kaydetme yeteneği de dahil olmak üzere tüm işlem hakkında bilgi içeren bir Transaction nesnesi olabileceği oldukça açık. Bu, kodlarını "KÖTÜ KODU" tarzında yazan bir kişiye nasıl olur?

Ayrıca KÖTÜ KODUNU böyle bir nesneyi bile kullanmak için nasıl yeniden yönlendirirsiniz? Bu sadece bir karmaşa.


9
2017-10-30 22:32



Getters ve setters, diğer birçok patter, dilin bir sınırlamasını düzeltmek için girişimlerde bulunur. Bu durumda, özellikleri. Birçok Java kodlayıcısı, diğer dillerde genel bir değişken gördüğünde korkuyla titreyebilir. Genellikle bunu unutuyorlar saner Eğer mantıksal kümeye mantık eklemeniz ya da o değişkeni elde etmeniz gerekiyorsa, bir çok şey yapmak yerine, aynı isimde bir özellik ile değiştirebilirsiniz. getId() ve setId()  her ihtimale karşı. (VB6'nın bile özellikleri vardı) - Esteban Küber
Aslında, özellikler, alıcılar ve ayarlayıcılar kadar problem. OO'nun fikri, bir nesneyi sizin için bir şey yapmasını istemenizdir. Bir alıcı veya ayarlayıcı buna uygun mu? Getters veya salt okunur özellikleri gerçekten zararlı değildir ve bazen ihtiyaç duyulur (bunlara ihtiyacınız olmadıkça bunları önleyebilirsiniz), ancak ayarlayıcılar / yazılabilir özellikler korkunçtur. Özelliklerle sahip olduğum en büyük sorun, bu kötü davranışları teşvik etmeleri. Birisine kesinlikle ihtiyacınız olduğunda, daha güzel bir sözdizimi vardır, ancak dile yerleşik özellikler sahip olmak, insanları iyi bir fikir olduğunu düşünmeye teşvik eder. - Bill K
Tam olarak Bill K'nin söylediği gibi. Kısa versiyon - if (account.balance> 1000) {account.balance = account.balance - 1000; TransfertoMe (1000)}; = KÖTÜ KODU. account.Withdraw (1000); = İYİ KOD. İkincisi, erişim gerektirmez ... - kyoryu


Aslında en sık gördüğüm şey eksiklik Uygun bir desen kullanımı. Tipik senaryo: ben: "Hey, A modülü zaten bir dizi nesneye iliştiren bir kod parçasına sahip ve bunların üzerinde X veritabanı işlemi yapıyor, bu kodu neden kullanmadın?" kodlayıcı: "iyi, ama bu nesneler üzerinde Y işlemi yapmak zorunda kaldım." me: "X veya Y'yi uygun şekilde yürütmek için Komut şablonunu kullanmak için yeniden kodlamayı kullanmaktan ne haber?"

Bir kez, Özne-Gözlemci modelinin kullanımının elden çıktığını gördüm. Özneyi kalıcı olarak saklamak için veritabanını kullanan süreçler arasında uygulandı. Konuya ilişkin güncellemelerin sayısından ve gözlemcilerin sayısından dolayı, veritabanındaki yük muazzamdı ve öngörülemeyen sistem çapında bir yavaşlamaya neden oldu.


4
2017-10-30 21:21





Ayrıca fabrika modelini de söyleyebilirim. Eoin gibi benzer bir deneyim. Benim durumumda projenin tonlarca fabrikası vardı, çünkü bazı insanlar yerel bir uygulama için A nesnesini ve uzak bir nesne için B nesnesini kullanmış olabileceğinizi düşündü ve bir fabrika aracılığıyla soyutlandı (ki bu mantıklı bir şeydi).

Fakat "uzaktan" uygulamaya hiç bir zaman ihtiyaç duyulmadı ya da uygulanmadı ya da gelecekte bile öngörüde bulunuldu ... ve ayrıca, daha az yetenekli mühendisler, kalıbı kesici bir takım gibi bir çok başka şey için desen kullanmaya başladı ...


4
2017-10-30 21:35



Klasik 'YAGNI' vakası: buna ihtiyacınız olmayacak! - Mitch Wheat


HERŞEY.

Beni yanlış anlamayın, onları harika bir üs olarak buldum ve ne zaman çok iyi anlaşılırsa anladım. Kodu ne zaman ve nasıl uygulayacağınızı iyi bilmek için tasarım becerilerini kazanmanız çok zaman alır. Aslında, temiz kod oluşturma becerileri için genel durum budur.

O zaman kullanmayla ilgili değil, "kullanmadan önce iki kez düşün" sorusunda tam olarak söylediğin şeydir. Ne yaptığını ve nedenini iyi anla. Eğer yapmazsan, o konuda size rehberlik edecek biriyle konuş. Tüm kalıpları bilenlere dikkat edin, ancak bunların herhangi birinin - niçin / nedenini - özellikle de söz konusu olanı - açıkça anlatamam.


3
2017-09-25 04:34



Bana göre, en büyük şey, tasarım modellerinin çoğunlukla 'geleneksel' sözde prosedürel OO'dan farklı bir programlama modelinden baktığınızda faydalı olmasıdır. Tasarım desenleri kullanılarak yazılmış kod, bir Actor modelini kullanarak kod gibi korkunç bir görünüme sahip olmalıdır - ve eğer bir Aktör benzeri model kullanarak kod yazıyorsa, tasarım desenleri son derece pragmatik ve sıklıkla belirgin hale gelir. - kyoryu
+1 AntiPatterns'ın bu yüzden tanıtılmasının nedeni budur. Yanlış bağlamda kullanılan bir Tasarım Kalıbı bir AntiPattern haline gelir, bu da sakıncaların faydalarından daha ağır basması anlamına gelir. - helpermethod


Gördüğüm en büyük şey, tek bir destroyerin nasıl ve ne zaman çağrılacağı konusunda yeterli özen ve dilligence'ın uygulandığı tektonik modeldir.

Böyle bir desen için, bir tek tek ölmesinin ne zaman gerektiğine karar vermek için uygun süreç hakkında bir tartışma yoktur.

Sadece benim 0.02.

şerefe,

soymak


2
2017-10-30 22:57