Programlama tasarım desenlerini kavrayamıyorum

16

Son 4 yıldır javascript ile çalışıyorum. Sorun çözme becerilerimden çok eminim ve kod kalitemizin iyileştiğini görebiliyorum. Toplulukla güncel kalmaya çalışıyorum ve şu anda ES2015 ve React.js ile çalışıyorum. Ancak, programlama tasarım modellerini hiç anlayamıyorum gibi hissediyorum. Bununla ilgili kaynakları nerede bulacağımı biliyorum ve bu konuda zaten kitap okudum. Proje yapısı hakkında karar vermek için kıdemli çalışma arkadaşlarıma güveniyorum ancak üzerinde çalışmakta sorun yaşamıyorum.

Kendi başıma bir şey başlatmam gerektiğinde şu iki yolu ararım: React.js gibi büyük bir kütüphane / çerçeve kullanıyorsam, topluluğun yaptıklarını kopyalama eğilimindeyim; Eğer daha küçük bir şeydeysem modül modelini kullanacağım. Bu konuda daha iyi bir anlayışa sahip olduğumda daha iyi kararlar verebileceğimi biliyorum, ama şimdilik tamamen kayboldum.

Bu konuda üstün eğitim almalı mıyım? Bu konuda bir mentora ihtiyacım var mı? Sadece aptal mıyım? Bunu anlamak gerçekten zor mu?

design-patterns javascript

— Abensur
kaynak

6

