Akıllı Sözleşme Geliştirme Sürecinde SOLID İlkeleri 🚀
Bu ilke ilk olarak nesne yönelimli programlama bağlamında ortaya çıktı, ancak özellikle işlevsel programlamaya olan popülerliğin artmasıyla ilke setinin belirli bir paradigma yerine yazılım geliştirme sürecinin geneline uygulanabilir olduğu görüldü.
Herhangi bir talimat kümesi gibi, bu ilkelere körü körüne uymamak, onları bir dizi öneri olarak takip etmek gereklidir. Genel olarak bir bilgisayar, çalıştırdığı kodun güzel mi yoksa çirkin mi olduğunu umursamaz, sonuçta sıfır ve birler üretecektir; ancak biz geliştiriciler olarak okunabilir, bakımı yapılabilir ve ölçeklenebilir kod elde etmek isteriz, bu nedenle SOLID ilkelerini takip etmek kötü bir proje işaretlerini ortadan kaldırmaya yardımcı olur.
Bu makalede, SOLID ilkelerini akıllı sözleşmelerle çalışma bağlamında ele alacağım. Her bir ilke için Bob Martin tarafından verilen tanımı sağlayacak ve ilkenin özünü gösteren örnekler sunacağım. Haydi başlayalım!
🅢 – Tek Sorumluluk İlkesi: Bir Sınıfın Tek Bir Nedeni Olmalıdır 🧰
OpenZeppelin’i incelediğinizi düşünün, bu kütüphane modülerliği destekliyor. ERC-20 standardını destekleyen, ERC-721, ERC-1155 vb. Sözleşmeler var. Her biri farklı sorumlulukları taşıyan bu sözleşmeler, ihtiyaç duyulan işlevselliği eklemek için kullanılabilir. Örneğin, iki farklı sorumluluğa sahip olan iki sözleşme (Mülkiyet ve Jeton) varsa, Mülkiyet işlevselliği gerekiyorsa, bunu diğer sözleşmeye eklemek için kalıtım kullanılabilir. Bu ilke, kod karışıklığını önlemeye ve takımda çalışmayı şeffaf tutmaya yardımcı olur.
🅞 – Açık-Kapalı İlkesi: Yazılım Varlıkları İyileştirmeye Açık, Değişime Kapalı Olmalıdır 🏗️
Akıllı sözleşmelerde değişiklikler karmaşık olabilir. İşte Açık-Kapalı İlkesi devreye giriyor! Bu ilke, “mevcut sözleşmeleri değiştirmeyin, genişletin!” diyor. Orijinal sözleşmeleri değiştiremezsiniz çünkü bu, geriye dönük uyumluluğu bozar. Ancak mevcut sözleşmeyi temel alarak yeni bir sürüm oluşturabilirsiniz. Örneğin, tokenURI işlevini geçersiz kılmak isteyebilirsiniz, ancak herkesi aynı anda memnun edemezsiniz, bu nedenle tokenURI işlemini geçersiz kılan bir başka sözleşme oluşturabilirsiniz. Başka bir örnek, token transferinden önce ve sonra çağrılan beforeTokenTransfer ve afterTokenTransfer işlevleridir. Bu işlevlerin işlevselliği, orijinal işlevleri içeren bir sözleşmeyi devralan bir sözleşmede belirtilebilir ve bu işlevleri çağırmak ve kendi işlevinizi yapmak isterseniz, super anahtarını kullanabilirsiniz.
🅛 – Liskov Yerine Koyma İlkesi: İşaretçileri Kullanırken Dikkatli Olun 🔄
Matematiksel terimler bir yana, bu ilke sözleşme mirasının düzenini koruma ile ilgilidir. Solidity’de bu oldukça kolay! Bir çocuk işlevine farklı argümanlar verirseniz, derleyici sizi uyarır. İşleri tutarlı tutun ve birçok sıkıntıdan kaçının.
🅘 – Arayüz Ayrıştırma İlkesi: Kullanılmayan Arayüzlere Bağımlı Olma 🧳
Solidity’nin arayüzleri olduğunu ve Arayüz Ayrıştırma İlkesinin bu paradigma ile uyumlu olduğunu unutmayın. Bir arayüz, yalnızca uygulanması gereken yöntemleri içermelidir. İlgili bir sözleşme uygularken, ihtiyaca göre farklı arayüzlerden kalıtım yapabilirsiniz.
🅓 – Bağımlılık Tersine Çevirme İlkesi: Düzeneğinizi Değiştirin! 🔄
Bağımlılık Tersine Çevirme İlkesi ile masayı ters çevirin. Akıllı sözleşmelerde esneklik için soyutlamaları tanıtırsınız. Örneğin, Test sözleşmesindeki doSomething işleminin bir jeton göndermesi gerekiyordu. IToken arayüzüne dayalı olarak, işlevi transfer işlevleri ile açıklayan iki sözleşme tanımlanmıştır, biri bir değeri transfer ederken diğeri belirli bir adresten transfer eder. İki sözleşmede de transfer işlevi aynı argümanları aldığı için, Test sözleşmesinden işlevi çağırırken TokenTransfer ve TokenTransferFrom sözleşmelerinden hangi uygulamayı seçeceğinizi seçebilirsiniz.
Sonuç olarak, bu öğretici örnekleri inceledikçe SOLID ilkelerinin aslında karmaşık olmadığı ortaya çıktı. Aslında birçok geliştirici günlük çalışmalarında SOLID ilkelerini kullanır. Umarız bu konuyu eksiksiz bir şekilde ele almışızdır!
