Bilgi İşlem Tasarım Kalıpları

Tasarım Kalıpları (Design Patterns) adı verilen akım, özellikle bilgi işlem yazılımcıları tarafından son yıllarda çok ilgi görmüştür. Bir tasarım kalıbı basit bir açıklama ile bir nevi reçetedir. Bu reçete, sürekli karşımıza çıkan bir sorun tipine karşı bulunmuş, gene sürekli verilmiş olan ve işe yarar bulunmuş bir çözümdür.

Yazının devamı için buraya tıklayın.

Görüşler

FZ
22 yıl önce

Konu ile ilgilenenlere birkaç güncel makale-tartışma adresi:

Design Patterns Still Aren't: A Pattern of Misunderstanding: Fetishizing the Gang of Four

http://perlmonks.org/index.pl?node_id=285065

Software Design Resources

http://perlmonks.org/index.pl?node_id=285637

mentat
22 yıl önce

hmm, cehaletimi bagislayin oncelikle, java'ci degilim.. ancak o yazida ben hic pattern goremedim. bazi isleri yapmak icin kullanilabilecek yontemler anlatilmis ama bunlar java dili ile ilgili degil, java kutuphanelerinden hangileriyle en dogru cozume ulasilabilecegi ile ilgili sanki. bir gariplik var sanki.

benim pattern'dan anladigim sey, dilin klasik deyimleri ile (nesne, inheritance, vs) cozumlenemeyecek islerin yine dilin kaliplari kullanilarak cozulmesi.

mesela singleton en basitinden. global member variable'dir kendisi ama biraz daha guvenli ve temiz bir kullanim getirir (duruma gore). ama dil disindan baska hicbir kutuphane vs kullanmazsiniz.

class SingletonFoo{
static SingletonFoo* m_pThis;
SingletonFoo();
~SingletonFoo();
public:
static const SingletonFoo* getInstance() {
if (!m_pThis) // bunu cpp'de 0'a esitledik
m_pThis = new SingletonFoo;
return m_pThis;
}
// buraya da non-static member funclar vs..
};

budur, mesela singleton..

neysem, benden onceki mesaji atan arkadasin da belirttigi gibi, pattern'lar konusunda bitmeyen bir tartisma da var. iyi mi kotu mu seklinde. ozellikle de GoF'un patternlarina karsi ciddi elestiriler mevcut. (adini hic bir zaman tam dogru yazamayacagim) Alexandriescu'nun da Modern C++ Design'di galiba kitabi ise ciddi saygi duyulasi bir baska kitap..

pattern nedir konusna donersek de, bazilarina gore veri yapilari bile bir pattern'dir (bence abarti biraz), kriter, dilin kendisi icinde olmamasi. (orn, yigit, kutuk, vs)

bir baska ilginc nokta da, gucunden pek suphe edilmeyen c/c++ pattern'lara muhtac iken, genelde parantez sayisiyla alay konusu olan Lisp'in pattern'lara ihtiyac duymayan, en ilerlemeye ve gelistirmeye acik dil oldugu gorusu..

neyse, sabah sabah daha fazla uzatmayayim..

bir de bir rica, patternlarin bence de en onemli islevi, yazilimcilar arasinda dil ve iletisim birligini saglamasi. o nedenle, siz de yazidaki pattern'larin turkce'lerinin yanina da en azindan ingilizcelerini ekleyebilirseniz parantez icinde, biz de daha iyi ogrenmis ve standart pattern'larin (inatla kalip demiyorum, dogru turkcesi oldugundan supheliyim) turkce isimlendirilmesini de saglamis olursunuz.

malkocoglu
22 yıl önce

Kaliplari, dil haricindeki alanlar icin de kullanabilirsiniz. Son zamanlarda revacta olan kalip kitaplari, teknoloji secimi, yazilim gereksinimleri analizi (requirement analysis) gibi konulara bile uygulanmaya basladi.

LISP hakkindaki yorumunuz ilginc.. Hakli olabilirsiniz. :)

Bilgi islem dunyasi bir bilim alani hala degil; Mesela karsilastiracak olsak, iliskisel veri tabanlarinin altinda kapi gibi matematiksel teori vardir, bir XYZ iliskilsel modelin 'dogrulugu' ispat edilebiliyor. Yazilim muhendisliginde bir nesnesel modelin dogrulugunu ispat edebiliyor muyuz? Bu soruya hala cevap hala hayir. Boyle gri bir alanda o yuzden zevkle ve renkler konusuyor, ya da tecrubeye dayali 'receteler'.

Kaliplari, bir onceki yazarin soyledigi gibi, cok buyutmemek lazim; Bizim takip ettigimiz kaliplarin 'formatidir'. Sunum tarzi olarak bilgi islem cozumleri icin kaliplarin uygun oldugunu dusunuyorum. Ayrica, baskalarinin kullandigi receteleri takip amaci ile de iyi olabiliyor. Template Method, Singleton, Observer kullanmasak bile, fikir olarak yararlandigimiz gorus acilari.

Iyi calismalar,

Görüş belirtmek için giriş yapın...

İlgili Yazılar

e-Bergi Eylül Sayısı Yayında

anonim
2 Eylül 2008, 1 dakika okuma süresi

