Picproje Elektronik Sitesi

MİKRODENETLEYİCİLER => Diğer => Konuyu başlatan: volkanunal - 02 Eylül 2020, 11:44:44

Başlık: Gömülü Yazılım ve Tasarım Kalıpları
Gönderen: volkanunal - 02 Eylül 2020, 11:44:44
Merhabalar, şu şekilde bir kitap mevcut.

Design Patterns for Embedded Systems in C isminde, sizlere sormak istediğim şu. Kendi yazılım projelerinizde tasarım kalıplarını ne kadar kullanıyorsunuz ? bu konuda görüşlerinizi merak ediyorum.

Görüşlerini belirten tüm arkadaşlar için çok teşekkür ederim, kolay gelsin.
Başlık: Ynt: Gömülü Yazılım ve Tasarım Kalıpları
Gönderen: muhittin_kaplan - 02 Eylül 2020, 20:43:25
Sırf cleancode ve Design patern için kitaplar aldım, okudum uyguladım. Ama nedense bende davranış değişikliği oluşturmadı.Olmuyor, alışılmış yerden yürüyorsunuz
Başlık: Ynt: Gömülü Yazılım ve Tasarım Kalıpları
Gönderen: tunayk - 02 Eylül 2020, 21:12:18
Yazdığınız yazılım sizde başlayıp siz de bitiyor ise, buna çok takılmaya gerek yoktur. Uygularsanız faydanıza olur elbetteki. Ama bu kalıpları uygulamadan yazılmış yazılım kötüdür anlamına da gelmez.

Bir yazılımcı olarak bir ekibin parçasıysanız işte o zaman işler değişir.  O ekibin ortak hareketi için belli başlı kalıplar üzerinde mütabık olmaları şarttır.

Başlık: Ynt: Gömülü Yazılım ve Tasarım Kalıpları
Gönderen: mylord92 - 02 Eylül 2020, 21:14:50
Biz iş yerinde mecburen kullanıyoruz. Clean codedan ziyade tekrar kullanılabilir olması önemli. 5-6 noktada argemiz var ve kodları olabildiğince ortak kullanmaya çalışıyoruz. Kendi yazmış olduğumuz bir framework mevcut. O framework üzerinde diğer argeler cihazlarına uygun yazılımları geliştiriyorlar. Framework'e ait devicelar, middlewarelar haliyle ortak ve cihaz spesifik olmaktan uzak olmalı.

Bunun ne gibi bir artısı var;
- Bir argenin yazdığı bir device(devicetan kastımız misal bir linear interpolasyon algoritması olabilir, timeout algoritması olabilir vs.) veya middleware veya mcu spesifik driverlar başka bir argede ihtiyaç duyulduğunda tekrar yazılmasına gerek kalmıyor. İş gücü kazancı.
- Framework belli olduğundan hangi algoritma nereye ne şekilde bağlanmalı hızlıca anlayabiliyorsunuz.
- Okunabilirlik ve dökümante edilebilirlik artıyor. Arge süresini azalttığı için aslında yazdığınız aplikasyonu dökümante edecek zamanı buluyorsunuz.

Mutluluk kaynağı adeta :P

