Yazılım Tasarım Prensipleri

Hayatta başarılı olmak için nasıl ki bazı prensiplere sahip olmak gerekiyorsa, bana göre bir yazılım projesinin de bazı prensiplere dayalı olarak geliştirilmesi gerekiyor. Tabi söz konusu olan bir sektör ise her sektörde olduğu gibi yazılım sektöründe de bu prensiplerin belli standartlar kapsamında yapılması en doğal olanıdır. Bu yazının kapsamında daha önce araştırmış olduğum fakat unuttuğum bir konu olan yazılım tasarım prensipleri (SOLID) kavramına tekrardan bir göz atacağım ve notlarım arasına eklemiş olacağım.

İlk önce SOLID kelimesini oluşturan kavramları ve bunların kısa tanımlarını incelemek istiyorum. Sonrasında her bir konu için ayrı bir makale hazırlayarak konuları örnekler ile detaylandırmaya çalışacağım.

(S) Single Responsibility Principle

Özetle bir sınıfın (class) sadece bir işten sorumlu olmasıdır. Örneğin iş emri ile ilgili bir sınıf tanımladığımızı düşünürsek, bu sınıftaki metotlar sadece iş emri ile ilgili olmalıdır. Söz gelimi iş emrinin durumunun değiştirilmesi, açılması gibi işlemler bu sınıf tarafından yapılırken, bu hareketlerin loglanması, bildirimlerinin ilgili kişilere gönderilmesi gibi işler başka sınıflar tarafından yapılmalıdır. Konu ile ilgili detay makaleye buradan ulaşabilirsiniz.

(O) Open-Closed Principle

Genel kabul gören slogan tipinde bir tanımı vardır. Bir sınıfın genişletilmeye açık olması (Open) fakat değiştirilmeye kapalı olması (Closed) prensibidir. Bu prensibe göre projenin ileri safhalarında doğacak ihtiyaçlarının var olan sınıflardaki kodlara ekleme yapılarak veya kodlarda değişiklik yapılarak karşılanması bu prensibe aykırıdır. Var olan sınıf kendisinde hiçbir yazılımsal değişiklik yapılmadan, belli bir arayüzü (Interface) uygulayan ve sonradan eklenebilecek tüm diğer nesnelerle uyumlu çalışabilmelidir. Konu ile ilgili detay makaleye buradan ulaşabilirsiniz.

(L) Liskov Substitution Principle

Temel anlamda kalıtım ile türetilen nesneler (instance) ile tüm diğer nesnelerin türetildiği ana nesne birbiri ile yer değiştirildiğinde aynı davranışı sergilemeleri prensibine dayanır. Yani türetilen sınıftan örneklenmiş nesneyi ana sınıf tipinden bir parametre alan metoda gönderdiğimizde hata alıyorsak veya hata almamak için hata yakalama bloklarını kullanarak bazı sınıflara özel istisnai kodlar yazıyorsak, tasarımda bu prensibi göz ardı etmişiz demektir.

(I) Interface Segregation Principle

Uygulamamızda sınıfların uygulaması gereken arayüzler birbiri ile ilişkili özelliklerine göre gruplandırılmalıdır. Bu aşamada çok fazla üyesi olan bir arayüz tasarlamak yerine bir sorunu çözecek ve sadece o soruna odaklanmış özellik ve metotları içeren arayüzler oluşturulmalıdır.

(D) Dependency Inversion Principle

Projelerdeki üst seviye nesnelerin daha alt seviyede işlem yapan nesnelere olan bağımlılığının alt sınıftan üste doğru değil de üst sınıftan alta doğru ilerlemesi prensibine karşılık gelir. Bu tür bağımlılıklar sınıfın kendisi ile değil de arayüzlerle yapılmak sureti ile alt seviye sınıflar ile bağlantısı gevşek hale getirilmiş olur.

Bu makale konuya tanım boyutunda bir giriş makalesi formatında oldu. Bazı özellikleri örneklerle açıklamadığım için anlaşılması güç olmuş ve tanımlara boğulmuş bir makale havası yansıtmış olabilirim. Bu sorunu ileride her bir konuyu ayrı birer makale olarak ele alıp örneklendirerek çözmeyi planlıyorum. Ana hedefim makaleleri olabildiğince kısa tutmak. Bu yüzden tüm konuları detaylı olarak burada anlatmak yerine ayrı ayrı bölümlendirmeyi daha cazip buluyorum.

Faydalı olması dileğiyle…

Bir cevap yazın

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