Nesneye Yönelik Tasarım İlkeleri, OOP programlamanın özüdür, ancak Java programcılarının çoğunun Singleton modeli, Dekoratör modeli veya Gözlemci modeli gibi tasarım modellerini takip ettiğini ve Nesneye yönelik analiz ve tasarımı öğrenmeye yeterince dikkat etmediğini gördüm . Soyutlama , Kapsülleme, Polimorfizm ve Kalıtım gibi Nesne yönelimli programlamanın temellerini öğrenmek çok önemlidir . Ancak aynı zamanda nesne yönelimli tasarım ilkelerini bilmek de aynı derecede önemlidir. Gelecekte test edilmesi, hata ayıklanması ve bakımı kolay olacak temiz ve modüler bir tasarım oluşturmanıza yardımcı olacaklardır.
Bu OOP ve SOLID tasarım ilkelerini hiç duymamış ya da belirli bir tasarım ilkesinin ne gibi faydalar sağladığını ve bu tasarım ilkelerinin kodlamada nasıl uygulanacağını bilmeyen, çeşitli deneyim düzeyindeki Java programcılarını ve geliştiricilerini düzenli olarak gördüm.
Ben de üzerime düşeni yapmak için tüm önemli nesne yönelimli tasarım ilkelerini not aldım ve hızlı başvuru için buraya koydum. Bunlar en azından size ne oldukları ve ne gibi faydalar sundukları hakkında bir fikir verecektir.
Yazıyı kısa tutmak için örnekler vermedim ama blogumda bu tasarım ilkelerinin bir çok örneğini bulabilirsiniz; sadece sayfanın üst kısmındaki arama çubuğunu kullanın.
Bir tasarım ilkesini anlayamıyorsanız, birden fazla örnek yapmaya çalışmalısınız çünkü bazen başka bir örneğe veya yazara daha iyi bağlanıyoruz, ancak bu tasarım ilkelerini anlamalı ve kodunuzda nasıl kullanacağınızı öğrenmelisiniz.
Yapabileceğiniz başka bir şey de SOLID Prensipleri: Yazılım Mimarisi ve Tasarımına Giriş gibi kapsamlı bir nesne yönelimli tasarım kursuna katılmaktır. Udemy’de Sujith George tarafından. Bu ilkeleri anlamamda ve uygulamada bana çok yardımcı oldu.
Herhangi bir tasarım ilkesini veya desenini öğrenmenin en iyi yolu, gerçek dünyadan bir örnek ve bu tasarım ilkesini ihlal etmenin sonuçlarını anlamak olsa da, bu makalenin konusu, Java Programcıları için Nesne Yönelimli tasarım ilkelerini tanıtmaktır. veya öğrenme aşamasında.
Şahsen bu OOP ve SOLID tasarım ilkelerinin her birinin onları net bir şekilde açıklamak için bir makaleye ihtiyacı olduğunu düşünüyorum ve bunu kesinlikle burada yapmaya çalışacağım, ancak şimdilik, kendinizi tasarım ilkesi kasabasında hızlı bir bisiklet yolculuğuna hazırlanın 🙂
1. DRY (Kendinizi tekrarlamayın)
İlk nesne yönelimli tasarım ilkemiz DRY’dir, adından da anlaşılacağı gibi DRY (kendinizi tekrar etmeyin) , yinelenen kod yazmayın, bunun yerine ortak şeyleri tek bir yerde soyutlamak için Soyutlamayı kullanın . İkiden fazla yerde bir kod bloğunuz varsa, onu ayrı bir yöntem haline getirmeyi düşünün veya birden fazla kez sabit kodlanmış bir değer kullanıyorsanız, bunları public final sabit yapın .
Bu Nesneye yönelik tasarım ilkesinin faydası bakımdadır. Kötüye kullanmamak önemlidir, çoğaltma kod için değil, işlevsellik içindir. Bu, OrderID ve SSN’yi doğrulamak için standart kod kullandıysanız , bunların aynı oldukları veya gelecekte aynı kalacakları anlamına gelmez.
İki farklı işlev veya şey için standart kod kullanarak, bunları sonsuza kadar sıkı bir şekilde birleştirirsiniz ve OrderId’niz biçimini değiştirdiğinde, SSN doğrulama kodunuz bozulur.
Bu nedenle, bu tür bağlantılara dikkat edin ve benzer kodu kullanan ancak ilgili olmayan hiçbir şeyi birleştirmeyin. Doğru kodu yazma ve bir sistem tasarlarken izlenecek en iyi uygulamalar hakkında daha fazla bilgi edinmek için Udemy’deki Java’da Yazılım Mimarisi ve Tasarım Modellerinin Temelleri kursuna da göz atabilirsiniz.
2. Değişenleri Kapsülleyin
Yazılım alanında sabit olan tek bir şey vardır, o da “Değiştir”dir. Bu nedenle, gelecekte değişmesini beklediğiniz veya şüphelendiğiniz kodu kapsülleyin. Bu OOP Tasarım ilkesinin yararı, uygun kapsüllenmiş kodu test etmenin ve sürdürmenin kolay olmasıdır.
Java’da kodlama yapıyorsanız, değişkenleri ve yöntemleri varsayılan olarak özel yapma ve özelden korumalı ve herkese açık değil gibi adım adım erişimi artırma ilkesini izleyin.
Java’daki tasarım modellerinin birçoğu Kapsülleme kullanır, Fabrika tasarım deseni , nesne oluşturma kodunu içine alan ve daha sonra mevcut kodu etkilemeden yeni bir ürünü tanıtma esnekliği sağlayan Kapsüllemenin bir örneğidir.
Btw, Java ve Nesne Yönelimli Programlamadaki tasarım kalıpları hakkında daha fazla bilgi edinmek istiyorsanız, bu Tasarım Modeli Kitaplığı kursu Pluralsight’ı kontrol etmelisiniz. Tasarım desenlerinin en iyi koleksiyonlarından biri ve bunların gerçek dünyada nasıl kullanılacağına dair tavsiyeler.
3. Açık Kapalı Tasarım İlkesi
Sınıflar, yöntemler veya işlevler, Uzatma için Açık (yeni işlev) ve değişiklik için Kapalı olmalıdır. Bu, birisinin zaten denenmiş ve test edilmiş kodu değiştirmesini engelleyen başka bir güzel SOLID tasarım ilkesidir.
İdeal olarak, yalnızca yeni işlevler ekliyorsanız, kodunuz test edilmelidir ve Açık Kapalı Tasarım ilkesinin amacı budur . Bu arada, Açık-Kapalı ilkesi, SOLID kısaltmasından “O” dur.
4.Single Responsibility Principle (SRP)
Tek Sorumluluk İlkesi, başka bir SOLID tasarım ilkesidir ve SOLID kısaltmasında “S”yi temsil eder. SRP’ye göre, bir sınıfın değişmesi için birden fazla neden olmamalıdır veya bir sınıf her zaman tek bir işlevi yerine getirmelidir.
Java’da bir Sınıfa birden fazla işlevsellik koyarsanız, iki işlevsellik arasında bağlantı sağlar ve bir özelliği değiştirseniz bile, üretimde herhangi bir sürprizden kaçınmak için başka bir test turu gerektiren birleştirilmiş işlevselliği bozma şansınız vardır. çevre.
Daha fazla gerçek dünyadan örnekler ve bu prensibe dayalı kalıplar hakkında bilgi edinmek için Udemy’deki SOLID Principles of Object-Oriented Design and Architecture kursunu da inceleyebilirsiniz.
5. Dependency Injection veya Tersine Çevirme ilkesi
Bağımlılık isteme; çerçeve tarafından size sağlanacaktır. Bu, Spring çerçevesinde çok iyi uygulandı , bu tasarım ilkesinin güzelliği , DI çerçevesi tarafından enjekte edilen herhangi bir sınıfın sahte nesneyle test edilmesinin kolay olması ve nesne oluşturma kodunun çerçeve içinde merkezileştirilmesi nedeniyle bakımının daha rahat olmasıdır. ve müşteri kodu bununla dolu değil.
AspectJ gibi bazı AOP (Aspect Oriented Programming) çerçevesinin yaptığı bayt kodu enstrümantasyonunu kullanmak veya tıpkı Spring’de kullanıldığı gibi proxy’leri kullanmak gibi Bağımlılık enjeksiyonunu uygulamanın birden çok yolu vardır . Bu SOLID tasarım ilkesi hakkında daha fazla bilgi edinmek için bu IOC ve DI tasarım modeli örneğine bakın . SOLID kısaltmasında “D”yi temsil eder.
6. Composition, Inheritance Tercih Edin
Mümkünse her zaman kalıtım yerine kompozisyonu tercih edin. Bazılarınız bunu tartışabilir, ancak Composition öğesinin Inheritance öğesinden çok daha esnek olduğunu buldum.
Kompozisyon, çalışma zamanında özelliği ayarlayarak ve bir sınıf oluşturmak için Arayüzleri kullanarak çalışma zamanında bir sınıfın davranışını değiştirmeye izin verir , herhangi bir zamanda daha iyi uygulama ile değiştirme esnekliği sağlayan polimorfizm kullanırız.
Klasik Etkili Java kitabı bile kalıtım yerine kompozisyonun tercih edilmesini önerir. Kodu ve işlevselliği yeniden kullanmak için Kompozisyonunuzun Kalıtımdan neden daha iyi olduğu hakkında daha fazla bilgi edinmek için buraya bakın.
7. Liskov Substitution İlkesi (LSP)
Liskov Değiştirme İlkesi’ne göre , Alt türler üst tür için ikame edilebilir olmalıdır, yani üst sınıf türünü kullanan yöntemler veya işlevler , alt sınıfın nesnesi ile herhangi bir sorun olmadan çalışabilmelidir”. LSP, Tek sorumluluk ilkesi ve InterfaceAyrımı İlkesi
ile yakından ilişkilidir . Bir sınıfın daha fazla işlevi varsa, alt sınıf bazı işlevleri desteklemeyebilir ve LSP’yi ihlal eder.
LSP SOLID tasarım ilkesini takip etmek için , türetilmiş sınıf veya alt sınıf, işlevselliği artırmalı, ancak azaltmamalıdır. LSP, SOLID kısaltmasında “L”yi temsil eder. Daha gerçek dünyadan bir örnekle ilgileniyorsanız, çoğul görüşle ilgili SOLID İlkeleri Nesneye Yönelik Tasarım kursu, başlamak için mükemmel bir kurstur.
Pluralsight üyeliğiniz yoksa, ön uç ve arka uç geliştirme, makine öğrenimi vb. gibi en son konulardaki 5000’den fazla çevrimiçi kursuna erişmenizi sağladığı için bir tane edinmenizi tavsiye ederim. Ayrıca etkileşimli içerir. testler, alıştırmalar ve en son sertifika materyalleri.
Daha çok Yazılım Geliştiricileri için Netflix’e benziyor ve Öğrenmek işimizin ayrılmaz bir parçası olduğundan, Pluralsight üyeliği rekabette öne geçmenin harika bir yoludur.
Ayrıca 10 günlük ücretsiz deneme sağlarlar.Bu, yalnızca bu kursa ücretsiz olarak erişmenin değil, aynı zamanda Pluralsight’a katılmadan önce kursların kalitesini kontrol etmenin de harika bir yoludur.
8. Interface İlkesi (ISP)
Arabirim Ayrımı İlkesi , bir istemcinin, bunu kullanmıyorsa bir arabirimi uygulamaması gerektiğini belirtir. Bu, çoğunlukla bir arabirim birden fazla işlevsellik içerdiğinde ve istemcinin yalnızca bir işlevselliğe ihtiyacı olduğunda ve başka bir işleve ihtiyaç duymadığında olur.
Arayüz tasarımı zor bir iştir çünkü arayüzünüzü bir kez serbest bıraktığınızda, tüm uygulamayı bozmadan değiştiremezsiniz.
Arayüz Ayrıştırma İlkesi (ISP)
Java’daki bu tasarım ilkesinin bir başka yararı, arabirimin, herhangi bir sınıf onu kullanmadan önce tüm yöntemleri uygulama dezavantajına sahip olmasıdır, bu nedenle tek işlevselliğe sahip olmak, uygulamak için daha az yöntem anlamına gelir. Kodlamada arayüzün faydasını göremiyorsanız, daha fazlasını öğrenmek için Java’da bir arayüzün gerçek kullanımı olan blog yazımı okumanızı öneririm.
9. Arayüz için Programlama değil uygulama
Uygulama için değil, her zaman arayüz için programlayın; bu , arayüzün herhangi bir yeni uygulamasıyla çalışabilen esnek koda yol açacaktır.
Bu nedenle, değişkenler üzerinde arayüz tipini, metot tiplerini veya Java’da metotların argüman tipini kullanın. Bu, Etkili Java ve Head First tasarım modeli
kitabı da dahil olmak üzere birçok Java kitabında tavsiye edilmiştir.
10. Yetkilendirme ilkeleri
Her şeyi kendi başınıza yapmayın, ilgili sınıfa devredin. Temsilci tasarım ilkesinin klasik örneği, Java’da equals() ve hashCode() yöntemidir . İki nesneyi eşitlik açısından karşılaştırmak için, bu kontrolü yapan Client sınıfı yerine sınıfın kendisinden bir karşılaştırma yapmasını istiyoruz.
Bu tasarım ilkesinin en önemli faydası, kodun tekrarlanmaması ve davranışın değiştirilmesinin oldukça kolay olmasıdır. Olay delegasyonu, bir olayın işleme için işleyicilere devredildiği bu ilkenin başka bir örneğidir.