İş harici kendi uğraştığım şeylerde ne sıklıkla kullanıyorum diye sorarsan sanırım hiç yada çok az. Geri dönüp baktığımda geçmişten bu yana kullandığım ortak kodlar neredeyse yok.
Başlık: Ynt: Gömülü Yazılım ve Tasarım Kalıpları
Gönderen: PhD - 02 Eylül 2020, 22:25:03
GitHup ve benzeri programlar tamda bu iş için ancak keşke uygulayabilsem..
Başlık: Ynt: Gömülü Yazılım ve Tasarım Kalıpları
Gönderen: Erol YILMAZ - 02 Eylül 2020, 23:28:49
Bircok yazilim yaptiktan sonra artik bu yazilimlari takip edemeyecegimi farkettim.
Sonucta biz bu konularda yeniyiz. Compiler in yazildigi ulkede bu isler nasil donuyor diye arastirmaya basladiktan sonra,
"Design pattern" konusuyla tanistim.
Ve hemen o andan itibaren yazilimlarimdaki iyi yonleri bir sablon haline getirmeye basladim. Eksik olan yerleri de zamanla topladik. 12 senedir bunu kullaniyoruz.
Ve en ciddi avantaji olarak, hata yapmamizi buyuk oranda engelliyor.
Başlık: Ynt: Gömülü Yazılım ve Tasarım Kalıpları
Gönderen: z - 03 Eylül 2020, 01:17:36
Cocuklar muhakkak lehim yapmayi ogrenebilirler fakat dikkatsizlik sonucu yangin cikartabilirler, kendilerini yakabilirler.

Lisedeyken havya ile kolumu yaktim. Masadaki elimi yumruk yapip cenemin altina koyarken pazu ve kol birbirine yaklasiyor ya iste tam o araya havyanin isinan kismi denk geldi ve kolumla havyayi o araya sikistirdim.

Aptalca bir kaza.

Başlık: Ynt: Gömülü Yazılım ve Tasarım Kalıpları
Gönderen: tunayk - 03 Eylül 2020, 01:30:10
Alıntı yapılan: z - 03 Eylül 2020, 01:17:36Cocuklar muhakkak lehim yapmayi ogrenebilirler fakat dikkatsizlik sonucu yangin cikartabilirler, kendilerini yakabilirler.

Lisedeyken havya ile kolumu yaktim. Masadaki elimi yumruk yapip cenemin altina koyarken pazu ve kol birbirine yaklasiyor ya iste tam o araya havyanin isinan kismi denk geldi ve kolumla havyayi o araya sikistirdim.

Aptalca bir kaza.



Sanki yanlış konuya gelmiş bu mesaj  :)
Başlık: Ynt: Gömülü Yazılım ve Tasarım Kalıpları
Gönderen: brandice5 - 03 Eylül 2020, 17:52:31
Ben de bisiklet surerken pesime kopek takilmisti. Kopekten kacmak icin daha hizli sureyim derken cakil yolda bisiklet kaydi ve dustum. Dustugumu goren kopek kosarak uzaklasti.

Bu da boyle bir animdir.

Tasarim kaliplarina gelirsek, bunu hakkiyla kullanabilmek icin C++ gibi object oriented bir dil kullanmak gerekli.
Gomulu sistemlerde C hala yaygin sekilde kullanildigi icin, C ile yazdiginiz kodda cok verim alacaginizi sanmiyorum.
Başlık: Ynt: Gömülü Yazılım ve Tasarım Kalıpları
Gönderen: kantirici - 04 Eylül 2020, 00:52:38
Gömülü sistem mühendisi unvanı ve aramaları gittikçe azalıyor, yerini gömülü yazılım mühendisi unvanı ve unvanın beklentileri alıyor. Bu noktada biz elektronik kökenli yazılımcılar olarak en büyük eksiğimiz algoritmalar, bilgisayar organizasyonu, veri yapıları, tasarım desenleri ve prensipleri gibi konular karşımıza çıkıyor.

Bence tasarım kalıpları ve prensipleri oldukça önemli. Ne kadar bilinirse o kadar iyi tabi uygulamak ve benimsemek önemli.

C dilinde nesne yönemli programlama yapılabilmekte ve tasarım desenleri uygulanabilmekte.

32 bit mcu'ların yaygınlaşması ve donanım kaynaklarının artmasıyla çoğu gömülü sistemlerde artık "trick"'li yazılım, elle yapılan optimizasyonlara v.b ihtiyaç azalıp bunların yerini anlaşılır ve esnek yazılım aldı. HAL altyapılarının hazır sunulmasıyla da programlarda "business logic" katmanı tamamen bağımsız bir şekilde geliştirilebiliyor.

