İçeriğe geç

SOLID Prensipleri

Bu yazımda yazılım geliştiricilerin olmazsa olmaz kavramı SOLID Prensipleri konusuna değineceğim. Amacım SOLID Prensipleri kavramına teorik bir giriş yapmak, SOLID kavramını oluşturan tasarımsal sorunlardan bahsetmek. Tabi internette bu türde okuduğunuz alışılagelmiş  makalelerden biraz farklı olacak diyebilirim. Zira buradaki amacım SOLID’i açıklayıp geçmek değil, SOLID ve etrafındaki bağlantılı kavramları bir bütün olarak size tanımlayabilmek olacak.

Kısa Tanımı

SOLID Prensipleri (SOLID İlkeleri), nesne yönelimli programlama ve tasarım için ortaya çıkmış  5 adet ilkeden oluşan bir bağımlılık yönetimi (dependency management) biçimidir. Mucidi Uncle Bob olarak bilinen Robert Cecil Martin’dir. Martin, bu kavramı “yazılımda kötü mimari tasarım” sorununa çözüm için ortaya çıkarmıştır.

SOLID Prensiplerini Neden Bilmeliyim?

Nesne-Yönelimli Programlama prensipleri her yazılım geliştiricinin bilmesi ve takip etmesi gereken bir konu. Bazı geliştiriciler “bu kavram mimariye giriyor, nasılsa kullanmıyorum, daha çok erken” vb. sebeplerden ötürü ya kendileri göz ardı ediyor ya da bulundukları takımda göz ardı ediliyorlar. Ancak şunu unutmamak gerekir ki siz basit projelerde ya da sadece uygulama geliştirme (application development) gibi daha çok sunum katmanında kod geliştiriyor olsanız da nesne yönelimli yazılım ve tasarımı öğrenmek ilk işiniz olmalı. Eğer bu ilkeleri bilir ve uygularsanız inanın çok şey kazanırsınız.

Nesne Yönelimli Programlama konusu ile ilgili yazdığım başlarken yazısı için burayı tıklayabilirsiniz…

Maalesef ki sektörde bu ve buna benzer tekniklerden bihaber çok fazla yazılım geliştirici var, üstelik bu arkadaşların bazılarının unvanlarında “Senior” yazıyor. Bu insanları işe alanların neden bu denli yetersiz olduğunu anlamakta zorlanıyorum açıkçası.

Mesleğinizde güçlü olabilmek, çeşitli sorunlara en baştan çözümler sunabilmek için bu tür kavramları bilmeli ve uygulamalısınız.

SOLID Prensipleri ve Bağımlılık Yönetimi

Bağımlılık Yönetimi (dependency management) kısaca; oluşturduğunuz kütüphanelerin yeniden kullanılabilir bir işlevselliğinin olması ve modüler bir yapıda oluşturulabilmesi için ayrı bileşenlere bölünmesidir. Her bir bileşenin kendi sorumluluk alanına sahip olması, başka bir bileşen ile sıkı sıkıya bağlı olmaması en önemli özelliğidir.

SOLID Prensipleri de tam burada ortaya çıkıyor;  bağımlılıkların azaltılması ve görevlerin tekilleştirilmesi, yazılımın bakımı ve genişletilmesi kolaylaştırıyor.

Yazılım geliştirmede “code smells” diye bir tabir vardır. Eğer önünüze geliştirmeniz için konulan bir projenin kodunun bakım ve genişletilmesinde yani teknik tasarımında sorun olduğunu görürseniz kodun “koktuğunu” anlarsınız. Yine aynı şekilde kodun elden geçirilip düzenlenmesi (code refactoring),  çevik ve uyarlanabilir yazılım geliştirilmesi (adaptive software development) için de SOLID Prensiplerinin doğru anlaşılması ve uygulanması gerekir.

Code Smells için Gerçek Hayat Hikayesi:

Çok eskiye gitmeyeceğim, yıl 2017, savunma üzerine önemli bir devlet kurumunun projesine başladım. İlk faz bitmek üzere. Proje takvimine göre  proje kabulü normalde 3 hafta sonra başlıyor ama uzatma alınmış ve onda da 8 hafta süreleri kalmış.

Projenin 11 modülü var ancak bunlardan 3’ü  temel modül ve ortada bu temel modüller yok. Şaka mı yapıyorum?  Tabi ki hayır!

