Principles

Software Design Principles (Yazılım Tasarım Prensipleri)

20 Haziran 2012Kazım CesurPrinciples

Tasarım prensipleri, yazılım geliştirirken hatalı yapılan tasarımları önlememize ve ideal bir yazılım oluşturmamıza yardımcı olmak amacıyla hazırlanmış bir rehberdir.

Bu prensipler Robert Martin tarafından ilk olarak “Agile Software Development: Principles, Patterns, and Practices” kitabında bir araya getirilmiştir.

Hazırlanan rehbere göre kötü tasarımın önüne geçmek için uzak durulması gereken 3 önemli vaka bulunmaktadır;

Rigidity : Esnek olamamak, tasarımınızın gerektiğinde geliştirmeye ve genişlemeye olanak sağlamadığını gösterir. Böyle bir tasarımda herhangi bir bölümü değiştirmek zordur çünkü yapacağınız değişiklik yazılımın bir çok bölümüne etki etmektedir.

Fragility : Kırılgan olmak, tasarımınızda yapacağınız değişikliğin yazılımın hiç beklemediğiniz diğer bölümlerinde sorun çıkarması ve işlevlerini bozan durumlardır.

Immobility : Sabit olmak, yeni bir yazılım geliştirirken daha önceki tasarımınızdaki bir bölümü tekrar kullanmak zordur, çünkü o bölüm önceki tasarımınızla karışmış bir durumdadır.

Kaynak;

Robert C. Martin
OODesign
Agile Principles, Patterns, and Practices in C#

Dependency Inversion Principle (DIP)

19 Haziran 2012Kazım CesurPrinciples

Dependency Inversion Principle (DIP)

“High-level modules should not depend on low-level modules. Both should depend on abstractions.”

“Abstractions should not depend on details. Details should depend on abstractions.”

Prensip temel olarak, üst modüller (sınıflar) ve alt modüller (sınıflar) arasında kuvvetli bir bağ olmamasını gerektiği ve alt ve üst modüller (sınıflar) arasında sadece soyut (abstract) bir bağ olmasını önermektedir.

Örnek bir senaryo üzerinde bu prensibi açıklamayalım. İngilizce’den Fransızca’ya metin çevirisi yapan bir uygulamamız olduğunu düşünelim ve üst ile alt sınıfların kuvvetli bir bağ ile birbirine bağlı olduğunu aşağıda gözlemleyelim.

(daha&helliip;)

Interface Segregation Principle (ISP)

31 Mayıs 2012Kazım CesurMS .Net Framework, Principles

“Clients should not be forced to depend on methods they do not use.”

Prensip temel olarak, genişletilecek sınıfların kullanmayacağı,
metodlar yada özellikleri içeren interface’leri yada ana soyut (base abstract) sınıfları;
birbiriyle olan ilişkileri (cohesive) ve işlevlerine göre ayrı interface’lere ayırmamız gerektiğini belirtir.

Peki böyle bir işlemin bize ne anlamda yararı olacaktır? Örneğin bir sınıf tasarladığımızda bir çok özelliği ve metodu olan bir interface implement ettiğimizi düşünelim. Interface’ i implement ettik ancak tasarladığımız sınıfın ihtiyacı olmayan bir çok özellikte sınıfımıza gelmiş oldu. Bu özelliklerin bazılarını implement ettiğimizi bazılarınıda etmediğimizi düşünelim. Tasarladığımız sınıfı kullanan diğer sınıflar implement etmediğimiz bir özellik yada metodu kullanmaya çalıştığında hata alacaklardır. Buda daha önce anlattığımız LSP ve SRP prensiplerinde bahsettiğimiz durumlara aykırı düşecek ve istenmeyen bir durum oluşturacaktır.

(daha&helliip;)

Liskov’s Substitution Principle (LSP)

24 Mayıs 2012Kazım CesurPrinciples

Liskov's Substitution Principle (LSP)

“An object should be substitutable by its base class (or interface). Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it.”

Türetilmiş sınıflar türetildikleri ana sınıf (base class) ile yer değiştirilebilir olmalıdır. Bir başka deyişle türetilen sınıflardan oluşturulan nesneler türetildikleri ana sınıfların (base class) nesneleriyle yer değiştirdiklerinde aynı davranışı göstermek zorundadırlar.

(daha&helliip;)

Open Closed Principle (OCP)

22 Mayıs 2012Kazım CesurPrinciples

”Software entities (Classes, modules, functions) should be OPEN for EXTENSION, CLOSED for MODIFICATION.”

Geliştirilen sistemlerin yaşam süreleri boyunca değişimlere uğrayabileceği göz önüne alındığında, bu prensip genişletilmeye açık ama değişikliğe kapalı varlıkların (Sınıf, Method vs.) kullanılmasını önerir.

Peki yazılımın kaynak kodunu değiştirmeden, geliştirdiğimiz modullerin böyle bir davranış sergilemesini sağlayabiliriz?
Bu soruyu soyutlayarak (abstraction) diye cevaplayabiliriz. Bir sınıfı soyutlayarak manupule edebilirz.

(daha&helliip;)