Tasarım Desenleri Yaratıcılığı Boğuyor

Yıllar önce, bir ekonomi profesörü ile tasarım kalıpları, programcılar için ortak bir dil nasıl oluşturdukları ve iyi bilinen sorunları nasıl iyi bir şekilde çözdükleri vs. hakkında konuşuyordum.

Sonra da bana bunun İktisat öğrencileri için kullanacağı tam tersi bir yaklaşım olduğunu söyledi. Genelde bir problem sundu ve onlardan önce bir çözüm bulmalarını istedi, böylece önce bunu düşünebildiler ve önce sorunu çözmenin yollarını bulmaya çalıştılar, ancak ondan sonra “klasik” çözümü sundu.

Bu yüzden "tasarım deseni" yaklaşımının programcıları daha akıllı ya da alçakça yapan bir şey olup olmadığını düşünüyordum, çünkü çoğu zaman bir problemi çözmek için yaratıcılık ve hayal gücü kullanmak yerine "bu sorun için doğru çözümü" alıyorlardı. yeni ve yenilikçi yol.

Ne düşünüyorsun?

Ekonomi profesörünüz kesinlikle doğru.

Yazılım Tasarım Kalıpları öncelikle deneyimli yazılım geliştiricilerin birbirleriyle iletişim kurmasının bir yoludur . Bilinen sorunlara yerleşik çözümler için bir kestirme yoldur.

Ancak, sorunu yalnızca model olmadan nasıl çözeceğini anlayan veya kendi başlarına benzer bir düzen bulmuş kişiler tarafından kullanılmalıdır. Aksi takdirde, kopyala / yapıştır kodlayıcısıyla aynı sorunu yaşarlar; kodları olacak, ancak nasıl çalıştığını anlamayacaklar ve bu yüzden de sorunu çözemeyecekler.

Ayrıca, tasarım desen çoktur kurumsal desenleri, kullanılmak üzere tasarlanmıştır desenler büyük, kurumsal yazılım sistemleri. Eğer Inversion of Control kabı harikalarını öğrenirseniz, çoğu program gerçekten ihtiyaç duymasa da, yazdığınız her programda kullanmak isteyeceksiniz (bağımlılıklarınızı daha küçük programlara enjekte etmenin daha iyi yolları var, bu bir IoC kabı gerektirmez).

Kalıpları öğrenin. Kalıpları ve uygun kullanımlarını anlayın. Aynı problemi model olmadan nasıl çözeceğinizi bilin (tüm yazılım desenleri temel algoritmalar üzerinden yapılan soyutlamalardır). O zaman, mantıklı bir şekilde, yazılım kalıplarını güvenle kullanabileceksiniz.

Tasarım Desenlerinin insanların Tasarım Desenlerine bakmanızı isteme şekli, benzer sorunlar ortaya çıkarsa uygulayabileceğiniz bir dizi çözümdür. Onları, dağda taş tabletlere oyulmuş Musa'ya verilen tek olası çözümler olarak düşünmenizi istemiyorlar.

Ne yazık ki, bazı insanlar bunları, öğrenilebilecek örnek tasarımlardan ziyade, kutsal yazılıma daha yakın bir şey olarak kabul ediyorlar. Bu yaratıcılığı öldürür ve bir kargo kültü kurar.

