Nesne Yönelimli Tasarım Prensipleri
Merhaba,
Nesneye dayalı programlama yaparken birden fazla teknik kullanabilir. Nesne temelli bir dil kullanıyorsak projede, nesneye dayalı programlama tekniklerini kullanmalıyız. Java ve C# gibi popüler nesne temelli yazılım dillerinde bu tasarımları yaparken ihtiyacımız olan her türlü yetenek mevcuttur. Bu yeteneklerden doğru biçimde faydalanırsak ortaya güzel tasarımlar çıkar. Bu tıpkı yemek yapımında kullanılan malzemeler gibidir. Yazılım geliştirirken önce neyin yapılmaması gerektiğini bilip ona göre davranmalıyız. Eğer kötü tasarımın ne olduğunu bilirsek iyi tasarıma bir adım daha yaklaşmış oluruz.
Kötü tasarımın bazı belirtileri ve ortak özellikleri vardır. Bu özellikler bir projede görülüyorsa bir şeyleri yanlış yapmışız demektir.
- Projede bir değişiklik yapılmak istenildiğinde bu değişikliği yapmak zor oluyorsa,
- Yapılan değişiklik birçok yeri bozuyorsa veya bozabileceğinden şüphe ediliyorsa,
O proje kötü tasarlanmış bir projedir. Bu gibi projeler ileride birçok sıkıntıyı beraberinde getirir. Yazılımda tasarımın doğru yapılmasının ne denli önemli olduğunu söyledikten sonra tasarım prensiplerini inceleyelim.
[caption id=”attachment_2776" align=”alignnone” width=”750"]
SOLID prensipleri diye de adlandırılan 5 adet ve dünya üzerinde nesne temelli yazılım geliştirirken kullanılan, standartlaşmış teknikleri sırayla inceleyelim.
Tek Sorumluluk Prensibi (Single Responsibility Principle — SRP)
Nesneye yönelik programlamanın kalbinde sınıflar bulunur. Bu sınıfların tasarımı projenin temelini oluşturur. Bunların kullanılmasının sebebi ise işleri yönetilebilir kılmaktır. Bazen farklı işleri gidip aynı sınıf ve metodlar içersinde hatta modüller içersine koyuyoruz. Bu yaptığımız şey etrafta yüzlerce ve binlerce satırlık sınıflar, metodlar görmemize sebep oluyor. Bu şekilde olunca en son satıra ulaşmak belli bir zaman alıyor.
[caption id=”attachment_2777" align=”alignnone” width=”750"]
SRP özetle, sadece tek bir sorumluluğu yerine getirmelidir ve yerine getirdiği sorumluluğu iyi yapmalıdır. Birden fazla sorumluluk yerine getirmeye çalıştığı zaman aşırı büyür ve karmaşıklaşır. Basit bir örnek verelim:
public class Ogrenci {
public void SinifiDegistir(){
// Ögrecinin sınıfını değiştir.
}public void DanismanDegistir(){
// Ögrecinin danışmanını değiştir.
}
}
Burada öğrenciyle ilgili yapılacak işlemleri metodlara ayırarak yönetilebilirliliği ve kullanılabilirliği sağladık.Açık Kapalı Prensibi (Open Closed Principle - OCP)Uygulama geliştirme sürecinde ve sonrasında müşterilerin isteklerine göre sürekli güncellemeler olmaktadır. Bu isteklerin sisteme kolay şekilde entegre olabilmesi için gelişime açık, değişime kapalı bir şekilde geliştirmeliyiz. İleriye dönük esnek tasarımlar yapmış olursak, isteklerin üstesinden kolayca gelebiliriz.[caption id="attachment_2778" align="alignnone" width="750"]
https://lostechies.com/derickbailey/2009/02/11/solid-development-principles-in-motivational-pictures/[/caption]OCP ile ilgili örneği buradan inceleyebilirsiniz.Liskov’un Yerine Geçme Prensibi (Liskov Substitution Principle - LSP)Barbara Liskov isimli üstadın ortaya attığı prensibe göre üst sınıflarla alt sınıflar arasında davranış olarak hiçbir fark olmamalıdır. Yani birbirlerinin yerine kullanılabilmelidirler. Türetilen sınıfların, türeyen sınıftaki işlevselliği tam olarak yerine getirdiğinden emin olmalıyız. Yani bir program türetilen sınıfı kullanırken, bir anda türeyen sınıfları kullanmaya geçebilmeli ve sistem bundan etkilenmemelidir.[caption id="attachment_2779" align="alignnone" width="750"]
https://lostechies.com/derickbailey/2009/02/11/solid-development-principles-in-motivational-pictures/[/caption]Liskov örneğine buradan ulaşabilirsiniz.Arayüz Ayrım Prensibi (Interface Segregation Principle - ISP)Prensipler konusunda ilerledikçe her prensibin uygulanmasının ortak bir amacı olduğunu fark etmişsinizdir. Bu prensip de yine aynı ortak amaca hizmet etmektedir. Tek sorumluluk prensibini hatırlayacak olursak; her sınıfın değişmesi için tek bir sebep var demiştik. İşte bu prensip de tek sorumluluk prensibinin arayüzler üzerine implemente edilmiş halidir.[caption id="attachment_2780" align="alignnone" width="750"]
https://lostechies.com/derickbailey/2009/02/11/solid-development-principles-in-motivational-pictures/[/caption]Arayüzler sınıfların özetleridir. Özet ne kadar kısa olursa o kadar iyidir ;) Eğer özet uzun olursa murat131 örneğindeki gibi klima tuşunu koyup işlevsiz bırakmak mecburiyetinde kalırız. ISP ile ilgili örneği buradan inceleyebilirsiniz.Bağımlılığın Ters Çevirilmesi Prensibi (Dependency Inversion Principle - DIP)Üst seviyeli işlem yapan sınıflar(High Level Class – Yüksek Dereceli Sınıf), alt seviyeli işlem yapan sınıflara(Low Level Class – Düşük Dereceli Sınıf) bağımlı olmaktadırlar. Bir başka açıdan bakarsak, üst seviyeli işlem yapan metodlar, alt seviyeli işlem yapan metodları kullanmaktadırlar. Haliyle alt seviye metodlarda olası her değişiklik üst seviye metodlarda değişikliğe sebep olması üst seviyenin alt seviyeye bağımlılığını göstermektedir. Haliyle DIP bize bu bağımlılığın ters çevrilmesini prensip edinmemizi önermektedir.[caption id="attachment_2781" align="alignnone" width="750"]
https://lostechies.com/derickbailey/2009/02/11/solid-development-principles-in-motivational-pictures/[/caption]DIP ile ilgili örneği buradan inceleyebilirsiniz.Diğer PrensiplerNesneye yönelimli yazılım geliştirme alanında standartlaşan SOLID prensipleri dışında birkaç tane daha yazılım geliştirmeyle alakalı prensipler vardır. Bunlar;
- KISS Prensibi
- YAGNI Prensibi
- DRY Prensibi
- Reuse Release Equivalency Prensibi
- Common Closure Prensibi
Tasarım Prensipleri özetle bu şekilde. Tasarım prensipleriyle ilgili daha derin bilgilere sahip olmak isteyenler küçük bir google aramasıyla ulaşabilirler.
