Dil yapılarına neden tasarım kalıpları eklenmiyor?

Son zamanlarda, şirketinin bir PHP uzantısı olarak MVC tasarım modelini eklemek için çalıştığını belirten bir meslektaşımla konuşuyordum.

Controllers, Models and ViewsPerformansı artırmak için dil yapılarına eklemek üzere C kodu yazdıklarını açıkladı .

Şimdi MVC'nin web uygulamalarında yaygın olarak kullanılan bir mimari tasarım deseni olduğunu biliyorum, ancak yine de örneğin Denetleyiciler için bir dil yapısına sahip dillerle karşılaşmam gerekiyor.

IMHO tasarım kalıplarını bir dile entegre etmek iyi OO tasarımının önemini vurgulayabilir.

Peki, neden en çok kullanılan tasarım kalıpları (MVC, Factory, Strategy, ... vb.) Dil yapılarına eklenmiyor?

Soru çok geniş geliyorsa, soruyu yalnızca PHP ile sınırlandırabilirsiniz.

Düzenle:

Bir proje geliştirirken bir tasarım deseni kullanmak gerektiğini ima etmiyorum . Aslında çalıştığı sürece basit tutma yöntemini destekliyorum.

Tasarım Kalıpları edilmektedir dil yapılara her zaman eklenmektedir. Hiç Altprogram Çağrı Tasarım Deseni duydunuz mu? Hayır? Ben de değil. Yani en Altrutin Aramalar, çünkü vardı hemen hemen anında dillere ekledi var 1950'lerin başında bir Tasarım Deseni. Günümüzde, CPU'ların makine kodu talimat setlerinde bile mevcutturlar.

Ne hakkında İçin Döngü Design Pattern? İken Döngü Tasarım Deseni? Anahtarı Tasarım Deseni? Nesne Tasarım Deseni? Sınıf Tasarım Deseni? Bunların hepsi bazı dillere eklendi.

