“Yapılandırma kongre” temel programlama ilkelerini ihlal etmiyor mu?

WPF MVVM çerçevesi Caliburn.Micro'ya bakıyordum ve birçok standart şeyin adlandırma kurallarına dayandığını okudum .

Örneğin, Görünüm'deki özelliklerin ViewModel'deki özelliklere otomatik olarak bağlanması. Her ne kadar bu uygun görünse de (bazı boyler kodunu kaldırsa da), ilk içgüdüsel tepkim bu kodu okuyacak yeni bir programcı için tamamen açık olmadığı yönünde. Başka bir deyişle, uygulamanın işlevselliği tamamen kendi koduyla değil, çerçevenin dokümantasyonu ile de açıklanmaktadır.

DÜZENLE:

Bu yüzden bu yaklaşıma konfigürasyon konvansiyonu denir. Bununla ilgili herhangi bir soru bulamadığım için sorumu değiştirdim:

Sorum şu:

Konfigürasyon üzerine kongre, işleri basitleştirmenin doğru bir yolu mu, yoksa bazı programlama ilkelerini ihlal ediyor mu (eğer öyleyse hangileri)?

Temel bir programlama ilkesi olarak "bir uygulamanın kendi koduyla tamamen açıklanması gerektiğini" düşünmüyorum. Sadece bir uygulamanın koduna bakarak açıklanmayan birçok şey var. Programlama dilinin kendisinin (sözdizimi ve anlambilim) temel şeylerini bilmenin dışında, kuralları bilmeniz gerekir. Java'daki bir tanımlayıcı büyük harfle başlıyorsa, bu bir türdür. Bilmeniz gereken bu sözleşmelerin bir sürü var.

Yapılandırma konusundaki sözleşme, programcının şeyler hakkında vermesi gereken kararların miktarını azaltmakla ilgilidir. Bazı şeyler için bu açıktır - hiç kimse türlerin büyük harf kullanımı için programınızın başında bildirmeniz gereken bir dilin olduğunu düşünmez - fakat diğer şeyler için o kadar açık değildir.

