yazılım tasarım prensipleri

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;)

Single Responsibility Principle (SRP)

22 Mayıs 2012Kazım CesurPrinciples

“THERE SHOULD NEVER BE MORE THAN ONE REASON FOR A CLASS TO CHANGE”

Tasarlanan her sınıfın sadece tek bir sorumluluğu olmalı ve sınıfın değişikliğe uğraması için birden fazla neden olmamalıdır. SRP, birbirine sıkı sıkıya bağlı olan sınıflarla benzerlik göstermektedir. Prensibe tasarımsal olarak baktığımızda ise sınıf bir sorumluğu yerine getirirken diğer sınıf fonksiyoneliteyi gerçekleştirmektedir. Buradaki sorumluğu netleştirecek olursak, sınıfın sadece tekbir metod içereceği anlamına gelmez. Sorumluluk sınıf içerisinde bir çok metod kullanılarak gerçekleştirilebilir.

(daha&helliip;)