SOLID Prensipleri / SOLID Principles
Merhabalaaar :)) Uzun zamandır yazmadığım blog yazılarıma SOLID tasarım prensipleri konusuyla tekrardan giriş yapıyorum :))
Bu yazının sonunda amacım sizlere SOLID tasarım prensipleri hakkında bilgi verebilmek, umarım başarabilirim. Şimdiden keyifli okumalar 🙂
Konuya direk Solid prensiplerinden girmeden önce gelin birlikte tasarım prensibi ne demek ilk ona bakalım…
Geliştirdiğimiz nesneye dayalı yazılımlarımız aslında çok farkında olmasakta oldukça karmaşık mimari tasarımlardan oluşur. Ve bizim bu karmaşık yapıları projelerimizde önemi konulardan biri olan esneklik konusunda sorunlar yaşamamamız için en aza indirmemiz gerekir. İşte SOLID bu esnek yapıları oluşturmamıza yarayan temel prensiptir.
SOLID yazılım prensipleri; geliştirilen yazılımın esnek, yeniden kullanılabilir, sürdürülebilir ve anlaşılır olmasını sağlayan, kod tekrarını önleyen prensipler bütünüdür.
Ve amaçlarını kısaca
- Yeni gereksinimlere karşın kodun üzerinde en az değişimi sağlaması,
- Yazılan kodu okuyan her kişi tarafından yeterince anlaşılır kılmak,
- Temiz kod yazmayı sağlamak ve gereksiz, karmaşık kodlamadan kaçınmak,
- Kod üzerinde sürekli düzeltme hatta yeniden yazma gibi sorunların yol açtığı zaman kaybını da minimuma indirmek,
şeklinde sıralayabiliriz.
Şimdi gelin SOLID’in ayrıntılarına inelim ve her harfinin ne anlama geldiğini inceleyelim…
S — Single-Responsibility Principle (Tek Bir Sorumluluğa Sahip Olma)
Bu prensipte savunulan görüş her sınıfın, nesnenin yada metodun ancak tek bir sorumluluğu taşıması gerektiğidir. Yani bir sorumluluk sadece kendi işini yapmalıdır. Bir metot hem ekrana çıktı verirken hem hesaplama, hem de raporlama gibi birden çok görevi tek metot ismi içerisinde yerine getirmemelidir.
Kohezyon olgusuyla yani bir sınıftaki tanımlı üyelerin birbirlerine mantıksal ilişkilenmesi biçiminde tanımlanabilmesi olgusuyla ilişkilidir. Düşünüldüğünde her sorumluluğu her görevi ayırmak zor gibi görünür ancak yazdığımız kodumuzda bunu yapabilirsek ileride olacak olan herhangi bir değişiklik için sadece bu değişikliğin olacağı görevi değiştirmek yeterli olacaktır. Böylelikle hem genel yapıyı bozmamış olur hem de sadece tek bir yerdeki değişiklikle problemi halledip zamandan da kazanmış oluruz.
O — Open-Closed Principle (Açık-Kapalı Prensibi)
Bu prensip ise programı geliştirmek, programa yeni bir davranış biçimi eklemek anlamına gelmektedir. OCP ye göre sınıflarımızın geliştirmelere açık yani programı oluşturan modüller yeni davranış biçimlerini sergileyecek şekilde genişletilebilmeli ancak değişikliklere kapalı olmalıdır.
OOP mantığının bu temeli bize Get/Set, Private ve Abstract gibi kullanımlarla bu prensibi yerine getirmemizi sağlar. Sınıfımız kendi özelliklerini net değişikliklerden korurken aynı zamanda geliştirmelere ve yeni eklemelere açık olmalıdır. Böylelikle sınıflarımızı hem koruyup hem de geliştirebilir, kontrolü programlama mantığının ötesinde elimizde tutmaya devam edebiliriz.
L- Liskov Substitution Principle (İkame Edilebilirlik)
Bu prensibimizde ise sınıflar arası ilişkilerin düzenlenmesinden bahsedilen bir durum söz konusudur. Yani Kodlarımızda herhangi bir değişiklik yapmaya gerek duymadan alt sınıfları, türedikleri(üst) sınıfların yerine kullanabilmeliyiz.
Arabaya klima tuşu koyup onu işlevsiz bırakmak, bu prensibe tam anlamıyla terstir.
Dummy code dediğimiz de tam olarak budur. Türetilen sınıfların, türeyen sınıftaki işlevselliği tam olarak yerine getirdiğinden emin olmalıyız.
I- Interface Segregation Principle (Arayüz Ayırma İlkesi)
Prensip interface yapısını doğru bir şekilde kullanmayı sağlar. Yani gereksiz interface kullanımı ve gereksiz olanları kullanmaya zorlamaya çalışılmamalıdır. Eğer bir interface oluşturulduysa belirli bir amacı olmalı ve o amacı yerine getirebilmelidir. Sonuç olarak, bir sınıfın kullanmadığı method ve özellikler programın içeriğine alınmamış olur.
Başka bir ifadeyle birbiriyle ilişkili olmayan birçok metodu ihtiva eden büyük bir interface sınıf yerine, birbiriyle ilişkili (cohesive) metotların yer aldığı birden fazla interface sınıfı daha makbuldür.
Sorumlulukların hepsini tek bir arayüze toplamak yerine daha özelleştirilmiş birden fazla arayüz oluşturmalıyız.
D- Dependency Inversion Principle (Bağımlılığı Tersine Çevirme)
Bu prensipte sınıflar arası bağımlılıklar olabildiğince az olmalıdır özellikle üst seviye sınıflar alt seviye sınıflara bağımlı olmamalıdır.
Bağımlılık özelliği OOP mantığında işleyen diller için kullanımı ve kodlamayı oldukça kolaylaştıran özelliklerden biridir.
Nesneleri, sınıfları ve metotları gerektiği şekilde bağlamak ve görevleri istenilen yerde tekrar etmeden tekrar kullanabilmek doğru bir şekilde olduğunda büyük bir kolaylık sağlar. Ancak bağımlılıklarda geri kalan her özellik gibi doğru bir şekilde kullanılmalı ve çağırılmalıdır. Alt seviyede olan herhangi bir işlemin değişikliğe uğrayabilecek olması, kendisine bağlı olan tüm düzeni bozabilir.
Bağımlılıkları birbirine sıkı sıkıya bağlanmış olan metotlarda tekrar kullanılabilirlik imkansız hale gelir ve bu doğru kod yazmada isteyebileceğimiz şeylerden biri değildir.
Kısaca çok uzatmadan ve sıkmadan anlaşılır bir şekilde sizlere SOLID prensiplerini anlatmaya çalıştım :)) Umarım yazının en az bir cümlesi bile faydalı olur sizler için :))
Bir sonraki yazımda ise yazılım geliştirme modellerini anlatmayı düşünüyorum, beklemede kalınn :))
