DRY – Don’t Repeat Yourself

DRY = Don’t Repeat Yourself = Kendini Tekrarlama!

DRY prensibine göre programcının kodlama esnasında kod tekrarlarından (code duplication) sakınması gerekmektedir. Kodun kendini tekrarlaması (örneğin copy-paste metodu kullanılarak) yazılım sisteminin genelde bakımını ve geliştirilmesini zorlaştırır. Bunun önüne geçmek için azimle DRY prensibinin uygulanması gerekmektedir.

Okumaya devam et

Interface Segregation Principle (ISP) – Arayüz Ayırma Prensibi

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.
ISP uygulanmadığı taktirde, birden fazla sorumluluğu olan interface sınıflar oluşur. Zaman içinde yüklenen yeni sorumluluklarla bu interface sınıflar daha da büyür ve kontrol edilemez bir hale gelebilir. Bunun bir örneğini resim 1 de görmekteyiz.

Okumaya devam et

Test Güdümlü Yazılımın Tasarım Üzerindeki Etkileri

Yazılımcı olarak çalıştığım projelerde geleneksel ve çevik yazılım süreçleri hakkında tecrübe edinme firsatı buldum. En son kitabım bir çevik süreç olan Extreme Programming hakkındadır. Edindiğim tecrübeler doğrultusunda çevik süreçlerin, klasik yazılım süreçlerine nazaran bakımı ve geliştirilmesi daha kolay yazılım sistemlerinin oluşturulmasında daha avantajlı olduğunu söyleyebilirim.

Okumaya devam et

Builder Tasarım Şablonu

Daha önceki bölümlerde Abstract Factory tasarım şablonu ile değişik nesne ailelerinden nasıl nesneler üretildiğini incelemiştik. Builder tasarım şablonu da Abstract Factory tasarım şablonunda oldugu gibi istenilen bir tipte nesne oluşturmak için kullanılır. İki tasarım şablonu arasındaki fark, Builder tasarım şablonunun kompleks yapıdaki bir nesneyi değişik parçaları bir araya getirerek oluşturmasında yatmaktadır. Birden fazla adım içeren nesne üretim sürecinde, değişik parçalar birleştirilir ve istenilen tipte nesne oluşturulur.

Okumaya devam et

Business Delegate Tasarım Şablonu

Modern yazılım sistemleri birden fazla katmandan oluşur. Bu katmanlar her zaman aynı server üzerinde mevcut olmayabilir. Bu durumda bir katmandan diger katmana ulaşmak için remote call olarak isimlendirilen RMI operasyonları yapılır. Örneğin EJB teknolojisi ile hazırlanan komponentler birden fazla server üzerinde hizmet sunabilir. Bu komponentlere bağlanıp, işlem yapabilmek için RMI kullanılır. Okumaya devam et

Dependency Inversion Principle (DIP) – Bağımlılıkların Tersine Çevrilmesi Prensibi

Bu prensibe göre somut sınıflara olan bağımlılıklar soyut sınıflar ve interface sınıflar kullanılarak ortadan kaldırılmalıdır, çünkü somut sınıflar sık sık değişikliğe uğrarlar ve bu sınıflara bağımlı olan sınıflarında yapısal değişikliğe uğramalarına sebep olurlar. Okumaya devam et

Open Closed Principle (OCP) – Açık Kapalı Tasarım Prensibi

Yazılım disiplininde değişmeyen birşey varsa o da değişikliğin kendisidir. Birçok program müşteri gereksinimleri doğrultusunda ilk sürümden sonra değişikliğe uğrar. Bu doğal bir süreçtir ve müşteri programı kullandıkça ya yeni gereksinimlerini ya da mevcut fonksiyonlar üzerinde adaptasyonları gerekçe göstererek programın değiştirilmesini talep edecektir.

Okumaya devam et

Loose Coupling (LC) – Esnek Bağ Tasarım Prensibi

Bir program bünyesinde, tanımlanan görevlerin yerine getirilebilmesi için birden fazla nesne görev alır. Bu nesneler birbirlerinin sundukları hizmetlerden faydalanarak kendi görevlerini yerine getirirler. Bu durumda nesneler arası bağımlılıklar oluşur. Bir nesne kullandığı diğer bir nesne hakkında ne kadar fazla detay bilgiye sahip ise, o nesneye olan bağımlılığı o oranda artar. Oluşan her bağımlılık bir sınıf için dolaylı olarak yapısal değiştirilme rizikosunu artırır, çünkü bağımlı olduğu sınıf üzerinde yapılan her değişiklik kendi yapısında değişikliğe neden olacaktır. Bu durum programın genel olarak kırılgan bir hale gelmesini kolaylaştıracaktır.

Okumaya devam et

Chain of Responsibility Tasarım Şablonu

Chain of responsibility sorumluluk zinciri anlamına gelmektedir. Sisteme gönderilen bir istediğin (komut) hangi nesne tarafından cevaplanması gerektiğini bilmediğimiz durumlarda ya da isteği yapan nesne ve servis sağlayan nesne arasında sıkı bir bağ oluşmasını engellememiz gerektiğinde Chain of Responsibility tasarım şablonu kullanılır. Okumaya devam et

Flyweight (Sinek Siklet) Tasarım Şablonu

Java dilinde yazılan programlar içinde sınıflar ve bu sınıflardan oluşturulan nesneler kullanır. Bazen aynı sınıftan yüzlerce, belki binlerce nesne oluşturup, kullanıyor olabiliriz. Bu gibi durumlarda çok nesne oluşturulduğu için sistem performansı kötüye gidebilir. Flyweight tasarım şablonu kullanılarak, kullanılan nesne adedini aşağıya çekebiliriz.

Okumaya devam et

Proxy (Vekil) Tasarım Şablonu

Oluşturulmaları zaman alıcı ve sistem kaynaklarını zorlayan nesnelere vekalet eden nesnelere proxy nesneleri adı verilir. Bu nesneler vekil oldukları nesnelerin tüm metodlarına sahiptirler ve kullanıcı sınıf ile vekil olunan nesne arasında aracılık yaparlar. Vekil olan nesne, kullanıcı sınıfa, vekil olunan nesne gibi davranır ve kullanıcı sınıftan gelen tüm istekleri vekil olunan nesneye iletir. Böyle bir yapının kullanılmasının sebebi, gerek olmadığı sürece vekil olunan nesnenin oluşturulmasını engellemektir ya da vekil olunan nesneyi gizlemektir. Okumaya devam et

Facade (Cephe) Tasarım Şablonu

Profesyonel yazılım sistemleri birçok komponentin birleşiminden oluşur. Yazılım esnasında bir çok ekip birbirinden bağımsız, sistemin bütününü oluşturan değişik komponentler üzerinde çalışırlar. Bir komponent, belirli bir işlevi yerine getirmek için hazırlanmış bir ya da birden fazla Java sınıfından oluşmaktadır.

Okumaya devam et

Embedded Jetty

Üzerinde çalıştığım açık kaynaklı JStorage projesinde Tomcat yerine, bir Java sınıfından koşturulabilecek Jetty containeri kullandım. Jetty, Tomcat gibi bir JSP/Servlet containeri. Aşağıdaki örnekte yer aldığı gibi Jetty bir Java (main()) program tarafından çalıştırilabilir.

Okumaya devam et