A Solution Architect's Journey
(?) Koşula bağlı değenlendirme operatörü
Bu operatör bize if-then-else pattern’ini tek bir satırda yapmamıza olanak sağlar. Bu öperatörü kullanmadan yazacağımız örnek kodlar aşağıdaki gibi olacaktır.
int a = 10; int b = 20; int max; if (a > b) max = a; else max = b;
Operatörün kullandıktan sonra kodlarımızın ne kadar kısaldığını gözlemleyelim.
Kullanım şekli (Koşul) ? Doğru cevap : Yanlış cevap
int a = 10; int b = 20; int max = (a > b) ? a : b;
“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.
“Unable to install or run the application. the application requires that assembly EnvDTE Version 8.0.0.0 be installed in the Global Assembly cache (GAC) first. Please contact your system administrator.”
Projenizi ClickOnce olarak deploy ediyorsunuz ve projenizin referanslarında EnvDTE.dll’i bulunmamasına rağmen bu hatayı alıyorsanız. Sebebi Visual Studio IDE’si arayüzden derlediğimiz ClickOnce paketi içerisine EnvDTE referansını otomatik olarak yerleştirmesidir. Bu sorunu aşmanın yolu ClickOnce paketi oluşturmak için MSBuild.exe tool’unu kullanmaktır.
Çok basit bir kaç adımda Visual Studio IDE’sini kullanmadan derleme, publish gibi işlemleri yapabilmekteyiz.
”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.
“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.