Programlamada tasarım kalıpları ne kadar önemlidir?

Ben bir üniversite öğrencisiyim ve tasarım kalıplarını öğrenmeye başladım ve amaçlarını anlamak için uğraşıyorum. Onları araştırmayı denedim, ancak bulduğum tüm kaynaklar onlar hakkında profesyonel değil akademik olarak konuşuyor gibi görünüyor.

Amaçları nedir ve öğrenmeleri önemlidir mi?

Tasarım modelleri niyetinizi çok hızlı bir şekilde iletmek için mükemmeldir - herkes bir fabrikanın ne olduğunu bilir.

Gerçekten, gerçekten, gerçekten kötü bir şey, kodunuzu kalıplara uydurmaya veya kalıplara göre sorumlulukları ya da bunun gibi bir şeyi yapmaya çalışmaktır. Bu "Bu nesne söylemek bir şey olduğunu bir Fabrikası" ve başka "Bu nesne münhasıran bir fabrika olmalı" demek.

Tasarım Desenleri hakkındaki wikipedia makalesinden :

Kalıplardan konuşmanın faydası, tasarımcıların zaten gördükleri durumları tartışmak için ortak bir terminolojiye sahip olmaktır.

Çok uzun bir süredir yazılım mühendisliğinde ciddi bir sorun yaşadık: bir projeye yeni gelen bir işe alınıyorsunuz ve programlama dilini ne kadar iyi biliyorlarsa yapsın, işlerinizde nasıl yapıldığına dair güncel bilgilere sahip olmak aylar alıyor üretken olmadan önce projelendirin. Donanım mühendisliğinde bu sorunu çok uzun zaman önce çözdüler: 'şematik diyagramlar' adı verilen ortak bir terminolojileri var. Bir donanım mühendisi kiralarsınız, sabahları donanım projenizin şemalarını verir, onları incelemelerine izin verirsiniz ve akşam saatlerinde, lehim tabancasını alıp üretken hale gelebilecekleri bir gün deme zamanı. Bu konuda daha iyi olmanın yollarını bulmaya çalışıyoruz; programlama dillerinin standardizasyonu bir yoluydu; standart kütüphaneler (günümüzde sınıf kütüphaneleri) başka bir yol olmuştur; ancak en önemli yollardan biri belki de tasarım kalıpları olmuştur. Peki, onlar önemli mi? Emin ol!

Paternlerin varlığının iki farklı, önemli nedeni vardır.

Birincisi zaten oldukça iyi açıklanmıştır: desen kullanımı geliştiriciler arasındaki iletişimi yağlar. Siz ve ben, 'Gözlemci' dediğimde kodun çok spesifik bir yapısından bahsettiğimi anlarsanız, o kalıbı kullanan biraz kodun nasıl çalıştığını çok hızlı bir şekilde açıklayabilirim. Alternatif, zaman alıcı ve hataya açık olan çözümü tam olarak tanımlamaktır. ("Peki, tüketici nesnelerini tanımlayan ve arabirimlendiren bu saf sanal sınıfı yarattım ve sonra aktif tüketicilerin listesini tutan bir sınıf yarattım ...")

Kalıpların ikinci yararı, yaygın problem formları için hazır çözüm formları olmalarıdır. Eğer kalıplarınızı biliyorsanız ve örneğin, sınıflar arasında gereksiz bağlantı kurmaya gerek kalmadan (muhtemelen birden fazla) üretici nesneden birden fazla tüketici nesnesine bilgi almanın iyi bir yolunu bulmanız gereken bir sorunla karşılaşırsanız, bir Gözlemci işi! " ve derhal probleminizi nasıl çözeceğinizi bileceksiniz.

Bu faydalar da gerçekten birbirini güçlendiriyor. Belirli ortak sınıf sınıflarını hızlı bir şekilde çözmenize izin verir ve işiniz bittiğinde, sorunu nasıl çözdüğünüzü çok hızlı bir şekilde iletebilirsiniz.

Bunu, kalıpların "var olmadığı" bir dünya ile karşılaştırın. Genellikle önemsiz tasarım sorunları olmayan bu sorun sınıflarından birine rastlarsınız ve iyi bir çözüm bulmak için oldukça fazla zaman harcarsınız (bu da büyük olasılıkla uygun desene çok benzeyecektir). Sonra, iş arkadaşınız ortaya çıkar ve bunu nasıl çözdüğünüzü bilmek ister ve nasıl ve nedenini tartışmak için bir saat geçirirsiniz.

Tüm bunlar oldukça açık görünmesi gereken bir uyarı ile ilişkilidir: sorunları uymayan kalıplara zorlamaya çalışmayın. Desen soruna uymazsa, çözüm kıvrımlı hale gelir ve desenlerin çaba azaltma faydasını kaybedersiniz. Ayrıca, çalışmanız artık iş arkadaşlarınızın modelin anlamını anlamasına uymayacağından, iletişim avantajının maliyetini kaybedeceksiniz. Aslında, iletişim maliyetini modelsiz maliyetin ötesinde artıracaksınız, çünkü modelin yanlış kullanımı iş arkadaşlarınıza çözümü yanlış bir şekilde anlayacaktır, ki bu hiç bir anlayıştan daha kötü değildir.

Kalıplar fikirlerin ve kavramların yeniden kullanımı ve bunların iletişim için ortak / tutarlı bir platform oluşturulması ile ilgilidir.