Konu özelinde TDD(Test Driven Dev.) konusu da yazılımı belirli kriterlere göre yazmayı gerektiriyor.

Kullanıcı elektroniğinin git gide cep telefonlarından kumanda edilmesi, internete çıkmaları gibi konularda gömülü sistemleri giderek karmaşıklaştırıyor. Bu noktada ise açık kaynak alt yapısı, pek çok platformu destekleyen kütüphane ve framworkler kaşımıza çıkıyor. Bu kaynaklar ise yukarıdaki yazılım kriterlerine göre yazılmış oluyorlar. Yani git gide gömülü sistem/yazımlar klasik yazılım Dünyası ile iç içe geçiyor. Bu geçiş ise bizlere o Dünyayı keşfetmeyi oranın raconuna uymayı gerektiriyor.

Son olarak gömülü sistemlerde (mcu tabanlı) c++ yaygınlaşıyor, rust da C'ye alternatif olarak öenmli bir oyuncu gibi.

Biraz uzun oldu ama konular birbirlerine bağlı olduğundan görüşlerimi paylaşmak istedim.
Başlık: Ynt: Gömülü Yazılım ve Tasarım Kalıpları
Gönderen: volkanunal - 04 Eylül 2020, 08:34:19
Alıntı yapılan: mylord92 - 02 Eylül 2020, 21:14:50Biz iş yerinde mecburen kullanıyoruz. Clean codedan ziyade tekrar kullanılabilir olması önemli. 5-6 noktada argemiz var ve kodları olabildiğince ortak kullanmaya çalışıyoruz. Kendi yazmış olduğumuz bir framework mevcut. O framework üzerinde diğer argeler cihazlarına uygun yazılımları geliştiriyorlar. Framework'e ait devicelar, middlewarelar haliyle ortak ve cihaz spesifik olmaktan uzak olmalı.

Bunun ne gibi bir artısı var;
- Bir argenin yazdığı bir device(devicetan kastımız misal bir linear interpolasyon algoritması olabilir, timeout algoritması olabilir vs.) veya middleware veya mcu spesifik driverlar başka bir argede ihtiyaç duyulduğunda tekrar yazılmasına gerek kalmıyor. İş gücü kazancı.
- Framework belli olduğundan hangi algoritma nereye ne şekilde bağlanmalı hızlıca anlayabiliyorsunuz.
- Okunabilirlik ve dökümante edilebilirlik artıyor. Arge süresini azalttığı için aslında yazdığınız aplikasyonu dökümante edecek zamanı buluyorsunuz.

Mutluluk kaynağı adeta :P

İş harici kendi uğraştığım şeylerde ne sıklıkla kullanıyorum diye sorarsan sanırım hiç yada çok az. Geri dönüp baktığımda geçmişten bu yana kullandığım ortak kodlar neredeyse yok.

Örnek vermeniz mümkünse nasıl bir senaryoda hangi tasarım kalıbına nasıl bir ihtiyaç oluştu hocam, örnek vermeniz mümkün müdür ?
Başlık: Ynt: Gömülü Yazılım ve Tasarım Kalıpları
Gönderen: volkanunal - 04 Eylül 2020, 08:35:19
Alıntı yapılan: brandice5 - 03 Eylül 2020, 17:52:31Ben de bisiklet surerken pesime kopek takilmisti. Kopekten kacmak icin daha hizli sureyim derken cakil yolda bisiklet kaydi ve dustum. Dustugumu goren kopek kosarak uzaklasti.

Bu da boyle bir animdir.

Tasarim kaliplarina gelirsek, bunu hakkiyla kullanabilmek icin C++ gibi object oriented bir dil kullanmak gerekli.
Gomulu sistemlerde C hala yaygin sekilde kullanildigi icin, C ile yazdiginiz kodda cok verim alacaginizi sanmiyorum.


