Sözleşmeye Göre Tasarım ve Savunma Programlaması arasındaki farklar

Yanıtlar:

30

Sözleşmeye Göre Tasarım ve savunma programlaması bir anlamda birbirinin karşıtlarıdır: DbC'de, ortak çalışanlar arasındaki sözleşmeleri tanımlarsınız ve ortak çalışanların sözleşmelerini yerine getirdiği varsayımı altında program yaparsınız. Savunma programlamasında, ortak çalışanlarınızın sözleşmelerini ihlal ettiği varsayımı altında program yaparsınız .

DbC tarzında yazılmış gerçek bir kare kök rutini, sözleşmesinde, negatif bir sayı girmenize izin verilmediğini ve daha sonra hiçbir zaman negatif bir sayı ile karşılaşamayacağını varsaymaz. Savunmadan yazılmış gerçek bir karekök yordamı negatif bir sayının geçtiğini ve uygun önlemler aldığını varsayar.

Not: Elbette DbC’de bir başkasının sözleşmeyi kontrol etmesi mümkündür . Örneğin Eyfel'de, sözleşme sistemi çalışma zamanında negatif bir sayı olup olmadığını kontrol eder ve uygun bir istisna atardı. Spec # 'da, teorem prover derleme zamanında negatif sayıları kontrol eder ve rutinin hiçbir zaman negatif bir sayıdan geçmeyeceğini ispat edemezse derleme başarısız olur. Aradaki fark, programcının bu kontrolü yapmamasıdır.

— Jörg K Mittag
kaynak
7

Sözleşmeye Göre Tasarım (DbC) savunma programlamanın bir yolu olabilir mi?

Evet.

“Defansif Programlama” genellikle zaman harcamak için bir bahane. Genellikle olağan istisnalara yol açacak şeyleri kontrol etmek için zaman harcar. İstisnalar yerine, istisnai durum hükümleri yerine ekstra IF beyanları yazılır.

Sözleşmeyi tanımlayın ve onunla bitirin.

Birisi sözleşmeyi ihlal ettiğinde, program - olayların normal seyri sırasında - normal olarak ele alınabilecek normal istisnaları kıracak ve yükseltecektir.

"Defansif programlama" ve "Hata önleme" hataların önlenmesinden ziyade hatalar (hata önleme kontrollerinin kendileri hatalı olduğu için) eklediği gösterilebilir.

İstisna işleme, "Savunma Programlaması" ndan çok daha iyi bir istisnayı susturabilir, günlüğe kaydedebilir ve kaldırabilir.

— S.Lott
kaynak
6
Savunma programlaması ifadelerden çok moe. Kod incelemeleri, statik analiz, güvenlik denetimleri, güvenli kodlama kuralları ve daha fazlasını içerir. Ek olarak, istisnalar ve istisnaların kullanılması (sadece programın çökmesine ve yakılmasına izin vermenin aksine) savunma programlama tekniği olarak kabul edilir.
— Thomas Owens
2
@ThomasOwens: "İyi Yazılım Geliştirme" gibi geliyor. Sadece istisnalar normalde ortaya çıkmadan önce başarısız olan birçok IF ifadesi (veya iddiası) yazmak için bir bahane olarak kullanılan savunma programlarını gördüm. Uzun ve iyi fikirler listene "Defansif Programlama" demezdim. İyi fikir listenize "Programlama" derim. Bu şekilde zaman kaybını listelediğiniz tüm akıllı şeylerden ayırabiliriz.
— S.Lott
2
Bu kodları kendim "kod yazarken iyi fikirler" olarak adlandırmayı tercih ediyorum, ancak savunma programlaması hakkında eğitim aldığımda, sistemin güvenliğini, güvenliğini ve güvenilirliğini sağlama amaçlı açık ve net bir şekilde herhangi bir teknikle ilgili olduğunu öğrendim. . Belki bu aşırı geniş bir tanımdır, ya da belki yanlış bir tanımdır, ama bana öğretildi. İnsanların ifadeler ve iddialar “savunma programlaması” diyorsa, ancak öğrettiğim tanıma dayanarak, istisnalar gibi daha iyi seçeneklerin olması gerekmediği durumlar hariç) böyle bir şey demeyeceğimi gördüm.
— Thomas Owens
@ThomasOwens: "Belki de aşırı geniş bir tanımdır". Anlaşmak. İyi fikirlerin harika bir kontrol listesi gibi görünüyor.
— S.Lott
2
-1: DbC'nin defansif bir programlamanın nasıl bir yol olduğunu anlamıyorum, temelde zıtlar. Sadece zaman kaybetmek için savunma programlaması yapmanın yaygın olduğundan şüpheliyim. Ve 'hata eklediği gösterilebilir' bir alıntıya ihtiyaç duyuyor, çünkü hiç belli değil.
— Mark
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.