Skip to content

Latest commit

 

History

History
41 lines (22 loc) · 3.57 KB

README.md

File metadata and controls

41 lines (22 loc) · 3.57 KB

SOLID Princibles

Bu projede SOLID prensipleri örnekler ile anlatılmıştır. Prensiplerin ayrıntılı açıklamalarına aşağıda vereceğim gitbook hesabımdan ulaşabilrsiniz.

Lab1 S— Single-responsibility "Her sınıfın veya metodun tek bir sorumluluğu olmalı "

Lab2 O — Open-closed principle " Sınıflar değişikliğe kapalı ancak gelişime açık olmalıdır"

Lab3 L — Liskov substitution principle "Liskov prensibi "

Lab4 I — Interface segregation principle " Ara yüzler optimum şekilde dizayn edilmelidir "

[Lab5]D — Dependency Inversion Principle " Katmanlı mimarilerde üst seviye modüller alt seviyedeki modüllere doğrudan bağımlı olmamalıdır "

SOLİD LOGO

Single-responsibility principle ;

Bu ilke "bir sınıfın değişmesi için yalnız bir nedeninin olması gerektiğini savunur" yani bir sınıfın az ve öz sorumluluğu olmalı karmaşık yapılardan her zaman kaçınılmalıdır. Bir class oluşturulurken sürekli " bu sorumluluğu buraya vermeli miyim ?" sorusu sorulmalıdır.

Open-closed principle;

Varlıklar(Entities) genişlemeye açık olmalı ancak değişikliğe kapalı olmalıdır. Zaten OOP genişlemeyi prensip edinilerek desteklenmiştir. Lakin bu değişikm esnasında yaratılan sınıflarda modifikasyona gerek kalmayacak şekilde mimariyi kurmamız gerekir. Bir sınıfın davraşınını değiştirmeden geliştirmemiz gerekir.

Liskov substitution principle;

Alt sınıflar miras aldığı üst sınıfın bütün özelliklerini kullanmalı, alt sınıflarda oluşturulan nesneler üst sınıfların nesneleriyle yer değiştirdiklerinde aynı davranışı göstermeli ve herhangi bir kullanılmayan özellik olmamalıdır. Bu ilkeye göre "türetilmiş veya alt sınıflar, temel veya ebeveyn sınıflarının yerine geçebilir."

Interface segregation principle;

INTERFACE LOGO

Bu prensip SOLİD'deki sınıflar yerine arayüzler interfaceler için gerçerli olan ilk prensiptir ve SRP-LSP prensiplerine benzemektedir. Bu ilke özet olarak şunu söyler "Hiçbir concrete sınıf kendisi ile ilgisi olmayan bir özelliği içeren arayüzden implemente edilmemelidir ". Burada asıl amacımız interfacelerin şişirilmesinden kaçınmamız olmasıdır.

Dependency Inversion Principle;

DIP LOGO

Bu ilkede yüksek seviyeli sınıflar düşük seviyeli modüllere bağlı olmamalıdır. Modül ve sınıflar soyutlamalara bağlı olmalıdır. Soyutlamalar detaylara bağlı olamamalıdır. Detaylar soyutlara bağlı olmalıdır. Bu detaydan kasıt sınıflara yüklenen görevlerdir. Bu ilkenin en can alıcı noktası bir sınıfın eylem yürütmek için kullandığı araçlar ile birleştirilmemesi gerektiğidir.

  • Dependencey Injection Methods açıklamaları da GitBook sayfamda bulunmaktadır.

Ayrıntılı açıklamalarıma GitBook hesabımdan ulaşabilirisniz. https://ridvanorun.gitbook.io/solid/