Bu görüşünüze katılmıyorum hocam, bu konu için yukarda bahsettiğim kitabi incelemenizi tavsiye ederim.
Başlık: Ynt: Gömülü Yazılım ve Tasarım Kalıpları
Gönderen: brandice5 - 04 Eylül 2020, 12:08:42
@kantirici ya cevaben, benim zaten C de OOP yapilamaz gibi bir iddiam yok, zamaninda benimde kullanmisligim var AMA ingilizce tabiriyle "feasible" degil.

@volkanunal a cevaben, kitabi inceledim ve bunun verimli olmadigi gorusumde hakli oldugumu gordum.
cunku C de DP uygulamak icin hem DP hem de OOP implementasyonuyla ugrasmaniz gerek, yani iki kat is yuku ve iki kat hata orani.

adam sadece bir object yaratmak icin malloc ile bellek ayirip ustune birde init fonksiyonu cagiriyor. polymorphism icin switch kullanmis. subclassing ve virtual function implementasyonuna hic girmiyorum bile, tamamen copluk.

calistiginiz platform sadece C derleyici destekliyorsa (ki boyle olsa bile yukaridaki sebeplerden ben yine tercih etmezdim) kullanmakta ozgursunuz ama C++ ile DP yapmak varken C ile tirmalamak gereksiz ve zaman kaybi.
Başlık: Ynt: Gömülü Yazılım ve Tasarım Kalıpları
Gönderen: AsHeS - 04 Eylül 2020, 17:15:46
Alıntı yapılan: brandice5 - 04 Eylül 2020, 12:08:42@kantirici ya cevaben, benim zaten C de OOP yapilamaz gibi bir iddiam yok, zamaninda benimde kullanmisligim var AMA ingilizce tabiriyle "feasible" degil.

@volkanunal a cevaben, kitabi inceledim ve bunun verimli olmadigi gorusumde hakli oldugumu gordum.
cunku C de DP uygulamak icin hem DP hem de OOP implementasyonuyla ugrasmaniz gerek, yani iki kat is yuku ve iki kat hata orani.

adam sadece bir object yaratmak icin malloc ile bellek ayirip ustune birde init fonksiyonu cagiriyor. polymorphism icin switch kullanmis. subclassing ve virtual function implementasyonuna hic girmiyorum bile, tamamen copluk.

calistiginiz platform sadece C derleyici destekliyorsa (ki boyle olsa bile yukaridaki sebeplerden ben yine tercih etmezdim) kullanmakta ozgursunuz ama C++ ile DP yapmak varken C ile tirmalamak gereksiz ve zaman kaybi.

Design paternlerinden kastiniz Gang of Four kitabinda ki ise tumunu zaten uygulayamiyorsunuz. Ekseri olarak bir yazilimci en fazla 5 tanesinde uzmanlasiyor kariyer hayatinda. Diger yandan, is mimari kurup yazilim yapinizi oturtmak ise zorunlulugunuz, bu paternlerle kisitli kalmayin. En guzel ornegi Linux Kernel (tamamiyle C) kaynak kodudur. Mimarisi gavur dilinde "state-of-art" yani sanat eseridir. Binlerce farkli sisteme, cipe, yaklasima hizmet vermektedir.

Dizayn paternleri kitabi da zaten en cok kullanilan 20'den fazla paterni ortaya koymaktadir. Ustunu sizde tasarlayip kullanabilirsiniz.

