Tasarım Deseni ile Yazılım Mimarisi Kavramları - Farkları ve İlişkileri Nedir?

1

Arkadaşlar bu iki kavram hakkında okumalar yaptım çeşitli kaynaklardan. İçinizde profesyonel olarak yazılım geliştiren, tasarım deseni ve mimari kalıplara uyan birisi şu konuyu biraz açıklayabilirse çok sevinirim.

Bir çok kaynakta tasarım desenleri [1, 2] anlatılmış fakat çok soyut olduğu için aklımda pek bir şey canlandıramadım.

Bir de çeşitli kaynaklarda bahsedilen yazılım mimarileri var [1, 2].

Bir yazılım geliştirirken bu kalıplara uyduğumuzda bazı avantajlarımız oluyor. İki kavramı da okuduğumda şu sonuçlara varıyorum

  • Projemizde oluşabilecek hatalara daha kolay müdahale edilebilir,
  • Projemize başka kişiler daha kolay destek verebilir (Proje yapısının daha anlaşılır olması ve kod okunabilirliği açısından)
  • Projemizde daha küçük ve kolay yönetilebilir yapılar meydana gelir (paketler, sınıflar, iletişim sağlayan aracı sınıflar vs.)
  • İleriki süreçte projenin büyümesi ya da güncellenmesi gibi süreçler daha kolay yürütülebilir
    vs. vs.

Mesela MVC, MVVM gibi mimariler var. Özellikle son zamanlarda Flutter/Dart ile mobil uygulama geliştirirken kullanılan BLoC deseni var. Bunlara baktığımda farkını tam olarak anlayamıyorum. Kaynaklarda BLoC Pattern diye geçiyor fakat tasarım desenlerine baktığımda içinde BLoC Pattern diye bir başlık göremiyorum. BLoC Pattern sanırım bir yazılım mimarisi. Yazılım mimarileri konularına baktığımda yine BLoC Pattern başlığını göremiyorum. Belki de yeni bir teknik olduğu için görünmüyordur.

Anlamak istediğim konu şu, tasarım deseni ile yazılım mimarisinin ilişkisi ne, farkı ne? Hangisi hangisini kapsar? Bu kalıplara göre yazılım geliştiren var mı içinizde? Biraz tecrübelerinizi paylaşır mısınız? Kirli kod yazmaya alışmak istemiyoruz.

Teşekkürler.

Düzenleme:
Yukarıdaki kavramlar haricinde bir de yazılım geliştirme modelleri isimli bir kavram daha mevcut. Bunun diğerlerine göre farkı net anlaşılıyor onun için sormadım.
Çalıştığı şirkette yazılım geliştirme modeli, tasarım deseni, yazılım mimarisi gibi çeşitli planları takip eden arkadaş varsa tüm bunlardan kısaca bahsederse sevinirim. Gerçek hayatta ne kadar uygulandığı ve gerekliliğini merak ediyorum.

2

Tasarim oruntuleri zaman icinde ortaya cikan seyler. Mesela OOP bir dilde tek kullanicili database’e veya bir dosyaya birden fazla yerden baglanmayi deneyen insanlari dusun. Aralarina yillar veya on yillar olabilir. Hepsi bir noktada “instance varsa dondur, yoksa yarat” kodunu yazacaklardir. Al sana singleton pattern.

Peki, iki database’e baglanip aralarinda is yapacak. Yazdik (db1 = DB1.getInstance(); db2 = DB2.getInstance();), yapti. Fakat ayni kodu baska database’ler ile nasil kullanacagiz? (Test icin mesela). Inversion of control problemi. Merkezi bir yere gidip “bana DB1 ver” dersek registry veya service locator (hep karistiriyorum), disaridan biri “setDB1Instance” cagirirsa dependency injection.

Peki bunlari yapmamiz icin kitap okumamiz gerekiyor mu? Hayir. (En azindan kolay olanlarini.) Yeterince miktarda deneyimli koda baktiginda kaosun icinde gorebiliyorsun. Bu yuzden “desen”/“oruntu” deniyor zaten. Bir sure/miktar sonra kendiliginden ortaya cikiyorlar.

Oyun tasarladigini dusun. Bir noktada oyuncuyu yonlendirmek icin karakterlerden biri ondan bir sey istiyor. Biri cikip “bu ‘quest pattern’” (‘gorev oruntusu’) diyor, daha once yuzlerce oyunda gormus…

Avantaji, artik bir ismi oldugu icin internette hakkinda yazilmis makale arayabiliyor, diger oyun tasarimcilariyla tartisabiliyorsun. Mesela biri “ikiden fazla gorev varsa ve sureleri toplami 30 dakikayi geciyorsa oyuncular dagiliyor, bir listede gostermen lazim” diyor; arastirma yapmislar. “Quest log” veya “journal pattern” adi vermisler…

Bu arada bir suru kisinin yaptigi benzer hatalar da oruntu olusturuyor, yeterince kod incelersen. Mesela burada bir cok kez yeni baslayanlarin her seyi tek bir fonksiyona (veya daha kotusu, modul seviyesine) tiktiklarini goruyorum. Kafamda hikaye yaratacak kilit noktalar olmadigi icin okumakta zorlaniyorum. Kimisi kendi koduna baktigina ayni zorlugu yasadigi icin “######### UI kismi #########” gibi comment’lerle ayiriyor. Bu insanlar genelde iyi ogrenen, becerikli insanlar olmalarina ragmen bu yazdiklari kotu bir pattern. (“Anti-pattern” da diyorlar.)

