July | 2016 | Karalama Defteri
July 23, 2016 July 29, 2016 ekin.yucel design patterns, software design, yazılım	design patterns, oop, software design
SOLID prensipleri, nesne tabanlı programlamada (OOP) ve tasarım mimarisinde kullanılan 5 tane prensiptir. Bu prensiplerin baş harfleri ile SOLID tanımı oluşmuştur. Kodun kolay anlaşılmasını sağlar. Bu prensipler ile loosely coupled (az bağımlı), reusability (yeniden kullanılabilinir) ve extendable (geliştirilebilir) mimari oluşturmamızı sağlar. Yazdığımız proje her zaman aynı kalmamaktadır. Projenin gelişime açık olması önemlidir. SOLID prensiplerine uygun yazılım projesi geliştirirsek projelerimiz her zaman esnek olur. Projenin kod bakımından ağırlaşmasının önüne geçer.
Bu prensipler bir hedef olarak düşünülebilir. Yaptığımız projeyi bu prensiplere mümkün olduğunca bağlı kalarak yazmaya çalışmalıyız.Aşağıda gösterilen resimde bu 5 prensip gösterilmektedir. Bunları kısaca anlatmayı düşünüyorum. Daha sonrasında her prensip ile ilgili örnekleri barındıran linkleri yazıya ilave edeceğim.
Single Responsibility Principle = Yaptığımız tasarım sade ve anlaşılır olmalıdır. Her sınıfın sadece tek bir görevi olmalı ve sadece o görevden sorumlu olmalıdır. Eğer bir sınıf için birçok görev tanımı yaparsak, ileride yapmak istediğimiz değişiklikler olunca işimiz zorlaşacaktır. SRP örnek
Open-Closed Principle = Bu prensip tanımına göre, tasarımımız gelişime açık değişime kapalı olmalıdır. Yarattığımız modüllerde kalıcı büyük değişiklikler yapmaktan ziyade hata düzeltme gibi kontrollü işlemler yapmalıyız. Büyük çaplı değişiklikler yapmak istediğimiz zaman mevcut kodda değilde o değişimi farklı bir modül üzerinden yapabiliriz. SRP ve OCP prensiplerini birbirlerinin tamamlayıcısı olarak görebiliriz. Her zaman bu değişimleri abstract sınıf veya interface sınıf kullanarak yapmalıyız. OCP örnek
Liskov Substitution Principle = Liskov yerine geçme prensibi olarak adlandırılır. Bu prensibe göre alt sınıflardan oluşturulan nesnelerin, üst sınıfların nesneleriyle yer değiştirdiklerinde aynı davranışı göstermek zorundadır. Child sınıflar, base sınıfların tüm özelliklerini kullanmak zorundadır. Bu örnekte kapsamlı olarak anlatılmaktadır.
Interface Segregation Principle = Interface (Arayüz) ayırım prensibi olarak adlandırılır. Kullandığımız arayüze gereğinden fazla özellik eklersek, oluşturduğumuz modüller bunların hepsini kullanmaya ihtiyaç duymayabilir. Bazı özelliklere ihtiyaç duymayan modüller bu özellikleri gereksiz olarak eklersek kullanışsız bir tasarım olacaktır. Interface yapısında her modülün kullanmadığı özellikler bulunuyorsa yapmamız gereken oluşturduğumuz interface yapısını bölmektir. ISP örnek
Dependency Inversion Principle = Bağımlılığı tersine çevirme prensibidir. Üst seviye modüller alt seviyeli modüllere bağımlı olmamalıdır. Alt sınıflarda yapılan değişimler üst sınıfları etkilememelidir. Her iki seviyeli modülde soyutlamalara bağlı olmalıdır. Ayrıca soyutlamalar fazlaca detaya boğulmamalıdır. Üst seviyeli modüller, alt seviyeli modüller ile abstract yapılar veya interface yapıları ile ilişki kurmalıdır. DIP örnek.
Design principles , Overview of SOLID Principles in C# , Wikipedia , SOLID–Adım Adım Tanımak (video anlatım),
Dependency kavramı ile ilgili detaylı bir yazı
Software Design Patterns (Yazılım Tasarım Şablonları)
July 8, 2016 ekin.yucel design patterns, yazılım	class, design patterns, oop, software, tasarım şablonları
Herkese merhabalar. Yazılım dünyasında sıkça bahsedilen ve önemli olan yazılım tasarım şablonları ile ilgili yazı dizisi yazmaya karar verdim.
Yazılım tasarımı sırasında sıkça karşılaşılan problemlere çözüm için tasarlanmış yazılım şablonlarına denir. Birçok farklı durum için o problemi çözmek için tasarlanmış kalıplardır. Bu tanımlamalar kullanılarak yazılım tasarımı yapılmaktadır. Yazılımcıların sistem veya uygulama geliştirirken kabul ettiği en iyi tasarım alıştırmalarından oluşmaktadır.
Tasarım şablonları programlama dillerinden bağımsız olarak tanımlanmışlardır. Ancak nesne tabanlı dillerine uygun tasarım şablonları daha fazla yaygınlaşmıştır. Bu şablonlar nesneler ve sınıflar arasındaki ilişkileri ve etkileşimleri göstermektedir. Yazılımı yapacak olan kişi elinde olan soruna göre bu şablonları özelleştirerek kullanacaktır.
Test edilebilir ve kanıtlanmış bu yapıları kullanarak yazılım geliştirme sürecini hızlandırmaktayız. Kaliteli yazılım tasarımı yapmak için projeyi hayata geçirdikten sonra çıkacak problemleri yazılım geliştirme esnasında çözmeliyiz. Tekrar kullanılabilir tasarım şablonları ile oluşacak büyük sorunların önüne geçebiliriz.
Tasarım şablonları yazılım dünyasında, (Design Patterns: Elements of Reusable Object-Oriented Software) adlı 1994 yılında yazılmış kitap sayesinde adından söz edilir hale gelmiştir. Kitabı yazan 4 yazar Gang of Four olarak adlandırılır.
Bu kitaba göre tasarım şablonları 3 gruba ayrılır;
Creational Patterns ( Yaratımsal Şablonlar )
Structural Patterns ( Yapısal Şablonlar )
Behavioral Patterns ( Davranışsal Şablonlar )
Yukarıda gösterilen resimde her belirtilen tasarım şablonu grubunda kullanılan yaklaşımlar gösterilmektedir.
Creational Patterns ( Yaratımsal Şablonlar ):
Yazılım nesnelerinin nasıl yaratılacağı hakkında genel öneriler sunmaktadır. Mevcut duruma uyarlanarak nesne yaratma problemleri ile mücadele etmektedir. Düzensiz oluşturulan nesneler tasarım problemlerine yol açabilir. Nesne yaratımını kontrol ederek karmaşıklıkları önleme amacındadır. Uygulamaya nesne oluştururken esneklik katmaktadır. Asıl amacı, iyi bir yazılımın içinde barındırdığı nesnelerin nasıl yaratıldığından bağımsız tasarlanması gerekliliğidir.
Modern yazılım geliştirmede nesnelerin birbirleri arasında oluşan ilişki önemlidir. Herhangi bir şablon olmadan oluşturulan büyük yazılım modelleri, yeni bir özellik eklenmek istediği zaman veya eklenecek yeni bir özellik olduğunda işlemi zorlaştıracaktır. Ayrıca yeniden kullanılabilirik imkanı azalacaktır.
Ne zaman sisteme eklememiz düşünülebilir?
Sistemin nesne yaratımlarından bağımsız olması gerektiğinde
Birbiri ile bağı olan nesneleri kullanacağımız zaman
Nesneleri nasıl oluşturduğumuzu gizlemek istediğimiz zaman ve sadece oluştukları interfaceleri göstermek istediğimizde.
Sınıfların örneklemelerinin çalışma zamanında tanımlanması
Temelde tek bir sınıf instantination varsa ve kullanıcı sürekli bu örneklemeye erişmek isterse
Aşağıda gösterilen sınıf diyagram birçok yaratımsal tasarım şablonunda ortaktır.
Creator = Nesne arayüzünü tanımlar ve nesne döndürür.
ConcreteCreator = Nesne arayüzünü implement etmektedir.
Yapısal tasarım şablonları ile dizaynı kolaylaştırarak sınıflar arasındaki iletişimi düzene sokmak için kullanılırlar. Sınıflar ve nesnelerin büyük yapıları nasıl oluşturacağı tanımlanır.
Nesnelerin davranışları ve birbirleri ile olan ilişkileri ile ilgilenir. Davranışsal şablonları kullanılarak nesnelerin birbileri ile olan iletişimin esnekliği artmaktadır.
Tasarım şablonlarını tanıtarak giriş yapmış olduk. Sonraki yazılarımda Yaratımsal şablonlardan başlayarak, her grupta bulunan yaklaşımları örnekler ile anlatmaya çalışacağım.