Simdi gelelim C++ embedded ici uygunluguna bu konuda cok cevap duyarsiniz. Olur, olmaz, deneriz, yer yarilsa olmaz, guzel olur vs... Dananin kuyrugunun koptugu yer eger dolu dolu object-oriented yazacaksaniz dinamik hafizaya ihtiyaciniz var. Bunu yapmak icinde evvela hafizaya daha sonra ise islem gucune ihtiyaciniz var.
Ornek vermek gerekirse 8kb ROM lu 256 byte RAM li bir PIC16 da bu islemi yapmak ne kadar makul dusunulur. Arduino ile genelde karsi ornek uretilir bu duruma lakin Arduino ile ne kadar zaman hassasiyeti saglayabilirsiniz ne kadar karmasik bir sistem uretebilirsiniz her zaman soru isaretidir. Gelelim en karmasik cevaplarin yerildigi yere yeni nesil Cortex M serilerine. RAM i ROM u nispeten buyuk dinamik hafiza kullanabileceginiz islem gucu nispi oranda yuksek atlara :). Acikcasi dinamik hafiza kullanmak, yonetmek her zaman ek bir sorumluluktur. Yaziliminizin karmasikligina gore profilleme (profiling) denilen sistem seviyesinde kim ne yapiyor diye izlemeniz (tracing) gerekiyordur. Bu tarz durumlarin yol actigi hatalari yakalamak her zaman lineer olmayan bir akista zordur. Burada yol catallanir aslinda 1. yontem goz yordamiyla inceleyip bulabilirsiniz. 2. yontem para dokersiniz ek araclara ornegin; statik kod analizi, dinamik kod analizi gibi araclara. Bunlarin iyisi gercekten iyi paraya satilir. Open-source olanlari nispeten ufak bir kodda dertlerinizi yasamadan ortaya cikarir ama biraz isler karisinca onlarinda gozunden kaciverir.

@kantirici bahsettigi TDD metodu her zaman zorlu bir metoddur. Dizayninizi yaparken once testlerini hazirlayip ciktilarinizi kesin olarak belirleyip tasarima gecmenizi "force" eder. Insan kaynaginin coklugu/azligina gore uygulanabilir.

Sonuc olarak; C her zaman pseudo-assembly dir :). Iyi bir mimari ile cok sorununuza care bulunabilinir. En buyuk ornegi icin Linux Source Code a bakabilirsiniz. 
Başlık: Ynt: Gömülü Yazılım ve Tasarım Kalıpları
Gönderen: LukeSkywalker - 04 Eylül 2020, 17:42:08
Her zaman driver yazan birilerine ihtiyaç olacak. Firmaların hal kütüphanelerini öğrenip bunlar üzerinde yüksek seviye proje geliştirmek, işlemcileri register seviyesinde kodlamaya göre nispeten kolaydır ve insanoğlu kolaylığa çabuk alışır. Özellikle 32 bit mcularda geliştirilen katmanlarla kod yazarken işlemciden bağımsız kod yazmak aşırı alışkanlık yapıcı. Bu kötü birşey değil aslında fakat elektronikçiler yine de işlemcilerin datasheetleriyle haşır neşir olmayı bırakmamalı. En azından yeni çıkan mcuların dökümanlarına göz gezdirmeli arada sırada. Gün gelir lazım olur. ELAN isimli mcu çok cazip mesela fiyatıyla.
Başlık: Ynt: Gömülü Yazılım ve Tasarım Kalıpları
Gönderen: mylord92 - 05 Eylül 2020, 17:26:43
Alıntı yapılan: volkanunal - 04 Eylül 2020, 08:34:19Örnek vermeniz mümkünse nasıl bir senaryoda hangi tasarım kalıbına nasıl bir ihtiyaç oluştu hocam, örnek vermeniz mümkün müdür ?

Sürekli bir maliyet iyileştirme, yeni ürün çalışmalarının olduğu bir senaryoda tekrar kullanılabilir kodlar önem kazanıyor. Örneğin bugün X üreticisinin ürettiği bir mcu ile yaptığımız işi yarın daha ucuz diye Y üreticisinin ürettiği bir mcu ile yada yine X üreticisinin ürettiği ama farklı bir seri mcu ile yapmamız gerekebiliyor. Bu noktada tüm mcu driverlarını tekrar taşımak yerine yazdığımız frameworkün port dosyalarını yeni mcu ya göre doldurarak ve kodun aplikasyon tarafında hiç bir değişiklik yapmadan kullanıyoruz. Hatta iş öyle bir noktada ki mcu modelleri için port dosyalarınıda framework içine işliyoruz ve definelar ile kullanacağımız mcuyu belirterek sürücülerini dahil ediyoruz :)