“aib’in okuyamamasi” yeterince iyi bir sebep degilse arama yapabiliyorsunuz: “long function antipattern”. Belki baskasinin yazdigi bir sey ikna eder.

Dogrusu, kod bloklarini guzel isimlendirilmis fonksiyonlara ayirmak:

def eviTemizle():
  temizlikMalzemeleriniAl();
  odalariTemizle();
  mutfagiTemizle();
  banyoyuTemizle();

Bu arada, sadece baska fonksiyonlar cagiran fonksiyon da bir pattern. Cok yaygin olmasa da, dikkat ceken bir sey. Bence iyi bir pattern, ama belki birilerine gore veya kimi durumlarda anti-pattern’dir.

Yazilim mimarileri de bir nevi pattern, fakat daha buyuk seviyede. Biraz daha kilavuzlu, kitabina gore takip edilmesi gereken oruntuler. Buyuk ve komplike olduklari icin icinde kendi kendilerine olusmalari zor; daha cok arastirma/gelistirme sonucu olarak ortaya cikiyorlar. O yuzden “oruntu” demiyoruz…

Ayakustu, bir defada bu kadar cikti. Belki sonra devam ederiz.

5 Beğeni
3

Araçtaydım cevap yazamadım. Vakit ayırıp tecrübelerinizi paylaştığınız için teşekkür ederim.

Düzgün kod yazma alışkanlığını sadece kod yazarak deneyimleme yöntemiyle mi kazandınız yoksa çalıştığınız ekipte belirlenmiş desen/mimarilere bağlı kalmak zorunda kaldığınız oldu mu?

Sizin yazdıklarınızdan anladığım şu; profesyonel bir geliştirici her halükarda düzgün, anlaşılır, kullanışlı kod yazacaktır. Bunu yaparken hazır patternleri/mimarileri de kullanılabilir, kendi tecrübesi neticesinde oluşturduğu kişisel bir pattern de kullanabilir.

İlk etapta az tecrübeye sahip olduğumuz için küçük projelerimizi hazır pattern/mimarilere uyarlayarak geliştirmek düzgün kod yazma alışkanlığı kazanma adına faydalı olacak diye düşünüyorum.

4

Tabi ki oldu.
Kisinin sadece kendi kendine ogrenmesi de mumkun, fakat fikrine saygi duyulabilecek herhangi biri, bir noktada, bir sure, diger insanlarla beraber calismanin cok daha faydali olacagini soyleyecektir.

Mesela kitap okuyarak, calisarak, egzersiz yaparak cok iyi bir Go oyuncusu olmak mumkun. Fakat daha az calisip, bir suru insanla oyun oynayan birinden daha hizli olunacagini zannetmiyorum.

Duzgun kod yazma aliskanligina sahip oldugumdan emin degilim. Oyle oldugunu umuyorum.

Degisen paradigmalara, beraber calisilan programcilara da ayak uydurmak lazim. 2000’lerin baslarinda “her sey obje, her yer OOP” mentalitesi hakimdi. (Ilk nesil yazilim muhendisligi okullarinin OOP ogretmesi, piyasadaki bir suru yeni programciyi ise almanin en kolay yolunun OOP dillerin kullanilmasi oldugu icin boyle oldugunu dusunuyorum.) O noktada cikip functional kod yazan birinin iyi bir programci oldugunu, veya duzgun kod yazdigini soyleyebilir miyiz? Veya bugun cikip bir fonksiyona λx: x + 1 yerine new IntegerIncrementor() paslasak olur mu? (Cevap: Soyleyemeyiz, olmaz)

Bu arada, su aralar, bagli kalinmak zorunda olunan mimarileri benim belirledigim (mimari takimi olarak bizim belirledigimiz) daha cok oluyor.

Oruntuler dedigim gibi daha kisa kapsamli oldugu icin “bagli kalmak” fiili dogru durmuyor. Bir problemi cozmek icin fikir sordugumda “X pattern’i bu is icin bicilmis kaftan sanki” cevabi almak, veya daha yeni arkadaslara “burada Y pattern’ini kullan bence” demek daha yaygin sanki.

Veya code review esnasinda “sunu soyle degistirsen bir tik daha okunur olur”, “bunu bak asagidaki z ile beraber paslarsan kod biraz daha kisalir” gibi tavsiyeler verdikten sonra, hepsine uyulsa/uyuldugunda X pattern’i olusacagini/olustugunu gormek de basima gelen bir sey. Zaten bu yuzden “pattern”.

Malesef “her halukarda” degil, ama evet.

Belki etimolojiye girecek ama, “kisisel pattern” oksimoron sanki. Bir suru insanin birbirinden bagimsiz, habersiz bir sekilde ayni/benzer olarak yaptiklari sey “pattern”. Veya buyuk miktarda kod incelendiginde arada bulunan benzerlikler “pattern”. “Kisisel pattern”, kisinin yillar icerisinde tekrar tekrar kullandigi bir sey gibi duruyor. Iyi bir sey olmayabilir. Otomasyon icin guzel bir nokta ama.

Pattern’lari okumak, bilmek, yeri geldiginde fark edip kullanmak cok onemli bir ozellik. (Mimariler de keza.)

Bu arada, state machine’in ne oldugunu bilmeyen birinin yazdigi neredeyse state machine kodunu okumak cok aci veren bir sey.

3 Beğeni