Uzlaşmak zorundayım: KURU veya Komut-Sorgu-Ayırma?

Son zamanlarda bir komut ve bir sorgu yöntemi olan bir yöntemi refactoring.

Bir komut yöntemi ve bir sorgu yöntemine ayırdıktan sonra, şimdi kodu çağırıyorum sonra DRY ilkesinin ihlali gibi görünüyor sorgudan değeri almak nerede kodda birden çok yer olduğunu buldum.

Ama bu ortak kodu bir yönteme sarmak olsaydı, bu yöntem hem komut hem de sorgu olurdu. Bu kabul edilebilir mi?

Çelişen tasarım ilkeleri arasında daima göz önünde bulundurulması gereken değişimler vardır. Bunu çözmenin yolu, ilkelerin ardındaki temel nedenlere bakmaktır. Bu durumda, komutu çalıştırmadan bir sorguyu çalıştıramamak sorunludur, ancak sorguyu çalıştırmadan bir komutu çalıştıramamak genellikle zararsızdır. Sorguyu tek başına çalıştırmanın bir yolu olduğu sürece, özellikle de böyle bir şey yapılırsa, sorgu sonucunu komuta eklememek için hiçbir neden göremiyorum:

QueryResult command()
{
   // do command stuff
   return query();
}

Daha önce Komut-Sorgu-Ayırma (CQS) duymadım, ancak bir işlevin / sınıfın ideal olarak sadece bir şey ve bir şey yapmaktan sorumlu olması gerektiğini belirten Tek Sorumluluk İlkesi (SRP) ile ilgili olacağı anlaşılıyor. .

Komut kodunuz 20 satır kod ve sorgu kodu başka bir 30 satır ise ve hepsi bir işlev gövdesindeyse, SRP'yi ihlal ediyorsunuz ve CQS'yi de varsayıyorum ve bu iki mantık birbirinden ayrılmalıdır. .

Ancak, varsayımsal örneğinizle giderken, büyük olasılıkla DRY'nin kodun çeşitli yerlerinde ihlal edilmemesi için komutunuzu ve sorgunuzu birleştirecek bir sarmalayıcı yöntemi oluşturacağım. Ben de sarıcı hala tek bir sorumluluğu var: SRP (ve belki CQS) ihlali olarak düşünmek olmaz: komut bir sorgu ile birleştirmek ve tüketmek daha kolay bir üst düzey soyutlama oluşturmak.

Sarma yönteminin mükemmel kabul edilebilir bir çözüm olduğunu düşünüyorum ve bunu göstermek için örneğinizi bir adım daha ileri götürelim. 1 yerine 2 sorgu çalıştırıp ardından buna dayalı bir komut eylemi yapmanız gerekiyorsa ne yapmalısınız? Yani 2 kod satırınız 6 veya 8 olur. Ya biri ile diğeri arasında veri doğrulama / kontrol olsaydı, şimdi 15 kod satırınız var. Bu 15 satırı birden fazla dosyaya serpmek yerine, tüm bunları yapan bir sarıcı oluşturma hakkında iki kez düşünür müsünüz?

DRY daha önemlidir, çünkü çok daha temel bir ihtiyacı çözer - gereksiz, etkili boşa harcanan çabayı önler. Bu temel bir şeydir - bunu anlamak için programcı olmak gerekmez.

CQS, izleme sonuçları için desteği olmayan dillerde, hem sonuçları hem de etkileri için yürütülen kodu anlama zorluğuna bir yanıttır. Ancak:

1. Sonuçları için kod yürütme zorunluluğundan kaçınılamaz, çünkü bu küçük birimlerden büyük programlar oluşturmanın temelidir.

2. Etkileri için kod yürütme zorunluluğundan da kaçınılmaz, çünkü matematik ve teorik bilgisayar bilimi dışında, bir program yürütmenin değeri, gözle görülür şekilde bizim için yapabileceklerine dayanır.

3. Etkilere neden olma ve aynı kodda sonuç üretme zorunluluğundan kaçınılamaz, çünkü pratikte, sadece birine veya diğerine değil, hem etkilere hem de kompozisyona ihtiyacımız vardır.

Etkileri izlemenin insanlar için çok zor olması sorununa asıl çözüm, elbette bilgisayarların bize insanlara yardım etmesini sağlamaktır ! Benzer bir şey, istisnaların ve çalışma zamanı tarafından zorlanan sözleşmelerin (olmayan) çözümler oluşturduğu çalışma zamanı değerleri (dizi indekslerinin geçerliliği gibi) arasındaki karmaşık ilişkilerin izlenmesi hakkında söylenebilir .

Sonuç olarak, CQS gibi "çözümler" sadece gerçekliğe dayalı sağlam ilkelere göre program tasarlama yolunda ilerlemektedir. KURU'ya git.