Tasarım nedir?
Tasarımı kısaca açıklamak gerekirse, bir programı hayata geçirebilmek için tasarım prensipleri kullanılarak oluşturulan yapıdır.
İyi bir tasarım yapmak, bir program için büyük ölçüde önemlidir ve onun sürdürülebilirliğinin garantisidir de diyebiliriz.
İyi bir tasarım yaparken tıpkı Object Oriented Programming’in amaçlarında var olan Reusability, Extendability, Maintainability ve Readability kavramlarına uymaya özen gösterdiğimizde, uygulamamızın bir nevi hayat sigortasını da sağlamış oluruz.
Bu kavramlardan kısaca bahsetmek gerekirse:
İyi bir tasarım yapmaktaki amacımız nedir?
Bu soruya ise aslında yukarıda OOP’nin de temel amaçlarından olan kavramları tanımlarken yanıtlamış olduk.
Özetle geçmek gerekirse, uygulamamızın geliştirile bilirliğini arttırmak ve esnekliğini sağlamaktır diyebiliriz.
Kötü tasarımın belirtileri nelerdir?
Kötü tasarıma neden olabilecek başlıca 3 unsur gösterilir.
Sistemin genişletilebilir olmaması ve bunun beraberinde binlerce satırlık sınıflar, kendini tekrar eden metotlar ve Unit testlere (özellikle tightly coupled yüzünden) elverişli olmaması da en büyük sebeplerden birkaçıdır.
Hiçbir tasarım prensiplerine uyulmamasının da kötü bir tasarım belirtisi olduğu gibi yerli yersiz kısımlarda da bu prensiplere uydurulma çabası ile atılan taklalarla over architecture’a kaçılması da kötü bir tasarım belirtisidir.
Bu makalemizde tasarım nedir, iyi tasarımın belirtileri ve kötü tasarımın belirtilerini ele almış olduk. Gelecek makalelerimde ise başlıca tasarım prensiplerini örneklerle anlatıyor olacağım. 🙂
{:tr} Makalenin ilk bölümünde, Software Supply Chain güvenliğinin öneminden ve containerized uygulamaların güvenlik risklerini azaltabilmek…
{:tr}Bildiğimiz gibi modern yazılım geliştirme ortamında containerization'ın benimsenmesi, uygulamaların oluşturulma ve dağıtılma şekillerini oldukça değiştirdi.…
{:tr}Bildiğimiz gibi bir ürün geliştirirken olabildiğince farklı cloud çözümlerinden faydalanmak, harcanacak zaman ve karmaşıklığın yanı…
{:tr}Bazen bazı senaryolar vardır karmaşıklığını veya eksi yanlarını bildiğimiz halde implemente etmekten kaçamadığımız veya implemente…
{:tr}Bildiğimiz gibi microservice architecture'ına adapte olmanın bir çok artı noktası olduğu gibi, maalesef getirdiği bazı…
{:tr}Bir önceki makale serisinde Dapr projesinden ve faydalarından bahsedip, local ortamda self-hosted mode olarak .NET…
View Comments
Merhaba, "yerli yersiz kısımlarda da bu prensiplere uydurulma çabası" kısmına bir örnek vermeniz mümkün mü?
Over architecture için en basitinden OCP prensibinden örnek vermek gerekirse ilgili linkteki https://gokhan-gokalp.azurewebsites.net/open-closed-principle-ocp-acik-kapali-prensibi/ eğer tek bir Circle'nin alanını hesaplamaya ihtiyacımız varsa iş kurallarımıza göre (Önceden belirleniyor iş kurallarımız) kalkıpta bunu hemen daha sonra farklı alanda gelir diyerekten dallandırıp budaklandırmanın da anlamı bulunmuyor. :) Unutmayalım, prensipleri veya desenleri kullanırken geleceği tahmin etmek yerine ilgili iş kurallarımız düzeyinde uygulanınca zaten kendiliğinden desenler çıkıyor. Size burada YAGNI (You ain't gonna need it) prensibini bir araştırmanızı öneririm. :)