Sık sık SOLID ilkelerini duymamış geliştiricilerle karşılaşıyorum (biz . — Transl.) veya nesne yönelimli programlamayı (OOP) veya bunları duymuşsunuzdur ancak pratikte kullanmayın. Bu makale, geliştiriciye günlük çalışmalarında yardımcı olan OOP ilkelerinin faydalarını açıklamaktadır. Bazıları iyi biliniyor, bazıları ise pek bilinmiyor, dolayısıyla makale hem yeni başlayanlar hem de deneyimli programcılar için faydalı olacaktır.
Hatırlatıyoruz: tüm Habr okuyucuları için - Habr promosyon kodunu kullanarak herhangi bir Skillbox kursuna kaydolurken 10 ruble indirim.
Skillbox şunları önerir: Eğitici çevrimiçi kurs .
KURU (Kendinizi Tekrar Etmeyin)
Oldukça basit bir prensip, özü isminden de anlaşılıyor: "Kendinizi tekrar etmeyin." Bir programcı için bu, yinelenen kodlardan kaçınma ihtiyacının yanı sıra çalışmalarında soyutlamayı kullanma fırsatı anlamına gelir.
Kodda tekrar eden iki bölüm varsa bunlar tek bir yöntemde birleştirilmelidir. Sabit kodlanmış bir değer birden fazla kullanılıyorsa, onu genel bir sabite dönüştürmek faydalı olacaktır.
OOP'un temel amacı olan kodu basitleştirmek ve bakımı kolaylaştırmak için bu gereklidir. Aynı kod hem OrderId hem de SSN ile doğrulamayı geçmeyeceğinden union'ı aşırı kullanmamalısınız.
Değişiklikleri Kapsülleme
Çoğu şirketin yazılım ürünleri sürekli olarak gelişmektedir. Bu da kodda değişiklik yapılması gerektiği, desteklenmesi gerektiği anlamına geliyor. Kapsülleme kullanarak hayatınızı kolaylaştırabilirsiniz. Bu, mevcut kod tabanınızı daha verimli bir şekilde test etmenize ve korumanıza olanak tanır. .
Java ile yazarsanız, o zaman .
Açık/kapalı prensibi
Bu ilke şu ifadeyi okuyarak kolayca hatırlanabilir: “Yazılım varlıkları (sınıflar, modüller, işlevler vb.) genişletmeye açık, değişiklik için kapalı olmalıdır.” Uygulamada bu, kaynak kodunu değiştirmeden davranışlarının değiştirilmesine izin verebilecekleri anlamına gelir.
Kaynak kodundaki değişiklikler kodun revizyonunu, birim testini ve diğer prosedürleri gerektirdiğinde bu prensip önemlidir. Açık/kapalı prensibini izleyen kod genişletildiğinde değişmez, dolayısıyla onunla ilgili çok daha az sorun olur.
İşte bu prensibi ihlal eden bir kod örneği.
İçinde bir şeyi değiştirmeniz gerekiyorsa, kodun istenen parçayla bağlantısı olan tüm bölümlerinin değiştirilmesi gerekeceğinden çok zaman alacaktır.
Bu arada açıklık-kapalılık SOLID'in ilkelerinden biridir.
Tek Sorumluluk İlkesi (SRP)
SOLID setinden bir başka prensip. “Sınıf değişikliğine neden olan tek bir neden vardır” diyor. Sınıf yalnızca bir problemi çözer. Birkaç yöntemi olabilir, ancak her biri yalnızca ortak bir sorunu çözmek için kullanılır. Tüm yöntemler ve özellikler yalnızca buna hizmet etmelidir.
Bu prensibin değeri, bireysel yazılım bileşeni ile kod arasındaki bağlantıyı gevşetmesidir. Bir sınıfa birden fazla işlevsellik eklerseniz, bu iki işlev arasında bir ilişki ortaya çıkarır. Yani birini değiştirirseniz, birinciye bağlı olan ikincinin de bozulma ihtimali yüksektir. Bu da tüm sorunları önceden tespit etmek için test döngülerinin artırılması anlamına geliyor.
Bağımlılık Tersine Çevirme İlkesi (DIP)
Yukarıda, AppManager'ın AppManager ile yakından bağlantılı olan EventLogWriter'a bağlı olduğu bir kod örneği bulunmaktadır. Bir bildirimi göstermek için push, SMS veya e-posta gibi farklı bir yola ihtiyacınız varsa AppManager sınıfını değiştirmeniz gerekir.
Sorun DIP kullanılarak çözülebilir. Bu nedenle AppManager yerine, çerçeve kullanılarak girilecek bir EventLogWriter talep ediyoruz.
DIP, bağımlılık modülünü değiştirerek bireysel modülleri başkalarıyla kolayca değiştirmeyi mümkün kılar. Bu, diğerlerini etkilemeden bir modülün değiştirilmesini mümkün kılar.
Miras yerine kompozisyon
Kodu yeniden kullanmanın iki ana yolu vardır: kalıtım ve kompozisyon; her ikisinin de kendi avantajları ve dezavantajları vardır. Genellikle ikincisi daha esnek olduğu için tercih edilir.
Kompozisyon size, bir sınıfın özelliklerini ayarlayarak çalışma zamanında sınıfın davranışını değiştirme yeteneği verir. Arayüzleri uygularken daha esnek bir uygulama sağlayan polimorfizm kullanılır.
Joshua Bloch'un Etkili Java'sı bile kalıtım yerine kompozisyonun seçilmesini tavsiye ediyor.
Barbara Liskov İkame Prensibi (LSP)
SOLID araç setinden bir başka prensip. Alt türlerin üst türün yerine geçebilmesi gerektiğini belirtir. Yani bir üst sınıfla çalışan yöntem ve fonksiyonlar, alt sınıflarıyla da sorunsuz çalışabilmelidir.
LSP hem tek sorumluluk ilkesi hem de paylaşılan sorumluluk ilkesiyle ilişkilidir. Bir sınıf, bir alt sınıftan daha fazla işlevsellik sağlıyorsa, alt sınıf, bu ilkeyi ihlal ederek bazı işlevleri desteklemeyecektir.
Burada LSP ile çelişen bir kod parçası var.
Area(Rectangle r) yöntemi bir Dikdörtgenin alanını hesaplar. Program, Square'i çalıştırdıktan sonra çökecek çünkü Square burada bir Dikdörtgen değil. LSP ilkesine göre, temel sınıflara referanslar kullanan işlevler, türetilmiş sınıfların nesnelerini ek talimatlar olmadan kullanabilmelidir.
Bir alt türün spesifik bir tanımı olan bu prensip, Barbara Liskov tarafından 1987'de "Veri Soyutlaması ve Hiyerarşi" başlıklı bir konferansın açılış konuşmasında önerildi, dolayısıyla adı da buradan geliyor.
Arayüz Ayırma İlkesi (ISP)
Başka bir KATI prensip. Buna göre kullanılmayan bir arayüzün hayata geçirilmemesi gerekiyor. Bu prensibe uymak, işletim mantığında değişiklik yapıldığında sistemin esnek kalmasına ve yeniden düzenlemeye uygun kalmasına yardımcı olur.
Çoğu zaman bu durum, arayüz aynı anda birden fazla işlev içerdiğinde ve müşterinin bunlardan yalnızca birine ihtiyacı olduğunda ortaya çıkar.
Arayüz yazmak zor bir iş olduğundan, iş bittikten sonra hiçbir şeyi bozmadan değiştirmek zor olacaktır.
Java'daki ISP ilkesinin avantajı, önce tüm yöntemlerin uygulanmasının gerekmesi ve ancak o zaman sınıflar tarafından kullanılabilmesidir. Bu nedenle prensip, yöntem sayısını azaltmayı mümkün kılar.
Arayüz için programlama, uygulama için değil
Burada her şey başlıktan açıkça anlaşılıyor. Bu prensibin uygulanması, arayüzün herhangi bir yeni uygulamasıyla çalışabilecek esnek kodun oluşturulmasına yol açar.
Değişkenler için arayüz tipini, dönüş tiplerini veya yöntem argüman tipini kullanmalısınız. Bir örnek, SubClass yerine SuperClass'ı kullanmaktır.
Şöyle ki:
Liste numaraları= getNumbers();
Ve hayır:
ArrayList numaraları = getNumbers();
Yukarıda tartışılanların pratik bir uygulamasıdır.
Yetkilendirme ilkesi
Yaygın bir örnek, Java'daki equals() ve hashCode() yöntemleridir. İki nesneyi karşılaştırmak gerektiğinde, bu eylem istemci sınıfı yerine karşılık gelen sınıfa devredilir.
İlkenin avantajı, kodun kopyalanmaması ve davranışı değiştirmenin nispeten basit olmasıdır. Bu aynı zamanda etkinlik delegasyonu için de geçerlidir.
Tüm bu ilkeler, yüksek uyum ve düşük bağlantı ile daha esnek, güzel ve güvenilir kod yazmanıza olanak tanır. Elbette teori iyidir, ancak bir geliştiricinin edindiği bilgiyi gerçekten kullanabilmesi için pratiğe ihtiyaç vardır. OOP ilkelerine hakim olduktan sonraki adımınız, yaygın yazılım geliştirme sorunlarını çözmeye yönelik tasarım modellerini öğrenmek olabilir.
Skillbox şunları önerir:
- pratik kurs .
- Uygulamalı çevrimiçi kurs .
- İki yıllık uygulamalı kurs .
Kaynak: habr.com