Onlardan bazıları. Örneğin, yineleyiciler birçok dilde ve standart kütüphanelerinde dil özelliğidir (merhaba, foreach ve getiri dönüşü). Gözlemci de sık sık olaylar şeklinde bulunur (PHP'de değil - geri arama aboneliğini kendiniz yönetmeniz gerekir). Komut, WPF'nin temel özelliğidir.

Diğerlerinin birçoğu dil desteğinden gerçekten fayda sağlamaz (ve dili daha hantal hale getirir) - onlar için dil özelliği tasarlayabilirseniz Denetleyicileri nasıl basitleştirirdiniz? Sınıflar olarak, sınıfları desteklemek için halihazırda mevcut olan tüm altyapıdan yararlanırlar - onları somutlaştırabilir, etrafından geçirebilir ve örneğin herhangi bir nesne olarak ünite testi yapabilirsiniz.

IMO'nun bir tür dil desteğinden yararlanabileceği tek MVC bileşeni View (bazı resmi şablonlama motoruyla) - ve PHP'de zaten desteklenmektedir - dinamik olarak PHP komut dosyaları oluşturabilir ve yükleyebilirsiniz (bunlar genellikle şablon olarak kullanılan bir tür önişleme).

Aynı şey fabrika yöntemi için de geçerlidir - istediğiniz herhangi bir dil özelliğiniz varsa bunu nasıl basitleştirebilirsiniz? Bazı dillerin (C ++ gibi) eksik olduğu bir özellik, bu tür adından nesne oluşturma yeteneğidir, ancak çoğu üst düzey dil bunu yapabilir (ve yararlı fabrika yöntemleri oluşturmak için bile gerekli değildir). Bunun dışında, ihtiyacınız olan tek şey bir örnek oluşturabilmeniz ve geri döndürmemeniz.

Bazı tasarım kalıpları gerçekten de dil kurguları olarak eklenir - sadece bu şekilde tanımlanmazlar, çünkü insanlar bir kez kurulduktan sonra onları “sözdizimi” olarak görmeye başlarlar. Java'da istisna işleme iyi bir örnektir - birçok kişi benzer bir şeyi açıkça kodlar Çekirdek sözdiziminin bir parçası olmasaydı tasarım deseni olarak.

Ancak soruya odaklanmak için - bir dile çok fazla tasarım deseni eklemek istememenizin birçok nedeni vardır:

• Bunları dil kurucu olarak eklemek gerekli değildir - tüm tasarım kalıpları başka şekillerde uygulanabilir
• Dili zorlaştırır - bu, dili öğrenmeyi zorlaştırdığı, derleyicileri ve araçları yazmayı zorlaştırdığı için kötü bir fikirdir
• Birçok tasarım modeli için alternatif uygulama yaklaşımları mevcuttur. Bir yaklaşım seçmek ve onu temel dilin bir parçası olarak kutsamak, muhtemelen insanları bu yaklaşımı başkaları üzerinde kullanmaya yönlendirecektir (bazı durumlarda daha iyi olabilir)
• Tasarım modellerine aşırı güvenmek her durumda muhtemelen kötü bir fikirdir - dil tasarımcıları muhtemelen onları daha da teşvik etmemeleri gerektiğini fark ederler.

Ayrıca, metaprogram oluşturma yetenekleri (örn. Lisp) ile yeterince güçlü bir dil kullanırsanız, dili herhangi bir tasarım desenini uygulamak için kendiniz genişletmek nispeten kolaylaşır . 5 satırlı bir makro ile kendiniz eklemek kolaysa, temel dilde herhangi bir desene ihtiyacınız yoktur.

Dil yapılarına neden en çok kullanılan tasarım kalıpları (MVC, Factory, Strategy, ... vb.) Eklenmiyor?

Bu modellerin çoğu, belirli bir dil desteği olmadan çoğu programlama dilinde uygulanabilir. Örneğin Java'daki MVC'yi ele alalım:

• Doğrudan kodlayabilirsiniz.
• Bir uygulama jeneratörü kullanarak uygulayabilirsiniz ... ve aynı anda çok sayıda diğer kazan plakasıyla ilgilenebilirsiniz.
• Bunu "framework" kütüphane sınıflarını kullanarak uygulayabilirsiniz.
• Ek açıklamaları ve statik veya çalışma zamanı ek açıklama işlemini kullanarak uygulayabilirsiniz.

Tüm bu seçenekler göz önüne alındığında, dili doğrudan genişletmenin çok az değeri vardır. Ve bir dizi "olumsuz" vardır:

• Bu, dil sözdizimini karmaşık hale getirme eğilimindedir (tartışmalı olarak) acemi programcılar için hayatı zorlaştırır.
• Dil spesifikasyonunu daha büyük ve daha karmaşık hale getirme eğilimi göstererek, dil uygulayıcıları için zorlaştırır. (Ve elbette, spesifikasyon ne kadar büyük olursa, hatalar ve tutarsızlıklar olma olasılığı o kadar yüksektir.)
• Her zaman başka bir model daha eklemek için baskı olacaktır ... dil istikrarı ile ilgili sorunlara / endişelere yol açacaktır.
• Dilde belirli kalıpları destekleyerek, bazı uygulamalara uymayabilecek kalıpları desteklemenin belirli yollarını sabitlersiniz.

Onlar.

Fonksiyonlar, C'de bir dil kurumu haline gelmeden önce montaj kodundaki bir tasarım modeliydi.

Sanal işlevler, C ++ 'da bir dil yapısı haline gelmeden önce C'de bir tasarım modeliydi.

Ancak, bir değiş tokuş var. Kalıp, kazan plakası kodunun (birkaç anahtar kelime bile) üretimini içeriyorsa, bu yararlı bir dil özelliği olacağının bir göstergesidir. Ancak, desen basit ve açıksa, örneğin. C'nin "(int i = 0; i <10; i ++)" için, herkesin aynı şekilde yazması yine de yararlıdır, ancak "i = 0 ila 10" için önemli ölçüde daha uzun değildir ve önemli bir avantaja sahiptir. biraz farklı bir döngü yapmak için nasıl değiştirileceği açıktır.

'Dörtlü çete' kitabını okuduğunuzda anlaşılacaktır:

1. Kitaptaki tasarım örüntüleri aslında diğer OO dillerinde kodlanmış küçük konuşma kurallarıdır.
2. Bu nedenle, bu desenler OO diline dahil edilemez - bu diller içindeki küçük konuşmayı yeniden uygular - küçük konuşmayı doğrudan kullanmak daha iyidir
3. Tasarım kalıplarının neden yararlı olduğu, şu anda kullanılan dilin rolünü vurgulamaları ve sözdizimi dışındaki diğer konulara odaklanmalarıdır. Bu kalıpları dil içinde kodlamak, tasarım kalıplarının bu özelliğini kaybedecektir.
4. Yukarıdaki sorudaki asıl sorun, yazma yazılımının sadece dili öğrenmekle ilgili olmadığı noktasını kaçırmasıdır. Doğrudan hangi dilin sağladığından yeterli mesafe almak ve mevcut gereksinimlere odaklanmak önemlidir.

Çünkü tasarım kalıpları kullanıcı kodu ile mükemmel bir şekilde uygulanmaktadır. Onun örneği sadece PHP olduğu için oldu - ama aslında performansa ihtiyacınız varsa, sadece başka bir dilde çalışacak ya da HipHop ya da başka bir şey alacaksınız.

Dil özellikleri hem belirtilmesi hem de uygulanması karmaşıktır ve yalnızca "Mevcut deyimler X'tir" amacıyla bir tane oluşturmak haklı değildir. Herhangi bir anlamlı kullanıcı kodunu neredeyse hiç kaydedemezsiniz.

Eh, bayat soru ama ben semantik kadran üzerinde kabul edilen de dahil olmak üzere "Tasarım Desenleri" ayarladığınız yere bağlı olarak bir çok cevap ile katılmıyorum.

GoF Tasarım Desenleri kitabında buna bağlı olduğunu söyleyebilirim. Örneğin, MVC (aslında bir GoF kalıbı değil, ancak bu kalıba uyar), toplu tüketim için dil yapıları olarak ifade etmek tamamen uygun değildir (belirli bir PHP projesi için mantıklı olsa da). Mimari bir desen olarak tema üzerinde sürekli varyasyonlar ve farklı durumlar için çok çeşitli mükemmel yasal yorumlar vardır (çoğu MVC'den çok uzak olsa da, muhtemelen artık MVC olarak adlandırılmamalıdır). Örneğin, web'de, http bariyeri, denkleme istemci tarafını (şüphesiz acı verici) dahil etmeye çalışıp çalışmadığınıza ve ne düşündüğünüzü daha fazla görebildiğinize bağlı olarak biraz garip bir uyum sağlar uygun şekilde sunucu tarafı bakış açısı.

İteratör ise çok çeşitli yapılara çok çeşitli şekillerde uygulanabilen oldukça genel bir kavramdır.

Bir şeyin bir çekirdek dil tasarımına ait olup olmadığına, sunucu tarafındaki web'e özgü bir dilde bile, IMO, çizilmesi gereken şey, bir şeyin çizgiden geçtiği ve hesaplanamayan sayıda şey yapmayı kolaylaştıran noktadır daha kolay ve sizin için bir mimari desen gibi aşırı spesifik ancak geniş ölçüde uygulanan bir şey yapmak.