Swift kullanarak SOLID Tasarım Prensibi

ibrahim6516 · 13 Tem 2021

SOLID ilkeleri, etkili, sürdürülebilir, ölçeklenebilir ve gevşek bağlı bir sistemin uygulanmasının/yaratılmasının temelidir.

Yazılım yazmaya yeni başlamış olmanız veya yıllardır yapıyor olmanız önemli değil. Sisteminizi uygularken bu ilkelere uymaya başlarsanız, sistemdeki her bir katılımcı tarafından takdir edilecektir.

SOLID ne anlama geliyor?

Tek Sorumluluk İlkesi

Sınıfın değişmesi için tek bir nedeni olmalıdır. Zaman içinde ancak o sınıf bağlamında birden çok kez değiştirilebilir. Basit bir ifadeyle, sınıfta değiştirmek için bağlamsal bir nedeni olmalıdır.

Açık ve Kapalı Prensibi

Basit bir ifadeyle, Uzatma için açık ancak değişiklik için kapalı. Sınıflar, sınıfın işlevselliğini genişletmek için açık olmalı ancak mevcut işlevselliğe dokunmaya/değiştirmeye izin vermemelidir.

Aşağıdaki kullanım örneğinden biraz daha anlamaya çalışalım,

Uygulamamızda ödeme entegrasyonu şartı bulunmaktadır. Nakit, kart veya farklı cüzdan kullanma gibi farklı ödeme yöntemlerimiz var.

SOLID'den O ilkesini takip etmezsek, sınıf uygulamamız şöyle olabilir:

Ödeme Yöneticisi… Ödeme için her şeyi yapacağım
Tüm ödeme işlevlerini yerine getirmekten sorumlu olan ödeme yöneticisi sınıfına sahip olacağız. Farklı ödeme yöntemleri için farklı işlevler oluşturduk ve bu ödeme yöntemiyle ilgili tüm ilgili işlevler bunun içinde yer alacak.

endişe Ayrılıklar

Ödemeyle ilgili bir şey olup olmadığını biliyorum. Ödeme yöneticisi sınıfına dokundum.

İYİ görünüyor, Mükemmel çalışıyor!!!

Bekle…

Son zamanlarda Hindistan Ulusal Ödemeler Kurumu, bir UPI (Birleşik Ödeme Arayüzü) ödeme sistemi geliştirdi ve RBI (Hindistan Rezerv Bankası) tarafından düzenlendi .

Gelecekte, başka birçok ödeme sistemi gelebilir. Şimdi mevcut ödeme yöneticisi sınıfını değiştirmemiz/değiştirmemiz ve UPI ödeme sistemi için bir provizyon yapmamız gerekiyor ve her yeni ödeme sistemi mevcut olduğunda, ödeme yöneticisini değiştirmemiz gerekiyor.

Bunda yanlış olan ne?

Mevcut kodu değiştiriyoruz, her zaman istemeden mevcut kodu kırma şansı var.

En kullanarak tasarlamak çalışalım Ç prensibini gelen KATI.

Açık-Kapalı ilkesinin arkasındaki birincil mekanizmalar soyutlama ve polimorfizmdir.

Soyutlama ve Polimorfizm
Her ödeme yönteminin ayrı bir sınıfı olacaktır. Yeni bir ödeme yöntemi eklemek için yeni bir sınıf ekleyeceğiz ve Ödeme Yöneticisi yalnızca kendini genişletmekle sorumlu olacak ve mevcut herhangi bir ödeme yöntemi sınıfına dokunmayacak, bu da bizi istemeden bir şeyleri kırmaktan koruyacaktır.

Sanırım istemeden de Tek Sorumluluk İlkesi'ne uyuyoruz

Liskov İkame Prensibi

Bu ilke, sürdürülebilir ve yeniden kullanılabilir kod oluşturmanın temelidir. Bu ilke, Açık-Kapalı ilkesinin uzantısıdır ve yeni türetilmiş sınıfların davranışlarını değiştirmeden temel sınıfı genişlettiğinden emin olmamız gerektiği anlamına gelir.

Bunu yapmak için aşağıdaki Bird temel protokolü oluşturulur

Geliştirici, Bird protokolünü onaylayan birçok farklı türde kuş sınıfı oluşturabilir.

Fakat ikinci versiyonda Penguin sınıfını ekleyip Bird protokolüne onay vermemiz gerekiyor fakat bir sorun var. “

uçamaz. ”

İçinde herhangi bir uygulama yok

Bir geçersiz kılma yöntemi hiçbir şey yapmazsa veya yalnızca bir istisna atarsa, muhtemelen LSP'yi ihlal ediyorsunuzdur.

Uygulama çalıştırıldığında, Penguin nesneleri setAltitude yöntemini yok saydığından tüm uçan desenler yanlış görünür. Penguenler yerde yüzüyor. Geliştirici OCP'yi takip etmeye çalışsa da başarısız oldu. Mevcut kod, Penguin sınıfını barındıracak şekilde değiştirilmelidir.

Bir penguen teknik olarak "bir" kuş olsa da, Bird sınıfı tüm kuşların uçabileceğini varsayar. Penguen alt sınıfı uçma varsayımını ihlal ettiğinden, Bird üst sınıfı için Liskov İkame İlkesini karşılamaz.

Bu sorundan nasıl kurtulur?