Bence tasarım dilini kullanma zorunluluğu söz konusu olduğunda bazı diller diğerlerinden daha 'affedicidir'. Güçlü yazılan derlenmiş diller (Java ve C # gibi), JavaScript ve PHP gibi zayıf yazılan komut dosyası dillerinden daha kötü tasarımdan etkilenir. Tabii ki, tasarım desenlerinin her ikisi için de yararlı olmadığını söyleyemeyiz.

— Matthew

3

Proje büyüklüğü de önemli bir rol oynamaktadır.

— Matthew

2

@Matthew nitpick Ben mutlaka Java / C # şiddetle yazılır çağırmak olmaz ...

— Jared Smith

2

@JaredSmith doğru, sık sık güçlü ve statik olarak yazılan arasındaki farkı unuturum.

— Matthew

6

Genel olarak kalıpları alt etmeye ve çalmaya çalışıyorsanız , Dur! Orada hiçbir şey yok! Bir desen, yaygın olarak ortaya çıkan bir soruna popüler bir çözümdür ve biri ona bir isim verdi. Hepsi bu kadar. Bazı özel kalıpları kavramakta zorlanabilirsiniz - Java'da ikili gönderimi taklit etmek için "ziyaretçi" kalıbını nasıl etkin bir şekilde kullanacağımı hatırlamakta zorlanıyorum - Ama "ziyaretçi" yi bağlayan gizli sosu arıyorsanız "veri aktarım nesnesi" deyin, bulamazsınız. Bunlar iki ortak soruna sadece iki popüler çözümdür, biri onlara isim vermiş ve isim sıkışmış.

— Solomon Slow

34

Yazılım Tasarım modelleri, bilinen sorunlara iyi bilinen çözümlerdir. Onları anlamanın yolu, kalıpları öğrenmek, nasıl çalıştıklarını anlamak ve her birini yazılım tasarımınıza uygulamanın ne zaman uygun olduğunu bilmektir.

Yazılım tasarım modellerini öğrenme şekliniz, bunları birer birer incelemek. Bu sürekli bir eğitim sürecidir. Öğrenme ayak izini azaltmak istiyorsanız, doğrudan kullanmakta olduğunuz teknolojilerle ilgili kalıpları inceleyin.

Tasarım kalıpları hakkında bilinmesi gereken bazı önemli noktalar:

Bazı tasarım desenleri mimari niteliktedir. MVC ve MVVM bu tür modellerin örnekleridir. Bu modelleri, sağladıkları organizasyonel ve yapısal faydalara ihtiyaç duyduğunuzda kullanırsınız.
Bazı tasarım kalıpları programlama dillerindeki eksiklikler için geçici çözümlerdir. Daha etkileyici bir programlama dili kullanıyorsanız, bu kalıplara ihtiyacınız olmayacaktır, ancak genellikle bu seçimi yapamazsınız. Çoğunluğu GoF desenleri olan bu kategoride .
Yazılım kalıbını yalnızca kalıbın özel olarak çözmek için tasarlandığı sorunu çözmeye çalışırken kullanın . Yazılım kalıplarını birleştirerek bir uygulama yazıyorsanız, yanlış yapıyorsunuz demektir.
Var olan her bilgi işlem sorunu için mevcut bir yazılım modeli yoktur. Durum böyle olsaydı, programlama sadece bir kalıp eşleştirme alıştırması olurdu.
Bazı desenler aslında anti-desenlerdir. Bu modellerin getirdiği ek karmaşıklık, sağladığı faydalardan ağır basar. Bu desenlerden hangisini önleyeceğinize, desen desen temelinde kendiniz karar vermelisiniz.

— Robert Harvey
kaynak

İyi cevap, ancak çoğu GoF modelinin programlama dillerindeki eksiklikler için geçici bir çözüm olduğu ifadesine katılmıyorum. Çoğu zaman, bazı desenler belirli diller için daha iyi uygulanabilir, evet, çünkü diller belirli sorunlar ve çözümler göz önünde bulundurularak tasarlanma eğilimindedir.

— Polygnome

1

Gof kalıpları 20 yaşında. Bunların çoğu, Java'nın C ++ tabanlı olduğu için Java'nın devralındığı sorunlar olan C ++ ile ilgili sorunları düzeltmek için oluşturuldu.

— Robert Harvey

Bu cevaptaki paradoks "iyi bilinen sorun" kısmıdır. Daha önce hiç yaşamadığınız takdirde, bu "iyi bilinen sorunları" anlamak zor.

— Fuhrmanator

2

Java, C ++ temelli değildir . Javas'ın sözdizimi edilir ilham C ++ tarafından, ama onun kesinlikle buna dayalı değil. her iki dil de oldukça farklı çalışıyor. Java abstact donanım gerçeği, Şablonlar değil, daha ziyade jenerik vb. Üzerinde, kendi başına belleği yönetir

— Polygnome

4

Herkesin öğrenme yaklaşımı biraz farklıdır ve genel yaklaşımınızın ne olduğu hakkında hiçbir fikrim yok, ama kendinizi "aptal" olarak etiketleyerek kendinize bir kötülük yaptığınıza inanıyorum.

Şahsen, birçoğunun "başarılı" yazılım mühendisleri, tasarımcılar vb. Olarak adlandırdıkları gözlemlerimden, hepsinin ortak bir teması vardır: "deneyim". Bunun "üstün eğitiminiz" olduğuna inanıyorum ve amazondan tonlarca kitap satın alıp onlardan okumaktan (kötü bir alışkanlığım) daha hızlı öğreneceksiniz.

Yani, örneğin, komut kalıbı gibi bir GOF kalıbı alın ve dil seçiminize uygulayın. Size ne gibi faydalar sağladığını ve dezavantajlarını anlayın. Tasarım kalıpları hakkındaki çeşitli kitaplar bunu size açıklayacaktır, ancak bu bilgiyi pratik olarak uygulamanın ve ondan öğrenmenin daha iyi olduğunu hissediyorum. Okuma materyallerini indirim yapmayın, bir amacı vardır, ancak BT dünyası bir ders kitabı alıştırması değildir. Bununla birlikte, BT dünyasına ilişkin görüş ve görüşüm ve kısmen, yazılım mühendisliğindeki kariyerime başladığımda kendi mücadelelerini temsil ediyor. Ayrıca, çok deneyimli yazılım geliştiricileriyle bile gördüğüm önemli bir konu, sabırsızlık ve yaptıklarından zevk almayı unutmaktır. Öyleyse öğreniminizle zaman ayırın ve yaptıklarınızdan gerçekten keyif almayı unutmayın, aksi halde neden zaman ayırmaya zahmet ediyorsunuz?

Ayrıca, diğer insanların pratik deneyimlerinden yararlanın. Hem kötü hem de iyi bir çok açık kaynaklı çözüm var ve onlardan öğrenebilirsiniz. Desenleri nasıl uyguladıklarına bakın ve farklı şekilde nasıl başa çıkacağınızı düşünün.

Bu yüzden genel tavsiyem, yaklaşımınızın yanlış olduğunu düşünüyorsanız, değiştirin. Etrafınızdaki insanlara, kavramadığınızı hissettiğiniz materyalleri öğrendiğinizi ve ne yaptıklarına bakın ya da hatta onlara sorduklarını görün.

— Issız Gezegen
kaynak

1

Programlamanın satranç oyunu gibi olduğunu düşünüyorum. Üzerinde bazı yerel yetenekler olabilir, bütün gün oynayabilirsiniz, ancak satranç hakkında bazı kitaplar okumazsanız ilerleme kaydedemezsiniz ve daha da önemlisi oyunun güzelliğini takdir edemezsiniz.

— Adrian Iftode

@AdrianIftode - kabul etti. Bahsettiğim gibi, kitapları, blogları veya herhangi bir okuma materyalini indirim yapmazdım, ancak programlama dilinde / platformda / çerçevede vb. çaba, ama bir sopa sallamak her kitap okudum.

— Issız Gezegen

@AdrianIftode Pekala, tam olarak değil. Kitap okumadan satranç oynamak, oyun hakkında hala çok şey öğrenebilirsiniz. Tek fark, bazı satranç ustalarının deneyimlerine ve düşüncelerine dayanarak olabildiğince hızlı öğrenmemenizdir. Öte yandan, kendinizi belirli şeyleri düşünerek, sadece satranç ustalarından öğrenen ve kendi yararınıza kullanabileceğiniz insanlar tarafından tamamen gözden kaçan bir ya da iki çözüme rastlayabilirsiniz. Sonunda, her iki öğrenmenin bir karışımının en iyi yararı sağladığına inanıyorum. Satrançta ve programlamada.

— cmaster - reinstate monica

1

Kısa cevap, onlara ihtiyacınız olmamasıdır . Onlarsız kod yazabilirsiniz. Matthew yorumlarda söylediği gibi bu özellikle dilin oldukça esnek olduğu ve projelerin daha küçük olduğu JavaScript için geçerlidir. Ancak 4 yıldır program yapıyorsanız, tekrarlayan veya garip hissettiğiniz şeylere rastlamadığınıza inanmakta zorlanıyorum. Tasarım alanlarını yeniden keşfettiğiniz veya eksik olduğunuz alanlar.

Örnek: JavaScript'in etkinlik sistemi genellikle eldeki görev için yetersizdir. Kendinizi hiçbir zaman olayların akışlarını birleştirmek veya dönüştürmek istemiyor musunuz? Yoksa bu olaylar dizisi kendi başlarına birinci sınıf değerler miydi? Arabulucu ve / veya Gözlemci kalıplarına ihtiyacınız vardır. 2 yönlü veri bağlamaya mı ihtiyacınız var? Aynı hikaye.

Gevrek prototip hiyerarşisi yıkıldı mı? Mixin / Trait / Subclass Fabrika desenleri kurtarmaya.

— Jared Smith
kaynak

4

Önemsiz herhangi bir programı herhangi bir tasarım deseni kullanmadan yazmak neredeyse imkansızdır, genellikle çok sayıda yaygın olanı da kullanırsınız. İhtiyacınız olmayan şey, kullandığınız kalıpları adlarıyla tanıyabilmektir. Kod boyunca kullandığınız tüm tasarım desenlerini adlandıramasanız bile, çalışma kodu yazabilirsiniz.

— Servy

@Servy Tasarım kalıpları soyutlamalar, soyutlamalar kesinlikle gerekli değildir. Temel davranışın bir kereye mahsus geçici bir uygulamasını her zaman yazabilirsiniz ... Örneğin Mesela ben, olaylar hakkında kendi verdi mümkün elle tüm ilgili tarafları kadar Tel ve sonra onları gereksinimleri değişim, sadece pub / sub kullanılmasına kıyasla berbat bütün her seferinde değiştirmek için. Alt sınıflar için (israf edildiyse) bir kereye mahsus sınıflarla her olasılıkta manuel olarak kodlamak mümkündür , o kadar iyi değildir.

— Jared Smith

1

Tasarım modelleri çok geniş olabilir. Genellikle daha geniş tasarım kalıpları o kadar açıktır ki, onları tasarım kalıpları olarak bile düşünmüyoruz (özellikle özel dil desteği olduğunda). Döngü bir tasarım modelidir. Fonksiyonlar bir tasarım modelidir. Nesneler bir tasarım modelidir.

— Servy

@ Terim bu şekilde kullanıyorsanız, o zaman katılmıyorum, ama OP'nin özellikle GOFish kalıpları anlamına geldiği izlenimini edindim.

— Jared Smith

1

@JaredSmith Tasarım desenleri soyutlama değildir . Sahip olduğunuz somut problem için bunları tekrar tekrar uygulasanız bile, bunlar hala kalıplardır . Genel bir Observer sınıfı yazmanıza ve bunu Observer desenini kullanmak için kullanmanıza gerek yoktur . Beton yazma Gözlemcilerin ve bunları kaydettirmek ve bildirmek için somut yöntemler hala deseni kullanıyor. zor olan örüntüyü tanımak. Bazen adını bile bilmeden bir desen kullanıyorsunuz,

— Polygnome

1

Öğrenecek çok iyi deneyime sahip bir danışman bulun. Kodunu izlemesini isteyin, bazı kod incelemelerini gönderin ve onunla işbirliği yapmaya çalışın. Kodlama becerilerinizi geliştirmenin en iyi yolu budur.

ekstra:

Beğendiğiniz bazı basit OSS projelerinde ortak çalışın
Aynı sorunu çözmenin iki yolu olduğunda, her zaman daha basit olanı seçin
Her türlü garip hatayı yapmakta özgür olduğunuz yan projelerle ekstra deneyim oluşturun ve tasarım desenini "zor yoldan" (tm) öğreneceksiniz

— Motocarota
kaynak