Neyse bir taraftan projeyi anlamaya çalışıyorum, diğer taraftan yazılım mimarisini gördükçe hayretler içinde kalıyorum. Öyle bir mimari var ki “mimari” kelimesi utanır, üstelik bu yazılım mimarisinin kontrolü ve olur onayı devlet projelerini ihalesiz alan ve alt firmalara taşere eden yarı devlet statülü bir A.Ş. çalışanları tarafından verilmiş ya da bir şekilde verdirilmiş (bu da tartışmalı bir konu tabi).

Projede bırakın güvenlik ve performansı, bağımlılık yönetimi hatta esneklik ve yeniden kullanılabilirlik namına hiçbir şey yok;

  • Veri katmanı direkt Sunum katmanına bağlanmış
  • Yazılım ASP.Net WebForm ama tüm ekranlar javascript ile içlerine gömülmüş, ASP.Net’in hiçbir özelliği kullanılmamış.
  • Tüm veriler, tablo isimleri, kolon isimleri kaynak kodda apaçık ortada.
  • Servis katmanı yok, servis yapısı asmx ile sunum katmanı içinde bir klasör.
  • SOLID Prensipleri, Tasarım Kalıpları namına hiçbir şey yok, servisleri taşıyacak interfaceler yok, cache yapılandırması yok, CI/CD namına bir şey yok, Unit Testing yok.
  • Asıl amacı veri tabanı ile iletişim olan veri katmanında tonlarca metot ve her birinde tonlarca if-else blokları ile doldurulmuş. İş katmanının görevini de yapıyor!
  • Daha sayamadığım onlarca sorun…

Yani belki de e-devlet yazılım projeleri hayatımda, ki bu süre 13 yıl, parça parça toplasam görmediğim kadar hatayı tek bir projede gördüm diyebilirim.  Bu mimariyi yazan ekibin teknik liderinin yetersizliği, onun ve ekibinin doğru denetlenememesi, böyle önemli bir projeye alınan ekip üyelerinin tamamının deneyimsiz olmaları,  iş dışında gelişen profesyonellikten uzak tavırlar projeyi bu hale getirmiş.

Ah işte tam da yurt dışına, İngiltere’ye yerleşme sebebim diyebilirim buna, neyse biz kaldığımız yerden devam edelim…

Peki Neden Bu Kadar Önemli ?

Bağımlılık yönetimi yapılmamış, temel OOP tasarım ve prensiplerine uyulmamış bir yazılım projesi, bakımının yapılmasında ve daha sonradan ortaya çıkabilecek genişletme isteklerinde işin işinden çıkılmaz bir hal alır. Yeni özellikler ekleyemez, hatta mevcut bir işlevde güncelleme yapamazsınız. Yaparsınız yapmasına ama bu düzenlemeler hiç düşünmeyeceğiniz başka bir yapıyı bozabilir. Bu sorunlar gittikçe can sıkıcı bir hal almaya başlar ve sonunda “projenin yeniden yazılması” gündeme gelir. Bunun etkileri çok daha büyük olacaktır çünkü o zamana kadar harcanan kaynaklar aynı iş için yeniden harcanacaktır. Tıpkı yukarıda verdiğim gerçek hayat hikayesinde olduğu gibi.

SOLID Prensiplerini uygulamak size bakımı yapılabilir, esnek ve genişletilebilir bir proje sunar. Lütfen yazılım ekiplerinizi seçerken mimari tasarım yönünden güçlü liderler seçin, eğer mimari tasarım yönü zayıf liderler seçerseniz onunla birlikte aynı ekipte yer alan diğer geliştiricileri de köreltir ya da kariyerlerinde tamir edilemez hasarlara yol açabilirsiniz.

Sınıf Tasarımı için Prensipler (Principles of Class Design)

Projenizde sınıflar için belirlenmiş prensiplerin uygulanması gerekir.  Bu prensipler sayesinde sınıflar üzerindeki modellemede uymamız gereken kurallar belirlenir. Sınıflar için uyulması gereken kurallar, kötü bir mimari tasarıma neden olabilecek 3 unsuru ortadan kaldırmak amacıyla ortaya çıkmıştır:

  • Rigidity (Esnemezlik): Oluşturulan mimari tasarımın geliştirmeye ve yeni eklentilere (plug-in) açık olmamasıdır.
  • Fragility (Kırılganlık): Projenin herhangi bir yerinde yapacağınız bir değişikliğin başka bir parçasında sorun çıkarabilmesidir.
  • Immobility (Sabitlik): Geliştirilen parçaların/modülün tekrar kullanımına uygun olmamasıdır.