Katmanları şöyle düşünebilirsin;

1) Mcu Sürücüleri
2) Framework IO, COM, Complex veya Memory sürücüleri
3) Gerekliyse 2 numarayı bağlayabileceğimiz algoritmalar.(Örneğin IO için bir debounce modülü, ADC için ortalama alan bir modül, optimizasyon veya kestirim modülleri vs.)
4) Middleware
5) Aplikasyon

Hiyerarşik olarak her katman bir altı veya bir üstü ile konuşabilir. Bu hiyerarşi kırılmadığı sürece oldukça esnek bir geliştirme ortamı sağlıyor.

Dezavantajı nedir diye sorarsan belki birkaç kB kadar kodun boyutunu arttırıyor olabilir.
Başlık: Ynt: Gömülü Yazılım ve Tasarım Kalıpları
Gönderen: volkanunal - 06 Eylül 2020, 12:17:53
Alıntı yapılan: mylord92 - 05 Eylül 2020, 17:26:43Sürekli bir maliyet iyileştirme, yeni ürün çalışmalarının olduğu bir senaryoda tekrar kullanılabilir kodlar önem kazanıyor. Örneğin bugün X üreticisinin ürettiği bir mcu ile yaptığımız işi yarın daha ucuz diye Y üreticisinin ürettiği bir mcu ile yada yine X üreticisinin ürettiği ama farklı bir seri mcu ile yapmamız gerekebiliyor. Bu noktada tüm mcu driverlarını tekrar taşımak yerine yazdığımız frameworkün port dosyalarını yeni mcu ya göre doldurarak ve kodun aplikasyon tarafında hiç bir değişiklik yapmadan kullanıyoruz. Hatta iş öyle bir noktada ki mcu modelleri için port dosyalarınıda framework içine işliyoruz ve definelar ile kullanacağımız mcuyu belirterek sürücülerini dahil ediyoruz :)

Katmanları şöyle düşünebilirsin;

1) Mcu Sürücüleri
2) Framework IO, COM, Complex veya Memory sürücüleri
3) Gerekliyse 2 numarayı bağlayabileceğimiz algoritmalar.(Örneğin IO için bir debounce modülü, ADC için ortalama alan bir modül, optimizasyon veya kestirim modülleri vs.)
4) Middleware
5) Aplikasyon

Hiyerarşik olarak her katman bir altı veya bir üstü ile konuşabilir. Bu hiyerarşi kırılmadığı sürece oldukça esnek bir geliştirme ortamı sağlıyor.

Dezavantajı nedir diye sorarsan belki birkaç kB kadar kodun boyutunu arttırıyor olabilir.

Bu bahsettiğiniz yapıya bir tasarım kalıba demek mümkün müdür hocam ?
Yani siz callbackler ile aslında bir donanım soyutlama yapıyorsunuz diye düşündüm ben ya da makrolar ile işlemci ailesine göre bir derleme yapıyorsunuz. Bu durumda bir çok 3.parti kütüphane tasarım kalıbı oluyor. Bence bahsettiğiniz yapı ile tasarım kalıbı arasında ince bir çizgi var.
Başlık: Ynt: Gömülü Yazılım ve Tasarım Kalıpları
Gönderen: berat23 - 06 Eylül 2020, 14:50:53
design patterns, object oriented vs. bunları tek başına teknik olarak yorumlayıp, bir sonuca varmanız olası değil. teknik olarak bakarsanız tamamı gereksiz, kodu büyüten, yavaşlatan, geliştirmeyi zorlaştıran yapılar. ama kazın ayağı öyle değil.