e-bergi eylül sayısı çıktı. Hem de sizlerden gelen yoğun ilgi üzerine aylık programlama sorumuzun ikincisiyle!

rsync ile Windows makinelerin Debian/GNU Linux'a yedeklenmesi

ctengiz
16 Aralık 2004, 1 dakika okuma süresi

Uzunca bir süredir ağ içerisinde yer alan kullanıcılara ait MS Windows makinelerinin yedeklenmesi için bir çözüm arayışı içerisindeydim. Sistemin sahip olması gereken özellikleri şu şekilde sıralayabilirim :

Yedek makinesinin yönetimi kolay olmalı.
Sistem ağ üzerinden çalışmalı.
Yalnızca değişen dosyaları yedekleyecek kadar akıllı olmalı.
Çok fazla ağ trafiğine sebep olmamalı.
GNU/GPL yazılımlar ile minumum maliyete sahip olmalı.
Son kullanıcı için kullanımı kolay olmalı.
Kendi başına zamanlanmış yedekler alabilmeli.

Bu yazıda bu hedeflere nasıl ulaşılabilineceği anlatılyor.

Matrix ve Felsefe

FZ
31 Ocak 2003, 1 dakika okuma süresi

Sizin de kafanız Keanu Revees gibi Matrix'ten sonra karıştıysa bu kitap kesinlikle sizin için yazılmış. Eğer film kafanızı karıştırmadıysa, hemen bir doktora görünün. Matrix'i henüz seyretmediyseniz, o zaman bu kitabı mutlaka okumalısınız. Böylece bu filmin insanlar için neden o kadar önemli olduğunu bulursunuz.

Dünya ile Rekabet Edecek Zehir Gibi Bir Bilgisayar Şirketi Kurmak

FZ
9 Nisan 2005, 59 dakika okuma süresi

30 yıl maaşla çalışıp didinmek yerine zehir gibi bir bilgisayar şirketi kurup birkaç yıl geceli gündüzlü çalışıp çok zengin olmak... Herkese parmak ısırtacak çözümler sunmak... Rakipleri çatlatmak... İyi güzel ama nereden başlanır, nasıl başlanır? Ne gibi tehlikeler, tuzaklar vardır? Herkes o tür bir bilgisayar şirketi kurabilir mi? Bu işlere kaç yaşında başlanır? Şirketinize nasıl "hacker" seçersiniz? Peki ya parayı nereden bulacaksınız? Kısa sürede gelir elde etmeye nasıl başlarsınız? 100.000$ yeter mi? Ne kadar süreliğine? Geliştirdiği Viaweb'i birkaç yıl sonra Yahoo'ya 40.000.000$'a satan usta bir "hacker"ın deneyimlerini merak ediyor musunuz? O halde buyrun:

Bu belge Paul Graham'ın 2005 yılının Mart ayında yayınladığı "How To Start A Startup" başlıklı makalesinin çevirisidir. Çeviri Gülsün Arıkan tarafından gerçekleştirilmiş, son düzeltmeler Emre Sevinç ve Bülent Murtezaoğlu tarafından yapılmıştır. Paul Graham'a yazısının Türkçe çevirisini yayınlamamıza izin verdiği için teşekkür ederiz. Belgenin özgün adresi burasıdır.

Dil Üstadları ile Araç Ustaları: IDE Ayrımı

FZ
23 Aralık 2004, 1 dakika okuma süresi

Geliştirici dünyası iki kampa ayrılmıştır. Bir kampta dil üstadları vardır, bu yazılımcılar yüksek seviyeli programlamadan -- birinci-sınıf fonksiyonlar, aşamalı programlama, AOP, MOP, kendi kendini sorgulama -- bahsederler. Araç ustaları ise tümleşik geliştirme ve hata ayıklama araçlarında ustadırlar, kod tamamlama, "refactoring", vs. Dil üstadları Emacs ya da VIM kullanır, bu tür editörler yeni dilleri denemek için daha uygundur. Araç ustaları ise Visual Studio, Eclipse, IntelliJ gibi IDE'leri kullanırlar.

Laszlo ve Groovy gibi yeni diller ya da AOP (Aspect Oriented Programming) gibi dil uzantıları genellikle öncelikli olarak metin-editörü tabanlı yazılım geliştirme ortamlarında ortaya çıkarlar ve ancak ondan bir süre sonra IDE dünyası bu tür desteklere kavuşur. Eğer dil ya da uzantı gerçekten başarılı ise araçlar da bunu desteklemeye başlar. Bu ayrımın tek sebebi araç geliştirmenin dil geliştirmekten zor olması değildir. Asıl mesele bir dile hakim olmak ile bir araç setine hakim olmanın çok farklı iki mantalite olmasıdır, belli bir ölçüye dek bunlar birbirlerini dışlayan alternatiflerdir. Acaba neden? İşte sebepleri...

Oliver Steele'nin The IDE Divide başlıklı makalesini tüm yazılım geliştiricilerin okumasında fayda var. (Not: Şöyle sağlam bir FM üyesi çıksa da bahsi geçen makaleyi Türk diline kazandırsa... hani yani küçük bir olasılık olsa da, belki diyorum, belki biri üstlenir, FM'ye bir katkıda bulunur...)