Yukarıda saydığım bu 3 unsur genel itibari ile bağımlılık seviyesi yüksek sınıf yapılarında görülür. Tabi birbirine sıkı sıkıya bağlı (tight coupling) bu sınıf yapılarında esneklikten, sağlamlıktan ya da tekrar kullanılabilirlikten söz edemeyiz. Sınıflar arası bağımlılığın azaltılması konusuna yani loose coupling konusuna başka bir yazımda ayrıca değineceğim.

SOLID Açılımı ve Tanımı Nedir?

Buraya kadar geldiyseniz aklınızda SOLID hakkında bir fikir uyanmış demektir. Yazıma başlarken de bahsettiğim gibi teorik olarak SOLID’in açılımını verip şimdilik bu yazımı tamamlayacağım.

SOLID, Nesne-Yönelimli Tasarım’ın (object-oriented design) ilk  5 prensibinin kısaltmasıdır:

  • SSingle Responsibility Principle (SRP): Nesnenin sadece bir sorumluluğu olmalıdır, yani olası bir değişiklikte tek bir nedene dayandırılmalıdır.
  • OOpen/Closed Principle (OCP): Nesne genişlemeye açık ancak değişikliklere kapalı olmalıdır. Yani bir sınıfın davranışını değiştirmeden onu genişletmeye dayandırılır.
  • LLiskov ‘s Substitution Principle (LSP): Programdaki nesnelerin, programın çalışmasında sorun yaratmadan kendi alt örnekleri ile değiştirilebilir olmasıdır. Bu aynı zamanda sözleşmeyle tasarım (Design by Contract ) olarak bilinir.
  • IInterface Segregation Principle (ISP): Nesnelerin ihtiyaç duymadıkları metodların Interface’lerinden münkün olduğunca ayrıştırılmasıdır.
  • DDependency Inversion Principle (DIP): 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.

Bize gerçekçi bir bağımlılık yönetimi sağlayan SOLID Prensipleri kavramına giriş yaptık, yukarıda sıraladığım bu 5 ilkenin her birinin C# kod örnekleri ve görsel anlatımla desteklenmiş yazılarını diğer makalelerimde bulabileceksiniz.

SOLID Prensiplerini oldukça geniş bir çerçevede incelemeye ve örneklendirmeye çalıştım.

Faydası olması dileği ile…

Tarih:Tasarım Prensipleri

8
Kimler Neler Demiş?

avatar
5 Comment threads
3 Thread replies
0 Followers
 
Most reacted comment
Hottest comment thread
6 Comment authors
S. Sıtkıselim inazVolkan Barbaros Gürcancüney yildirimnuran Recent comment authors
  Subscribe  
Bildir
S. Sıtkı
Ziyaretçi
S. Sıtkı

ELinize sağlık, gerçek hayat hikayesi kısmı benim de çalıştığım bir projemde başıma geldi. Oldukça deneyimli diye düşündüğümüz bir ekip liderinin kurbanı oldu proje. Maalesef bu tür adamlar piyasada çok, biz üç kuruşa zar zor iş bulurken böyleleri nasıl giriyorlar
bu işlere anlam veremiyorum.

selim inaz
Ziyaretçi
selim inaz

Birbirinin kopyası solid prensipleri konularından farklı olmuş, kötü tasarıma baya değinmişsiniz. Çok güzel olmuş, elinize sağlık.

ziya aktürk
Ziyaretçi
ziya aktürk

giriş olarak bile doyurucu, genelde bu kadar uzun yazılardan sıkılırım ama hiç sıkılmadan bir çırpıda okudum. Gerçek hayat hikayesi ayrıca etkileyiciydi.

Emeğinize sağlık.

cüney yildirim
Ziyaretçi
cüney yildirim

Gerçek hayat hikayesi bir harika, diğer yazılarınıza da bu tür anılarınızı yazın, çok güzel olmuş.

nuran
Ziyaretçi
nuran

Oncelikle elinize sağlık. Bilgi için teşekkürler.
Fakat makale solid ilkelerinin oraya kadar çok iyi olmuş.
Solid ilkeleri çok yüzeysel şekilde sadece çeviri olmuş. Daha iyi olmalıydı.
(Yapıcı yorum) saygilarimla