Kongre ve yapılandırmanın dengelenmesi zor bir iştir. Çok fazla kural kodun karışmasını sağlayabilir (örneğin, Perl'in örtük değişkenlerini ele alın). Programcının tarafında çok fazla özgürlük, bir sistemden edinilen bilgi başka bir okurken nadiren yararlı olduğundan, sistemlerin anlaşılmasını zorlaştırabilir.

Konvansiyonun programlayıcıya yardımcı olduğu yerlere iyi bir örnek Eclipse eklentileri yazarken verilir. Daha önce hiç görmediğim bir eklentiye bakarken hemen bunun hakkında çok şey biliyorum. Bağımlılıkların listesi MANIFEST.MF'de, uzatma noktaları plugin.xml'de, kaynak kodu "src" altında vb. Bunları tanımlamak için programlayıcıya kalsa, her bir Eclipse eklentisi farklı olurdu ve kod navigasyonu çok daha zor olurdu.

+1 ila @JesperE verdi ve bir şeyler eklemek istiyor:

bazı programlama ilkelerini ihlal ediyor mu

Evet, “konfigürasyon konvansiyonu”, “açık, örtük olmaktan daha iyidir” ilkesini ihlal eder (örneğin, "Zen-Of-Python" a bakın ).

Öte yandan, "sözleşme yerine yapılandırma", "Basit karmaşıktan daha iyidir" i ihlal etme eğilimindedir ve daha da kötüsü, DRY ilkesini ince bir şekilde ihlal eder; .

"Yapılandırma üzerine kongre" nin bir kısmı mantıklı varsayılanlara indirgenir. Standart olmayan bir amaç için kullanmak için bir şeyi yapılandırmanız gerekir. Struts ile Rails'i burada karşılaştırmalıyım. Rails'de, "işlem / ekranlarınızı" bir klasöre koymanız gerekir ve ardından çalışırlar. Struts'ta, onları hala bir klasöre koymak zorundasınız, ancak aynı zamanda bir aksiyon ismi ve bir JSP dosyası ve bir form adı ve bir form çekirdeği ile birlikte gelmelisiniz ve bu üç şeyin Struts-config'de birlikte nasıl çalışacağını belirtmelisiniz. xml AND, formun istek üzerine ait olduğunu belirtir (RESTful). Bu yeterli değilse, form / form-fasulye eşlemesi Struts-config'de kendi bölümüne sahiptir ve daha sonra aynı dosyadaki eylem bölümüne bağımsız olarak eşleştirilir ve hepsi çalışmak için JSP dosyasındaki el yazısı dizelerine dayanır. uygun şekilde. Her ekran için bu yapmanız gereken en az 6 şey ve bir hata yapmak için birçok fırsat. İhtiyacınız olursa, bunların çoğunu veya hepsini manuel olarak Rails'te ayarlayabileceğinizi düşünüyorum, ancak gereksiz karmaşıklık katmanlarının oluşturulması ve sürdürülmesi için Struts geliştirme süresi 2 / 3'ü kaplandı.

Adalet, Struts 1 insanlar masaüstü ve web arasında uygulamalar taşırken tasarlandı. Struts'un hazırladığı esneklik, Rails'in yaptığı her şeye ve bir masaüstü uygulamasının ihtiyaç duyacağı her şeye uygun olmasını sağlar. Ne yazık ki, bu esnekliği sağlayan yapılandırma dağı, sadece bir web uygulaması veya sadece bir masaüstü uygulaması yazması gereken biri için büyük bir top ve zincirdir.

Bir sonraki adıma geçtikleri bir yerde çalıştım ve " Kod Üzerinden Konfigürasyon" konusunu tartıştıklarını ancak mantıksal sınırlarına geldiklerini görünce sonuç konfigürasyonun yeni bir kodlama dili haline geldiğini gördüm. Herhangi bir önemli şekilde evcilleştirilmeden karmaşıklığın etrafa itildiği bir kabuk oyunuydu. Ve bana iyi tasarlanmış bir programlama dilinin sahip olduğu tüm tip kontrolleri ve diğer güvenlik ağları için bir takdir kazandırdı. Bir boşluk veya kesme işareti eklerseniz hata mesajı vermeyen bazı yarı pişmiş yapılandırma dosyası formatları, düzenleme araçlarına ve bunun için yazılmış kaliteli bir derleyiciye sahip kaliteli bir programlama dili üzerinde bir gelişme DEĞİLDİR.

Mantıklı varsayılanlara sahip olmanın, genişletilebilirlik ve modülerlik hakkındaki teorik ilkeleri ihlal ettiğini hayal edemiyorum. Bir Ruby / Rails programcısı, tüm konfigürasyonların açıkça birden fazla XML dosyasında yapıldığı Struts 1 gibi bir çerçeveye geçmek yerine, gözlerinde sıcak bir poker yapabilir. Genel olarak Rails'e karşı Struts'a değinmiyorum, ancak bu konvansiyonun büyük bir verimlilik kazancı olabileceğini düşünüyorum. Bu iki teknoloji karşılaştığım en aşırı gerçek dünya karşılaştırması.

Java ile çalışıyorsanız, Joshua Bloch'un "Etkili Java", "Öğe 2:" Pek çok yapıcı parametresiyle karşılaştığınızda bir Oluşturucu düşünün "s. 11-16. Çoğu amaç için, bazı parametreler (yapılandırma) gereklidir ve bazıları isteğe bağlıdır. Temel fikir, sadece gerekli konfigürasyona ihtiyaç duymak ve sadece kullanıcıyı (başka bir program olabilir) gerektiği gibi ilave seçenekler belirlemektir. Bir ay önce bu kalıpla bir sürü kodu temizledim ve olumlu bir şekilde parıldıyor.

Başka bir deyişle, uygulamanın işlevselliği tamamen kendi koduyla değil, çerçevenin dokümantasyonu ile de açıklanmaktadır.

Bir çerçeveyi kullanan bir uygulamanın işlevselliği her zaman çerçeveye bağlıdır, konfigürasyon konvansiyonu bu konuda bir fark yaratmaz.

Tecrübelerime göre, yapılandırmaya göre yapılan düzenleme yalnızca kodu daha okunaklı hale getirmekle kalmaz, aynı zamanda ince hataların (özellikle kopyala-yapıştır-hataları) ortaya çıkma olasılığını azaltır.

Örneğin, bazı çerçevelerde A varsayalım, olay FooBarbir çağrıyı tetikler handleFooBar. Başka bir çerçevede B, bu korelasyon bir XML dosyasında bir yerde yapılandırılmıştır.

Yani, A'da basitçe

handleFooBar() {
   ...
}

FooBar'ı yanlış hecelememişseniz, FooBar ne zaman olursa olsun çağrılır.

B’de yine

handleFooBar() {
   ...
}

Ayrıca

<eventconfiguration>
  <event>
    <type>FooBar</type>
    <handler>handleFooBar</handler>
  </event>
</eventconfiguration>

Bu şekilde yapılandırılacak yüzlerce şeyle, kazara gibi ince bir böcek oluşturmak çok kolaydır

<eventconfiguration>
  <event>
    <type>BarFoo</type>
    <handler>handleFooBar</handler>
  </event>
</eventconfiguration>

çünkü kopyala yapıştırma işleminden sonra sadece değiştik <type>ama değiştirmeyi unuttuk <handler>.

Bu yapılandırma dosyaları büyük ve monoton olduğundan, birisinin hatayı gerçek program kodunda benzer bir hatayı bulacağından prova okuyarak bulması daha az olasıdır.

Birkaç ilkeyi ihlal ediyor olabilir, ancak aynı zamanda en temel tasarım ilkelerinden biri olan SRP'ye (Tek Sorumluluk İlkesi) de uymaktadır.