Java'da, KATI ilkeler yazılım yapısı tasarımına uygulanan nesne yönelimli bir yaklaşımdır. Tarafından kavramsallaştırılmıştır Robert C.Martin (Bob Amca olarak da bilinir). Bu beş ilke, nesne yönelimli programlama dünyasını değiştirdi ve aynı zamanda yazılım yazma biçimini de değiştirdi. Ayrıca yazılımın modüler olmasını, anlaşılmasının, hata ayıklamasının ve yeniden düzenlemenin kolay olmasını sağlar. Bu bölümde tartışacağız Java'da SOLID ilkeleri doğru örnekle .

SOLID kelimesinin kısaltması:

• Tek Sorumluluk İlkesi (SRP)
• Açık-Kapalı Prensibi (OCP)
• Liskov İkame Prensibi (LSP)
• Arayüz Ayrıştırma Prensibi (ISP)
• Bağımlılığı Ters Çevirme İlkesi (DIP)

İlkeleri tek tek detaylı olarak açıklayalım.

Tek Sorumluluk Prensibi

Tek sorumluluk ilkesi şunu belirtir: her Java sınıfı tek bir işlevi yerine getirmelidir . Tek bir sınıfta birden fazla işlevin uygulanması, kodun karıştırılması ve herhangi bir değişiklik yapılması gerekiyorsa tüm sınıfı etkileyebilir. Kodu kesinleştirir ve kodun bakımı kolaylıkla yapılabilir. Tek sorumluluk ilkesini bir örnek üzerinden anlayalım.

Sanmak, Öğrenci üç yönteme sahip bir sınıftır yani printDetails(), hesaplaYüzde(), Ve addStudent(). Bu nedenle Öğrenci sınıfının, öğrencilerin ayrıntılarını yazdırmak, yüzdeleri hesaplamak ve veritabanını oluşturmak için üç sorumluluğu vardır. Tek sorumluluk ilkesini kullanarak, ilkenin amacını gerçekleştirmek için bu işlevleri üç ayrı sınıfa ayırabiliriz.

Öğrenci.java

