SOLID Prensiplerini Programlama

Zamanla SOLID'in iki bölümünü anlayabiliyordum - “S” ve “O”.

“O” - Miras ve Strateji Örüntüsünün yardımıyla Açık Kapalı Prensibi öğrendim.

“S” - ORM öğrenirken Tek Sorumluluk ilkesini öğrendim (sebat mantığı alan nesnelerinden uzaklaştırıldı).

Benzer şekilde, diğer SOLID bölümlerini (“L”, “I” ve “D”) öğrenmek için en iyi bölgeler / görevler nelerdir?

Referanslar

1. msdn - C # 'da KATI Prensiplerini İhlal Etme Tehlikeleri
2. channel9 - .NET / C # 'da SOLID Prensiplerinin Uygulanması
3. OOPS İlkeleri (KATI İlkeleri)

Çok yararlı bir makale bulana kadar birkaç ay önce ayakkabının içindeydim.

Her ilke, her yazılım geliştiricisinin projelerinde karşılaşabileceği gerçek dünya durumlarıyla güzel bir şekilde açıklanmaktadır. Burada kısa kesiyorum ve bir seferde bir adım olan SOLID Yazılım Geliştirme referansını işaret ediyorum .

Yorumlarda belirtildiği gibi, başka bir çok iyi pdf okuma var - Pablo'nun SOLID Yazılım Geliştirme .

Ek olarak, SOLID ilkelerini daha ayrıntılı olarak tanımlayan bazı iyi kitaplar var - SOLID Yazılım Geliştirme Konusunda İyi Kitap .

Her ilke için kısa bir özeti düzenleyin ve yorumlar:

• “S” - Tek Sorumluluk İlkesi, değişime izin vermek için işin ihtiyaçlarından kaynaklanmaktadır. “Değişimin tek bir nedeni”, yalnızca teknik kavram yerine iş kavramı ve bağlamı göz önünde bulundurularak hangi mantıksal olarak ayrı kavramların birlikte gruplanması gerektiğini anlamanıza yardımcı olur. In another words, her sınıfın tek bir sorumluluğu olması gerektiğini öğrendim . Sorumluluk sadece verilen görevi başarmaktır

• “O” - Açık Kapalı Prensibi öğrendim ve “miras yerine kompozisyonu tercih et” ve böylece sanal metotları olmayan ve muhtemelen mühürlü olan ancak uzatmaları için soyutlamalara dayanan sınıfları tercih etmeye başladım.

• “L” - Liskov Yerine Getirme Prensibi'ni veri erişimini yöneten depo modeli yardımıyla öğrendim.

• “Ben” - Müşterilerin kullanmadıkları arayüzleri uygulamaya zorlanmaması gerektiğini öğrenerek Arayüz Ayrıştırma Prensibi'ni öğrendim (ASP.NET 2.0'daki Üyelik Sağlayıcı'da olduğu gibi). Öyleyse arayüz “çok fazla sorumluluk” a sahip olmamalı
• “D” - Bağımlılık İnversiyon Prensibi'ni öğrendim ve değiştirilmesi kolay olan kodlamaya başladım . Değişimi daha kolay, daha düşük toplam sahip olma maliyeti ve daha yüksek bakım maliyeti anlamına gelir.

CodePlex yararlı bir kaynak açıklamalarda sözü edildiği gibi, bir referans dahildir örnek KATI

(I) Arayüz Ayrımı ve (D) bağımlılığı Ters çevirme, ünite testi ve alay yoluyla öğrenilebilir. Sınıflar kendi bağımlılıklarını yaratırsa, iyi birim testleri oluşturamazsınız. Çok geniş bir arayüze (veya hiçbir arayüze bağlı değiller) bağlıysa, birim testlerinizi yapmak için neyin üstesinden gelinmesi gerektiği açık değildir.

Liskov İkame Prensibi temel olarak uygulama mirasını fazla kullanmanıza izin vermez: mirası sadece kodun yeniden kullanımı için kullanmamalısınız (bunun için kompozisyon vardır)! LSP'ye bağlı kalarak, üst sınıfınız ve alt sınıfınız arasında bir "is-ilişki" olduğundan emin olabilirsiniz.

Söylediği şey, alt sınıflarınızın tüm alt sınıf yöntemlerini, alt sınıftaki yöntemlerin uygulanmasına benzer şekilde uygulaması gerektiğidir. Asla NOP uygulayan bir yöntemi geçersiz kılmamalı veya süper tip istisna atarken boş değer döndürmemelisiniz; Design by Contract koşullarında belirtilen bir yöntemi geçersiz kıldığınızda, yöntemin üst sınıftan sözleşmesine saygı göstermelisiniz. Bu ilkeyi çiğnemeye karşı savunmanın bir yolu, uygulanan bir yöntemi asla geçersiz kılmamaktır; bunun yerine bir arayüz çıkartın ve bu arayüzü her iki sınıfta da uygulayın.

Arayüz Ayrımı İlkesi , Tek Sorumluluk İlkesi ve GRASP'dan Yüksek Uyumluluk İlkesi bir şekilde ilişkilidir; Bir işletmenin sadece bir şeyden sorumlu olması gerektiği gerçeğine atıfta bulunur, böylece değişimin çok kolay bir şekilde yapılabilmesi için sadece bir sebep olabilir.

Aslında, eğer bir sınıf bir arayüz uygularsa, o zaman bu arayüzün bütün metotlarını uygulaması ve kullanması gerektiğini söyler. Belirli bir sınıfta gerekmeyen yöntemler varsa, arayüz iyi değildir ve sadece orijinal sınıfın ihtiyaç duyduğu yöntemlere sahip iki arayüze ayrılmalıdır. Uygulamalarının LSP'yi kırabilmesi için büyük arayüzler oluşturmanıza izin vermemesi gerçeğiyle, önceki prensip ile ilgili olan bir POV'den kabul edilebilir.

Fabrika Deseninde Bağımlılık İnversiyonunu görebilirsiniz ; burada hem yüksek seviye bileşen (müşteri) hem de düşük seviye bileşen (yaratılacak bireysel örnek) soyutlamaya bağlıdır.(arayüz). Katmanlı bir mimaride uygulamanın bir yolu: Uygulanan katmanda değil, adı verilen modülde bir katmana arabirim tanımlamamalısınız. Örneğin, veri kaynağı katmanına uygulanan API, veri kaynağı katmanına değil, çağrılması gereken iş mantığı katmanına yazılmalıdır. Bu şekilde, veri kaynağı katmanı, iş mantığında tanımlanan davranışa (dolayısıyla tersine çevirme) miras alır / bağlıdır ve bunun tersi olmaz (normal şekilde olduğu gibi). Bu, tasarımda esneklik sağlayarak iş mantığının herhangi bir kod değişikliği olmadan, tamamen farklı bir veri kaynağıyla çalışmasını sağlar.