İktisat profesörünüz öğrencilere problemi sunmaktan ve ilk önce onları çözmeyi denemelerini sağlamaktan bahsetti, bu iyi bir eğitim tekniğidir, ancak onlara göstermek için bir çözümü vardı. Kafanızdaki birçok farklı soruna bir sürü çözüm bulmak iyi bir şey ve bu da Tasarım Desenlerinin olmaya çalıştığı bir şey. Bazı yönlerden başarısız olduğunu düşünüyorum (Singleton kötü yaklaşımları teşvik ediyor, zorunlu OO'ya yönelik miyop bir odaklanma, vb.), Ancak zeka ve zevkle iyi kullanılabilir. Ancak, yazılımdaki her olası örnek çözümün Resmi Bir Tasarım Deseni Olması gerektiğini düşünmek bir hatadır.

Bir soruna bakarsanız ve kendinize "Bunun için Tasarım Deseni Nedir?" Diye sorarsanız, o zaman yanlış yapıyorsunuz ve yüzünüze bakan bir çözüm görme olasılığınız azalır.

Bir soruna bakarsanız ve kendinize "Bunu nasıl çözebilirim?"

Ayrıca ekonomi profesörünüzün doğru olduğunu düşünüyorum ve bu her şeyden önce bir şeyler öğrenmenin bir yoludur; Ancak şuna şöyle bakalım: Tekerleği gizli tutar ve Yaratıcılık uğruna herkesin yeniden icat etmesine izin verir misiniz? Hayır demenizi bekliyorum, çünkü bütün insanlar tekerleklerini icat edemez / üretemezler - ve eğer öyle yaparlarsa, bir noktada yapacaklar, jantın varlığının farkında olup olmadıkları önemli değil. değil.

Programcılara geri dönelim; Ben gün geçtikçe web geliştiricisiyim, bu yüzden MVC günlük olarak etkileşime girdiğim şeylerden biri. Birkaç kez kendi yapılarımı kurmaya çalıştım, çok şey öğrendim ancak hepsi temelde başarısız oldu. Elimden gelenin en iyisini yaptım ama orada MVC olmasaydı ne olurdu? Eh, basit, kaynak kodum berbat - güvenilirlik, bakım ve genişletilebilirlik açısından.

Bence bu çoğumuz için aynı. Hiç kimse size DI hakkında bir şey söylemezse - iyi bir uygulama olarak, geliştiricileri dersi öğreninceye kadar kaç kurumsal uygulamanın mücadele etmesi veya başarısız olması gerekir?

İkinci nokta Endüstri Standartları . MVC'yi web geliştiricilere öğretmeyecekseniz, o zaman ilk olarak işlerini yapma yollarını öğrenmek için zaman harcamanız gereken standart olmayan yapıların tümüyle yüzleşmeye hazırsınız, ve sonra bu yapıların bazılarının olabileceğini fark ediyorsunuz. iyi bir fikre sahip olmakla birlikte, çoğu yazılım projeniz için ciddi sonuçlara yol açabilecek ciddi tasarım kusurlarına sahip olacak - tanınmış çerçeveler bile zaman zaman tasarım kusurlarıyla mücadele ediyor.

Ancak bu güzel fikirlerin tümüne sahip olursak ve hepsini bir araya getirirsek ve akıllı geliştiriciler bu deneylerin hepsinden iyi şeyler alırsa ve bu belirli sorun için en iyi şekilde çalışan gerçekten harika bir yapı yaparsak ne olur? O zaman Tasarım Desenlerini yeni yarattınız . Eğer yaşayan bir canlıysanız, başka yol yoktur; Hayvanlar bile günlük yaşamlarında en iyi uygulamaları ve tasarım kalıplarını izler.

Bir çekiç yeniden icat etmeyin, ama her soruna çivi gibi davranmayın

Programlama kalıpları harika bir zaman tasarrufu sağlar, çünkü size kullanıma hazır çözümler sunar, iyi belgelenmiş ve kolayca unutabileceğiniz ortalama vakalarla test edilmiştir. Ancak bunları ne zaman kullanacağınızı öğrenmeniz (ve düşünmeniz) gerekir.

Sorunuzu yeniden ifade etmek: araba kullanmayı öğrenmek beni daha hızlı hareket ettirir mi yoksa daha yavaş yürür mü?

Programlama modelinin nasıl kullanılacağını öğrenmek, kendi çözümlerini bulmak için egzersiz yapmamanız gerektiği anlamına gelmez. Yaratıcılığınızı geliştirmek için hala yeterli probleminiz olacak. Programlama kalıplarını bilmek, yalnızca iyi bilinen problemlerle hızlı şekilde çalışmanıza ve daha az önemsiz olanlara odaklanmanıza izin verecektir.

Sorunuzun ikinci kısmına geri dönersek - uzmanınız doğru mu?

Evet haklı . Çalışmaların temel amacı, düşünmeyi öğrenmektir . Soruna kendi çözümlerini bulmaya çalışmalı ve mevcut çözümlerle karşı karşıya kalmalılar. Sadece bu şekilde onları gerçekten anlayabilirler. Onları önce kalıplarını öğrenirseniz, geride bıraktıklarını anlamayı değil, sadece uygulamalarını ve mekanik olarak öğrenmelerini riske atarsınız.

Bu, ilk önce öğrencilere programlamayı öğretme nedeninizdir ve kalıplar daha sonraki dönemlerde tanıtılmaktadır.

Tasarım desenlerini öğreterek programlama öğretmeme kesinlikle tavsiye ediyorum. Bunları arkasındaki ilkeleri anlamadan iyi uygulayamazsınız, bu yüzden bu ilkelerin öğretilmesi çok daha önemlidir.

Zaten tasarım kalıplarının çalışan programcılar için de o kadar değerli olmadığını düşünme eğilimindeyim. Belirli bir tasarım modelinde yer alan ilkeleri tam olarak anlarsanız, o zaman iyi bir çözüm olduğu bir durumda, tabii ki, bilmeseniz bile, tabii ki, doğal olarak onu (veya benzer bir şeyi) kurma eğiliminde olacaksınız. Bu bir isim ile bir kalıptı. Öğrenme kalıplarını harcadığınız zaman, genel olarak kod hakkında nasıl düşünüleceğini öğrenmekle daha iyi harcanabilir. Eğer "genel olarak problem çözme" becerileriniz çizilmiyorsa, bazı kalıplar uyguladığınızda ne kadar iyi olduğunuza bakmaksızın iyi bir kod yazamazsınız. Eğer "genel olarak problem çözme" becerileriniz iyi ise, o zaman tek bir kalıp bilmeseniz bile problemleri çözebilirsiniz.

Ayrıca ideal bir dünyada herhangi bir tasarım deseni olmayacağını düşünüyorum , çünkü bir desen olarak adlandırılacak kadar yaygın olan fikirlerin kütüphanelerde iyi bir şekilde uygulanabileceğini ve aslında sürekli olarak yeniden yazmak yerine kodu yeniden kullanacağımızı düşünüyorum. Her zaman kullanmak istediğinizde küçük bir regex motoru uygulamanızı gerektiren bir "normal ifade tasarım deseni" olup olmadığını hayal edin. Tasarım kalıpları sadece yazılamayan kütüphanelerdir çünkü dil doğru soyutlama imkanlarını sağlamamaktadır.

Bu aslında onlarla çok fazla ilgilenmemek için başka bir neden; bazen iddia edildiği kadar evrensel bir yerde değiller, ancak aslında belirli bir dilin izin verdiği / teşvik ettiği programları yapılandırma biçimlerine çok güçlü bir şekilde bağlılar. Python için yazılmış bir tasarım desenleri kitabı Java için yazılmış bir kitaptan tamamen farklı, Haskell gibi zorunlu olmayan bir dil için yazılmış bir kitaptan bile farklı olacaktır. Daha derin bir seviyede anlamak daha iyidir ve aşina olduğunuz her dilde tasarım kalıplarını kendiniz keşfedebilirsiniz.

Ticaret ve eğitimin farklı hedefleri var. Öğrencilere tasarım desenleri öğretiyor olsaydım, aynı yaklaşımı kullanırdım. Ancak üretim ortamında, zaman ve verimlilik her şeydir.

Dahası, sınıf dışında (makro) ekonomi farklı bir şeydir. Hükümetleri görüyor musunuz, "Vay canına! Şimdi vergileri ve aynı şekilde süper yapmaktan bıktık, o zaman bu sefer çok tuhaf bir şeyler deneyelim" mi? Hayır, yapmazsınız, çünkü böyle vahşi deneyler ekonomiyi onarılamayacak kadar paramparça edebilir. Bunun yerine, denenmiş ve test edilmiş yaklaşımlara sadık kalıyorlar: faiz oranını arttırmak, vergi tatillerini ilan etmek vb. Başka bir deyişle, tasarım modellerine güveniyorlar.

Cevap elbette: Evet.

Tasarım desenleri, nasıl çalıştıklarını ve neden getirdikleri değeri getirdiklerini anlamak için zaman ayırdığı sürece, kendi içinde harika bir öğrenme aracıdır.

Ayrıca, bir tasarım sürecini hızlı takip ederek büyük verimlilik artırıcıları olabilirler, çünkü sürekli ortaya çıkan sorunlara tanıdık çözümler sunarlar.

Ancak, çok fazla kısa devre tasarımı yaparlarsa veya insanlar dogmatik ve kullanımları konusunda aşırı hassas hale gelirlerse, ters etki yaratırlar.

Tasarım desenleri elbette daha az yaratıcı. Bütün fikir bu. Yaratıcılık kıt bir kaynaktır. Yaratıcılığa ihtiyaç duymayan sorunlara harcamamalısınız. Bir problemi önünüzdeki yüzlerce geliştiriciyle aynı şekilde çözerseniz, çalışması çok daha kolay, daha hızlı ve daha muhtemeldir. Sıkıcı, beklenmedik kod işini yapan kod aslında iyidir.