dize.format

 public class Student { public void printDetails(); { //functionality of the method } pubic void calculatePercentage(); { //functionality of the method } public void addStudent(); { //functionality of the method } } 

Yukarıdaki kod parçacığı tek sorumluluk ilkesini ihlal ediyor. İlkenin amacına ulaşmak için yalnızca tek bir işlevi yerine getiren ayrı bir sınıf uygulamalıyız.

Öğrenci.java

 public class Student { public void addStudent(); { //functionality of the method } } 

PrintStudentDetails.java

 public class PrintStudentDetails { public void printDetails(); { //functionality of the method } } 

Yüzde.java

kar vs buz

 public class Percentage { public void calculatePercentage(); { //functionality of the method } } 

Böylece işlevselliği üç ayrı sınıfa ayırarak tek sorumluluk ilkesi hedefine ulaştık.

Açık-Kapalı Prensibi

Uygulama veya modül, yöntemleri, işlevleri, değişkenleri vb. içerir. Açık-kapalı prensibi, yeni gereksinimlere göre olduğunu belirtir. Modül genişletmeye açık, değişiklik yapmaya kapalı olmalıdır. Uzantı, modüle yeni işlevler uygulamamıza olanak tanır. Bir örnek üzerinden prensibi anlayalım.

Sanmak, Araç Bilgileri bir sınıftır ve yöntemi vardır Araç numarası() bu araç numarasını döndürür.

AraçBilgisi.java

 public class VehicleInfo { public double vehicleNumber(Vehicle vcl) { if (vcl instanceof Car) { return vcl.getNumber(); if (vcl instanceof Bike) { return vcl.getNumber(); } } 

Truck adında başka bir alt sınıf eklemek istiyorsak, basitçe açık-kapalı prensibini ihlal eden bir if ifadesi daha ekliyoruz. Alt sınıfı eklemenin ve ilke hedefine ulaşmanın tek yolu, Araç numarası() Aşağıda gösterdiğimiz gibi bir yöntem var.

AraçBilgisi.java

 public class VehicleInfo { public double vehicleNumber() { //functionality } } public class Car extends VehicleInfo { public double vehicleNumber() { return this.getValue(); } public class Car extends Truck { public double vehicleNumber() { return this.getValue(); } 

Benzer şekilde araç sınıfından uzanan başka bir alt sınıf yaparak daha fazla araç ekleyebiliriz. yaklaşım mevcut uygulamayı etkilemeyecektir.

Liskov Değiştirme Prensibi

Liskov İkame Prensibi (LSP), tarafından tanıtıldı Barbara Liskov . Bu, mirasa öyle bir şekilde uygulanır ki, Türetilmiş sınıflar, temel sınıflarının tamamen yerine geçebilmelidir . Başka bir deyişle, eğer A sınıfı, B sınıfının bir alt türü ise, o zaman programın davranışını kesintiye uğratmadan B'yi A ile değiştirebilmeliyiz.

Aç-kapa ilkesini genişletir ve ayrıca bir üst sınıfın ve onun alt türlerinin davranışlarına odaklanır. Aksini gerektirecek güçlü bir nedenimiz olmadıkça, sınıfları mülkü koruyacak şekilde tasarlamalıyız. Bir örnek üzerinden prensibi anlayalım.

Öğrenci.java

Java dizesinin uzunluğu

 public class Student { private double height; private double weight; public void setHeight(double h) { height = h; } public void setWeight(double w) { weight= w; } ... } public class StudentBMI extends Student { public void setHeight(double h) { super.setHeight(h); super.setWeight(w); } public void setWeight(double h) { super.setHeight(h); super.setWeight(w); } } 

Yukarıdaki sınıflar Liskov ikame ilkesini ihlal etmiştir çünkü ÖğrenciBMI sınıfının boy ve kilonun aynı olması gereken ekstra kısıtlamaları vardır. Bu nedenle, Öğrenci sınıfı (temel sınıf), ÖğrenciBMI sınıfı (türetilmiş sınıf) ile değiştirilemez.

Bu nedenle, Öğrenci sınıfının ÖğrenciBMI sınıfıyla değiştirilmesi beklenmeyen davranışlarla sonuçlanabilir.

Arayüz Ayırma Prensibi

Prensip, daha büyük arayüzlerin daha küçük arayüzlere bölündüğünü belirtir. Çünkü uygulama sınıfları yalnızca gerekli olan yöntemleri kullanır. Danışanı kullanmak istemediği yöntemleri kullanmaya zorlamamalıyız.

Arayüz ayırma ilkesinin amacı tek sorumluluk ilkesine benzer. Bir örnek üzerinden prensibi anlayalım.

Diyelim ki adında bir arayüz oluşturduk. Dönüştürmek üç yönteme sahip olmak intToDouble(), intToChar(), Ve charToString() .

 public interface Conversion { public void intToDouble(); public void intToChar(); public void charToString(); } 

Yukarıdaki arayüzün üç yöntemi vardır. Yalnızca intToChar() yöntemini kullanmak istiyorsak, tek yöntemi uygulama seçeneğimiz yoktur. Sorunun üstesinden gelmek için prensip, arayüzü üç ayrı parçaya ayırmamıza izin veriyor.

 public interface ConvertIntToDouble { public void intToDouble(); } public interface ConvertIntToChar { public void intToChar(); } public interface ConvertCharToString { public void charToString(); } 

Artık yalnızca gerekli olan yöntemi kullanabiliriz. Diyelim ki tamsayıyı double'a ve karakteri string'e dönüştürmek istiyoruz, o zaman sadece yöntemleri kullanacağız. intToDouble() Ve charToString().

 public class DataTypeConversion implements ConvertIntToDouble, ConvertCharToString { public void intToDouble() { //conversion logic } public void charToString() { //conversion logic } } 

Bağımlılığı Ters Çevirme Prensibi

İlke, somut uygulamalar yerine soyutlamayı (soyut sınıflar ve arayüzler) kullanmamız gerektiğini belirtir. Yüksek seviyeli modüller düşük seviyeli modüle bağlı olmamalıdır ancak her ikisi de soyutlamaya bağlı olmalıdır. Çünkü soyutlama ayrıntıya değil, ayrıntı soyutlamaya bağlıdır. Yazılımı ayrıştırır. Bir örnek üzerinden prensibi anlayalım.

 public class WindowsMachine { //functionality } 

Windows'ta çalışacak klavyemiz ve faremiz yoksa buna değer. Bu sorunu çözmek için sınıfın bir yapıcısını oluşturup klavye ve monitörün örneklerini ekliyoruz. Örnekleri ekledikten sonra sınıf aşağıdaki gibi görünür:

 public class WindowsMachine { public final keyboard; public final monitor; public WindowsMachine() { monitor = new monitor(); //instance of monitor class keyboard = new keyboard(); //instance of keyboard class } } 

Artık Windows makinemizde klavye ve fare yardımıyla çalışabiliriz. Ama hâlâ sorunla karşı karşıyayız. Çünkü new anahtar sözcüğünü kullanarak üç sınıfı birbirine sıkı sıkıya bağladık. Sınıf Windows makinesini test etmek zordur.

Kodu gevşek bir şekilde bağlamak için, Klavye arayüzünü ve bu anahtar kelimeyi kullanarak WindowsMachine'i klavyeden ayırıyoruz.

Klavye.java

java swing eğitimi

 public interface Keyboard { //functionality } 

WindowsMachine.java

 public class WindowsMachine { private final Keyboard keyboard; private final Monitor monitor; public WindowsMachine(Keyboard keyboard, Monitor monitor) { this.keyboard = keyboard; this.monitor = monitor; } } 

Yukarıdaki kodda, WindowsMachine sınıfına klavye bağımlılığı eklemek için bağımlılık enjeksiyonunu kullandık. Bu nedenle sınıfları ayırdık.

Neden SOLID ilkelerini kullanmalıyız?

• Bağımlılıkları azaltır, böylece bir kod bloğu diğer kod bloklarını etkilemeden değiştirilebilir.
• Tasarımı kolaylaştırmayı, anlaşılır kılmayı amaçlayan ilkeler.
• İlkelerin kullanılmasıyla sistem bakımı yapılabilir, test edilebilir, ölçeklenebilir ve yeniden kullanılabilir hale gelir.
• Yazılımın kötü tasarımını önler.

Bir dahaki sefere yazılım tasarlarken bu beş prensibi aklınızda bulundurun. Bu ilkeleri uygulayarak kod çok daha açık, test edilebilir ve harcanabilir olacaktır.