işe biraz daha proje bakışıyla bakarsanız, yani büyük bir işi en hatasız, çok geliştiriciyle harmonik biçimde, yenliklere ve başka gözlere açık biçimde geliştirmelisiniz. profesyonel kod, gayet anlaşılır, belirli kalıplarda ve iyi dokümante olmalıdır. sadece geliştiricisi anlayabiliyorsa isterse harikalar yaratsın o aslında "bitirme projesidir". metrik olarak bilemem ama 2-3 geliştiricinin yaptığı bir projede böyle süreçlere elbette gerek olmayabilir. ya da piyasa tipi gömülü sistemler(endüstüriyel kontrol vs.) için framework vs. fazla maliyetli olur.  ama o kodun üzerinde 20 kişi çalışıyorsa bunları ancak aynı şekilde geliştirterek harmonize edebilirsiniz.
Başlık: Ynt: Gömülü Yazılım ve Tasarım Kalıpları
Gönderen: Erol YILMAZ - 07 Eylül 2020, 14:12:05
İlla ki büyük projeler düşünmek gerekmiyor bence,

Bir kodun sistematik şekilde, belli bir şablon üzerinden yazılması birçok avantaj sunacaktır.

Mcu'da kod yazmanın, kalemle çizgi çizmek olduğunu varsayalım...
Peki cetvel ile kalem bir araya gelirse neler olur? Konu yürümeye başlar...
Başlık: Ynt: Gömülü Yazılım ve Tasarım Kalıpları
Gönderen: brandice5 - 07 Eylül 2020, 14:36:29
Ingilizcede "overengineering" denen bir kavram var.

https://en.wikipedia.org/wiki/Overengineering

Alıntı yapılan: undefinedOverengineering (or over-engineering, or over-kill) is the act of designing a product to be more robust or have more features than often necessary for its intended use, or for a process to be unnecessarily complex or inefficient.

Yani Turkcesi

Alıntı yapılan: undefinedAşırı mühendislik bir ürünü amaçlanan kullanımı için genellikle gerekenden daha fazla özelliğe sahip veya daha sağlam olacak şekilde veya gereksiz şekilde karmaşık veya verimsiz olacak şekilde tasarlama eylemidir.

C ile design pattern yapmaya calismak tam olarak "overengineering" dir.

Bu konuda kitap yazilmis olmasi bunun dogru oldugu anlamina gelmez.
Başlık: Ynt: Gömülü Yazılım ve Tasarım Kalıpları
Gönderen: volkanunal - 08 Eylül 2020, 14:09:09
Alıntı yapılan: brandice5 - 07 Eylül 2020, 14:36:29Ingilizcede "overengineering" denen bir kavram var.

https://en.wikipedia.org/wiki/Overengineering

Yani Turkcesi

C ile design pattern yapmaya calismak tam olarak "overengineering" dir.

Bu konuda kitap yazilmis olmasi bunun dogru oldugu anlamina gelmez.


Mühendisliği yapıldıda overı kaldı hocam :)
Başlık: Ynt: Gömülü Yazılım ve Tasarım Kalıpları
Gönderen: LukeSkywalker - 08 Eylül 2020, 14:56:20
Overengineering deyince aklıma w124 geldi.
Başlık: Ynt: Gömülü Yazılım ve Tasarım Kalıpları
Gönderen: superconductor - 08 Eylül 2020, 15:27:15
Alıntı yapılan: brandice5 - 07 Eylül 2020, 14:36:29C ile design pattern yapmaya calismak tam olarak "overengineering" dir.

Bu konuda kitap yazilmis olmasi bunun dogru oldugu anlamina gelmez.

Mesela linux kernel aşırı mühendislik mi? Binlerce kişinin yıllardır geliştirdiği linux kernelde design pattern olmadan geliştirme yapıldığını düşünün..