Liskov İkame Prensibini Takip Edin
İŞARETÇİLERİ VEYA TABAN SINIFLARINA REFERANSLARI KULLANAN FONKSİYONLAR TÜREV EDİLMİŞ SINIFLARIN NESNELERİNİ BİLMEDEN KULLANABİLİR OLMALIDIR.

Tom'un Penguen Problemi

Arayüz Ayrıştırma Prensibi

Arayüz Ayrıştırma İlkesi istemcilerin kullanmadıkları arabirimleri uygulamaya zorlanmaması gerektiğini belirtir. Tek bir yağ arayüzü yerine, her biri bir alt modüle hizmet eden yöntem gruplarına dayalı birçok küçük arayüz tercih edilir.

Basit bir ifadeyle, İstemciler kullanmadıkları arabirimlere bağımlı olmaya zorlanmamalıdır.

2 tip çalışanımız var, bazıları ortalama ve bazıları çok verimli çalışanlarımız. Her iki tür işçi de çalışır ve yemek için günlük bir fırlatma molasına ihtiyaçları vardır.

Arayüz Ayrımı İlkesi Olmadan
Ama şimdi çalıştıkları şirkete bazı robotlar da geldi, ama yemek yemedikleri için fırlatma molasına ihtiyaçları yok. Bir yandan yeni Robot sınıfının, robotlar çalıştığı için IWorker protokolünü/arayüzünü uygulaması gerekir. Öte yandan, yemedikleri için uygulamak zorunda değiller.

Yeni işçi Robot- Yemek yemiyor.

Bu durumda IWorker'ın kirli bir arayüz/protokol olarak kabul edilmesinin nedeni budur.

Mevcut tasarımı korursak, yeni Robot sınıfı yemek yöntemini uygulamak zorunda kalır. Hiçbir şey yapmayan kukla bir sınıf yazabiliriz (diyelim ki günde 1 saniyelik bir başlatma arası) ve uygulamada istenmeyen etkilere neden olabilir.

Arayüz Ayrımı İlkesine göre, esnek bir tasarım kirli arayüzlere sahip olmayacaktır. Bizim durumumuzda IWorker arayüzü 2 farklı arayüze bölünmelidir.

Arayüzleri/protokolü Ayıralım
Bunu, Arayüz Ayrıştırma İlkesini destekleyen koddan sonra gelir. IWorker arabirimini 2 farklı arabirime bölerek, yeni Robot sınıfı artık yeme yöntemini uygulamak zorunda kalmıyor. Ayrıca, robot için yeniden şarj etme gibi başka bir işleve ihtiyacımız olursa, yeniden şarj etme yöntemiyle başka bir IRechargeble arabirimi oluştururuz.

Arayüz Ayrıştırma İlkesi
Bu, çalışma süresi sürprizlerinin olmadığı anlamına gelir. Derleme zamanında Robot'un yemek yiyemeyeceğini biliyoruz.

NOT: Arayüzün bunu yapmanın daha net olması için protokol adının önündeki 'I'yi kullandım. Biliyorum, Swift dilinde bu adlandırma kurallarını/gösterimlerini kullanmıyoruz/takip etmiyoruz.

Bağımlılık Tersine Çevirme Prensibi

Bağımlılık inversiyon prensibi belirli bir biçimine atıfta

Linkleri görebilmek için Turkmmo Forumuna ÜYE olmanız gerekmektedir.

yazılım

Linkleri görebilmek için Turkmmo Forumuna ÜYE olmanız gerekmektedir.

.

A. Yüksek seviyeli modüller, düşük seviyeli modüllere bağlı olmamalıdır. Her ikisi de

Linkleri görebilmek için Turkmmo Forumuna ÜYE olmanız gerekmektedir.

bağlı olmalıdır .

B. Soyutlamalar ayrıntılara bağlı olmamalıdır. Detaylar soyutlamalara bağlı olmalıdır.

Diyelim ki, üst düzey bir sınıf olan Yönetim sınıfına sahip olduğumuz ve Çalışan adlı düşük seviyeli bir sınıfımız olan bir şirket yönetim sistemi kuruyoruz.

Bağımlılık Tersine Çevirme İlkesi Olmadan
Yeni uzman personel alımı ile şirket yapısındaki değişiklikleri modellemek için uygulamamıza yeni bir modül eklememiz gerekiyor. Bunun için yeni bir sınıf İşveren yarattık.

Sistemde yeni bir İşveren olması şartı
Manager sınıfının oldukça karmaşık olduğunu ve çok karmaşık mantık içerdiğini varsayalım. Ve şimdi yeni İşvereni tanıtmak için onu değiştirmeliyiz.

Dezavantajları görelim:

1. Management sınıfını değiştirmeliyiz (bunun karmaşık olduğunu ve bu, değişiklikleri yapmak için zaman ve çaba gerektireceğini unutmayın).
2. Yönetim sınıfındaki bazı mevcut işlevler etkilenebilir.
3. Birim testi yeniden yapılmalıdır.

Tüm bu sorunların çözülmesi çok zaman alabilir ve eski işlevsellikte yeni hatalara neden olabilir. Uygulama, Bağımlılık Tersine Çevirme İlkesine göre tasarlanmış olsaydı durum farklı olurdu.

Bu, Yönetim sınıfını, bir IEmployee arabirimini ve IEmployee arabirimini uygulayan Çalışan sınıfını tasarladığımız anlamına gelir. İşveren sınıfını eklememiz gerektiğinde tek yapmamız gereken bunun için IEmployee arabirimini uygulamaktır. Mevcut sınıflarda ek değişiklik yok.