Teoride kodun yeniden kullanılmasının iyi bir şey olduğu konusunda hepimiz anlaştık (!) - ancak pratik olarak yapmak istediğimizden daha zor olduğu ortaya çıkıyor (bazı açılardan bu değişiyor, ancak her zaman bir meydan okuma olacak ). Ancak gerçekte, yeniden kullanmak istediğimiz şeylerin çoğu, bir şeyler yapmanın, belirli bir soruna çözüm oluşturmak için bir çeşit şablon kullanmanın bir yoludur - bunlar Desenlerdir. Böylece, X problemini çözmek için iyi bir yaklaşımın Y Deseni kullanmak olduğunu ve Y deseninin elemanlarının a, b ve c olduğunu bildiğimizi söylediğiniz bir duruma gidersiniz. Kalıplar geniş ölçüde anlaşıldığı için iletişimin faydası olan derinlemesine açıklama yapmak zorunda değilsiniz.

Desenlerle ilgili eğlenceli olan şey, diller ve çerçevelerin, daha fazla ve daha iyi kod yeniden kullanımı (daha fazla ve daha iyi lego tuğlaları) elde ettiğimiz net etki ile ortak desenler için daha iyi destek sağlamak için evrimleşmesidir. ) yeniden kullanımı kolaylaştırır.

Tasarım desenleri, herhangi bir yazılım çözümünün üzerine inşa edildiği sadece bilinen tuğlalardır. Aşağıdaki nedenlerden dolayı önemlidirler:

1. Onlar dil bilincidir. Belirli bir problem / mimari / görev için hangi tasarım deseninin uygun olduğunu öğrendikten sonra, herhangi bir çok paradigma dilinde uygulayabilirsiniz - C #, Java veya Python olsun - çözüm çoğu durumda aynı olacak, sadece sözdizimini uyarlamak. Bu, aynı sorun etki alanında kaldığınız sürece (ve hatta belki de alanlar arasında) deneyiminizi bir dilde programlamadan diğer dillere aktarabileceğiniz anlamına gelir.

2. Tasarım örüntülerinin programlama paradigmasına bağlanması gerçeğine rağmen , yani nesne yönelimli programlama için tasarım örüntüleri (en ünlü olanlar, "Dörtlü Çete" örüntüsü olarak da bilinir ). Desenler, paradigmanın en iyi ne olduğunu anlamanıza ve sadece sözdiziminin ötesine geçmenize yardımcı olur.Örneğin, insanların Basic veya Fortran'da yaptıkları şekilde programladıkları C # ve Java'da birçok uygulama gördüm - problemleri çözmek için mükemmel bir zorunluluk var ve sadece bu çözümü oluşturmak için OOP kullanıyorlar - kalıtım yok , polimorfizm yok, tüm yöntemler herkese açıktır. Tasarım modelleri bu kavramların arkasına bakmanıza ve gerçek hayatta nasıl çalıştıklarını görmenize yardımcı olur. Aynı şey fonksiyonel programlama gibi diğer paradigmalardaki tasarım deseni için de geçerlidir.

3. Desenler genellikle fikirleri temsil etmenin kullanışlı bir yoludur ve mimarlıktan Bilgisayar Bilimi'ne geldi. Belli bir "örüntü" nin arkasındaki fikri anladıktan sonra, bu örüntüyü başka bir problemde kolayca tanıyabilir ve bu örüntüyü kullanarak çözebilirsiniz (muhtemelen probleminizi daha iyi ele almak için biraz değiştirilmiş). Tonlarca farklı desen vardır: Kurumsal Yazılım Entegrasyonu'nda , Kaynak Kodu Testinde vb. Bilgisayar Bilimi kitaplarında desen arayın.

4. Desen öğrenerek iyi uygulamalar edinmenin yanı sıra, anti-desenleri inceleyerek kodunuzdaki aptalca hatalardan nasıl kaçınacağınızı kolayca öğrenebilirsiniz . Çok eğlenceli ve aynı zamanda eğitici olan anti-desen şeklinde farklı alanlarda ortak hatalar içeren birçok kitap var. Bu arada, bu anti-desenlerin adlarını seviyorum!

Bir deseni, sizin ve diğer geliştiricilerin anladığı bir sorunu çözmenin kanıtlanmış bir yolu olarak düşünebilirsiniz. Örneğin, sorun sıralı bir veri listesi oluşturmaktır, daha sonra bağlantılı bir liste kullanmayı veya verileri bir vektör ve sıralamaya yerleştirmeyi seçebilirsiniz. Bağlı seçenek desenini veya yük ve sıralama vektör desenini zaten biliyor olabileceğiniz için muhtemelen bu iki seçeneği de anlarsınız. Her birinin artılarını ve eksilerini biliyor olabilir ve neler olduğunu anlamak için uygulamayı görmeniz gerekmez.

Programlama için bir başlangıç ​​olduğunuzu düşünüyorum, tasarım desenini erken öğrenmenizi önermiyorum. Tasarım modelinin öğrenilmesi ve anlaşılması, yazılım geliştirme deneyimine dayandırılmalıdır. Kodlama konusunda daha fazla pratik yapmanız ve hangi kod stilinin kötü olduğunu bulmanız ve ardından tasarımı geliştirmek için tasarım desenini öğrenmeniz gerekir.

Bir tasarım deseninin kullanışlılığı, hangi dili seçtiğinize bağlıdır. Ne kadar güçlü bir dil seçerseniz tasarım kalıplarını daha az anlamanız ve uygulamanız gerekir. Tasarım deseni, dilinizin emdiği yerleşik bir özelliğin eksik olduğunu gösteren bir sinyal olabilir .

Joe Gregorio , Python'daki tasarım desenlerinin eksikliği hakkında harika bir konuşma yaptı

Tasarım modelleri, yazılım geliştirmede karşılaşılan genel sorunlara çözümlerdir. Bazı sorunlara her zaman birden fazla çözüm vardır ve tasarım modelleri, bu yaygın sorunlara bir dizi iyi çözüm sunarak hangi çözümün en iyi olduğuna karar vermenize yardımcı olur.