https://lwn.net/Articles/336224/ (https://lwn.net/Articles/336224/)
Başlık: Ynt: Gömülü Yazılım ve Tasarım Kalıpları
Gönderen: brandice5 - 08 Eylül 2020, 18:13:05
@superconductor daha onceki mesajlarimi okumadiniz sanirim. ben sizin isinizi kolaylastirip buraya koyayim.

Alıntı YapTasarim kaliplarina gelirsek, bunu hakkiyla kullanabilmek icin C++ gibi object oriented bir dil kullanmak gerekli.
Gomulu sistemlerde C hala yaygin sekilde kullanildigi icin, C ile yazdiginiz kodda cok verim alacaginizi sanmiyorum.

Alıntı Yapcalistiginiz platform sadece C derleyici destekliyorsa (ki boyle olsa bile yukaridaki sebeplerden ben yine tercih etmezdim) kullanmakta ozgursunuz ama C++ ile DP yapmak varken C ile tirmalamak gereksiz ve zaman kaybi.

Birincisi, Linux kernel design pattern denen kavramin tanimlanmasindan daha once 1991 de C ile baslanmis ve hala C ile devam eden bir proje. Yukarida yazdigim gibi sadece C kullanilma gibi bir durum var. Ayrica adamlar o kodlari yazarken "dur surada su design pattern i kullanayim" diye yola cikmamis. Yani bilincli bir design pattern kullanimi yok.

Ikincisi aslinda bilincsiz bir design pattern kullanimi da yok. Linkini verdigin makalenin 3 partini da inceledim. Birinci partta "reference counting" anlatilmis. Bu C++11 den once bizimde kullandigimiz bir yontemdi, smart pointers eklentisinden sonra kendi implementasyonumuzu kullanmayi biraktik. Ikinci partta "linked list" anlatilmis, ucuncu partda da "function pointer".

Simdi bu "reference counting", "linked list" ve "function pointer" konularina ne kadar "design pattern" denir tartisilir. Ben design pattern deyince bir "factory" ya da bir "observer" patterni bekliyorum. O 3 parttan olusan makaleler daha cok RAII ve data structures konulari. Yine OOP a en yakin konu "function pointer" olmus ki bu da design pattern degil bir OOP implementasyonu.

Konuyu daha da uzatmak istemiyorum, isteyen istedigini kullansin.
Başlık: Ynt: Gömülü Yazılım ve Tasarım Kalıpları
Gönderen: kantirici - 08 Eylül 2020, 20:08:46
Aslında "tasarım desenleri" konusu konuşulunca akademik bir durum /kitabi bir bilgi/formül gibi geliyor insanın aklına. Özellikle nesne yönelimli dillerle geliştirilen yöntemlerin gerektirdiği dil özelliklerinden dolayı da sanki bu dillerin kullanımını mecburi kılıyor gibi düşünülüyor. Aslında bazı yöntemlerde evet zorunlu; mesela "state pattern".

Fakat tasarım desenlerinin tanımına baktığımızda "best practices" durumlarından başka şeyler değiller. Ayrıca herkes kendi "design pattern"ini geliştirebilir. Yani uygulanan yaklaşımın bir tasarım deseni olması için ille bir kitapta veya kaynakta gösterilmesi gerekmez. Siz bir yöntemi benimser ve bunu paylaşırsanız bu sizin adlandırdığınız bir tasarım kalıbı olur. Eğer gerçekten iyi bir yöntem/yaklaşım ise topluluk tarafından benimsenir ve kitaplara konu olur.

C ile tasarım desenlerini uygulamanın "aşırı mühendislik" olması durumu yukarıdaki tanımlarla daha iyi anlaşılıyor. Eğer siz C ile "state pattern" yapmaya çalışırsanız mantıklı olmayabilir. Fakat tasarım deseni kullanmak üzerinde yaklaşırsak sorun olmaz.