SOLİD Prensipleri ve Örnekleri

ilyasaglar tarafından tarihinde yayınlandı

SOLID Prensipleri: 2000 Yıllarında Robert Cecil Martin kod karmaşıklığına, tekrar eden kodlara ve bir yazılımın kişiden bağımsız ilerlemesine yönelik bir takım çalışmalara imza atıyor. Bu çalışmalardan SOLID yani nesne yönelimli programlama için 5 temel prensip ortaya çıkmıştır.

Bu prensipler şunlardır;

  1. Single Responsibility Principle

  2. Open/Closed Principle

  3. Liskov ‘s Substitution Principle

  4. Interface Segregation Principle

  5. Dependency Inversion Principle

 

Single Responsibility Principle (Tekil Sorumluluk Prensibi)

“Bir sınıfın sadece bir sorumluluğu olmalı” 

Her bir method sadece kendisine verilen işi yapar aynı anda birden fazla modeli update etmez. Bu isterseniz sınıf olur, isterseniz interface ve onun implementasyonu olur isterseniz de method olur.

Örnek Kod:
Person.java

public class Person

{

private Long personId;

private String firstName;

private String lastName;

private String age;

private List<Account> accounts;

}

 

Account.java

public class Account

{

private Long guid;

private String accountNumber;

private String accountName;

private String status;

private String type;

}

 

Verilen örnekte, iki sınıf Kişi ve Hesap var. Her ikisinin de kendi özel bilgilerini saklama sorumluluğu vardır. Person.java’nın bilgilerini değiştirmek istiyorsak, Account.java sınıfında değişiklik yapmak gerekmez.

 

 

Open/Closed (Açık/Kapalı) Prensibi

“Yazılım bileşenleri geliştirmeye açık, ancak değişiklik için kapalı olmalıdır”

Oluşturduğunuz nesneler zaman içerisinde ek özellikler kazanabilir genişlemeye açık olurlar bu normal bir yazılım projesinde kaçınılmaz bir durumdur. Ama temel nesne değişime kapalı tutulmalıdır.

Örnek Kod:

public class HelloWorldAction extends Action

{

@Override

public ActionForward execute(ActionMapping mapping,ActionForm form, HttpServletRequest request,  HttpServletResponse response) throws Exception

{

 

//Process the request

 

}

}

Sınıflar istek işleme mantığını geçersiz kılmak üzere genişletilir.

Liskov’un Yerine Geçme Prensibi(Liskov Substitution Principle – LSP) 

“Kalıtım alarak türeyen sınıfların kalıtım aldıkları nesnenin tüm özelliklerini kullanmalı”

Eğer nesne kalıtım aldığı objenin tüm özelliklerini kullanmaz ise ortaya gereksiz kod yığınları oluşur ve sonrasında kalıtım alınan objenin diğerlerinden ayrılması için yeni kod ihtiyaç olur ve bu durum son derece verimsiz bir yazılıma sebep olur.

Örnek Kod:
public class IsbnEditor extends PropertyEditorSupport {
    @Override
    public void setAsText(String text) throws IllegalArgumentException {
        if (StringUtils.hasText(text)) {
            setValue(new Isbn(text.trim()));
        } else {
            setValue(null);
        }
    }
 
    @Override
    public String getAsText() {
        Isbn isbn = (Isbn) getValue();
        if (isbn != null) {
            return isbn.getIsbn();
        } else {
            return "";
        }
    }
}

Her kitabın her zaman sabit görüntüleme biçiminde bir ISBN numarası vardır. Veritabanında ve kullanıcı arayüzünde ISBN’nin ayrı temsilleri olabilir.

 

Interface Segregation Principle (Arayüz Ayrımı)

“Müşteriler kullanmayacakları gereksiz yöntemleri uygulamaya zorlanmamalıdır”

Arayüz ayırım prensibi, bir arayüze gerektiğinden fazla yetenek eklenmemesi gerektiğini söyler. Nesnelerin ihtiyaç duymadıkları fonksiyonların Interface’lerinden mümkün olduğunca ayrıştırılmasıdır.

 

public class MouseMotionListenerImpl implements MouseMotionListener
{
    @Override
    public void mouseDragged(MouseEvent e) {
        //handler code
    }
    @Override
    public void mouseMoved(MouseEvent e) {
        //handler code
    }
}

Her işlem için farklı dinleyici sınıfları var, sadece olaylar için işleyiciler yazmamız gerekiyor.  Her zaman, herhangi bir olayı ele almak, sadece ilgili dinleyiciyi bulur ve ilgili işlemler uygulanır.

 

Dependency Inversion Principle (Bağımlılık Değişimi)

Bağımlılığın ters çevirilmesi ilkesine göre üst seviye sınıflar, modüller, methodlar vs. alt seviyeli sınıflara bağımlı olmamalıdır. Alt sınıflarda yapılan değişiklikler üst sınıfları etkilememelidir. Yüksek seviyeli sınıflar, düşük seviyeli sınıflara bağlı olmamalı, her ikisi de soyut kavramlara bağlı olmalıdır.

 

 

 

 

Kaynak: https://howtodoinjava.com/best-practices/5-class-design-principles-solid-in-java/

Kategoriler: Genel
Etiketler:

0 yorum

Bir cevap yazın

E-posta hesabınız yayımlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir

Benzer yazılar

Elasticsearch verilerinin java uygulamasında göstermek
Genel

Elasticsearch Loglarını Uygulamanızda Göstermek

Uygulamanız için tuttugunuz logları projenizin içerisinde göstermenize saglayan adımları anlatmaya çalışacagım. Logları yazmak için Log4j & RabbitMq kullanımına yönelik ayarları şuradan bulunan yazıdan okuyabilirsiniz. ilk olarak pom.xml dosyasımıza bunu ekliyoruz.  Elascticsearch ortamında Loglarımız aşagıdaki gibi Devamı…

spring mvc crud örnek proje uygulaması
Genel

Spring MVC CRUD projesi

Bu projede Spring, Hibernate gibi teknolojileri kullanarak MVC’ye uygun olacak şekilde bir proje geliştirdim. Proje’de ekleme, silme, güncelleme, listeleme, arama yapma gibi özellikler bulunuyor. Projeyi incelyerek temel mvc yapısını ögrenebilir.  Hibernate ile yaptıgım ekleme, silme, Devamı…

java swing ile menu frame image
Genel

Java Swing ve Oracle Database ile örnek proje uygulaması

Java Swing GUİ widget araçlarını kullanarak geliştirdiğimiz ve Oracle Database ile verileri depoladıgımız örnek bir uygulama geliştirdik. Uygulama da OOP ile oluşturduğumuz mimar’ye uygun olarak birçok fonksiyon ve özellik ekledik. Bu uygulama OOP kullanımı,  Java Devamı…