Forum: D Programlama Dili RSS
sınıflar,fonksiyonlar,kurucular sebep sonuç ilişkisi
darkofpain #1
Üye Ağu 2013 tarihinden beri · 58 mesaj
Grup üyelikleri: Üyeler
Profili göster · Bu konuya bağlantı
Konu adı: sınıflar,fonksiyonlar,kurucular sebep sonuç ilişkisi
Merhaba arkadaşlar,

Uzun zamandır işlerimin yoğunluğundan ilgilenme fırsatı bulamadım son zamanlarda kafama takılan bir konuyu sizlerle paylaşmak ve tartışmaya açmak istedim.

Biliyoruz ki artık günümüzde kodlama standartı gelmeye başladı mesela php de eskiden fonksiyonlar ile yazılırken şimdi sınıflar ile ve frameworkler ile yazılıyor fonksiyonlarla ya da spagetti kod yazanlar hor görülüyor.

C dilini örnek alırsak kurucular ve fonksiyonlar mevcut sınıflar olmadığı için kendi standartın da yazılıyor o yüzden sorun yok C++ baktığımız da sınıf kavramı daha ağırlıklı bu sefer fonksiyonlar ile yazıldığı zaman hor görülüyor.

tabi bu diğer dillerde dilin yapısına göre değişkenlik gösteriyor.

Gelelim D diline...

D dili sınıfları,kurucuları,fonksiyonları ve şablonları destekleyen bir dil hal böyle olunca biraz karmaşaya yol açıyor şahsen sınıfları çok seven biri değilim ama örnek veriyorum bir "HTTP Parser" yaptınız bu kurucular ve fonksiyonlar ile yaptığınız sonra paylaştınız akabin de hemen şu sözler gelmeye başlıyor sınıf olarak niye yazmadın bu ne kadar ilkel yapı filan gibi

Siz ne düşünürsünüz neden bu kadar sınıflar la yazma baskısı var ayrıca D dilinde katı kurallar yok olmasını isterdim mesela C gibi sadece fonksiyonlar,kurucular ve şablonlar

bknz: Go dili kurucular,nesneler,fonksiyonlar kabul ediyor ayrıca katı kuralları var.

Go katı kuralından örnek:

Bu şekilde yazarsanız kabul ediyor.
func merhaba(){
}
Bu şekilde yazarsanız kabul etmiyor.
func merhaba()
{
}
Durum bu şekilde sizlerinde düşüncelerinizi,fikirlerinizi almak isterim arkadaşlar.
Avatar
Salih Dinçer #2
Üye Ock 2012 tarihinden beri · 1912 mesaj · Konum: İstanbul
Grup üyelikleri: Üyeler
Profili göster · Bu konuya bağlantı
Sanırım şu söylemime (kendisini tanıdıysam) Ali hocam da katılacak...:)

Kod çalışıyorsa sorun yok!

Yani ha işlevsel (functional), ha nesneye yönelik programlama (OOP) olsun, önemli olan tüm yan etkileri en aza indiren ve hız/satır oranını en iyi tutturan bir kod ortaya çıksın. Ancak günümüz karmaşalar dünyasında, iş kod yazıp çalıştırmakla bitmiyor. Yazım sonrası geliştirme ve bakım işlemleri de önemli bir yer tutuyor.

Hani "su akar yolunu bulur" gibi sözler vardır. Şu an OOP neyse, aslında olması gereken de odur. Hissettiklerini gayet iyi anlıyorum ama tüm bu yaşadıklarımız geçmişte yaşanılan tecrübelerin bir bütünü. Dolayısıyla hor görülmek bir kenara, uzun vadede kodlar yazmak istiyorsak mümkün olduğunca kendimizi nesnelere vermemiz gerekir diye düşünüyorum. Ama başlangıçta söylemime tekrar geri dönersek, önemli olan kodun doğru çalışması olduğuna göre aslında kimse kimseyi hor görmeye hakkı yok. Kod çok artistik görünebilir ama çok fazla yan etkiye de sahip olabilir!

Kolay gelsin...
Bilgi paylaştıkça bir bakmışız; kar topu olmuş ve çığ gibi üzerimize geliyor...:)
darkofpain #3
Üye Ağu 2013 tarihinden beri · 58 mesaj
Grup üyelikleri: Üyeler
Profili göster · Bu konuya bağlantı
Bende sizin gibi düşünüyorum ancak öte yandan baktığımızda yep yeni dil Go dilinde bile sınıf kavramı yok.

Bazı dillerde var okadar karmaşık hal aldı ki kod yazımı artık nasıl yazağını kestiremiyorsun bana kalsa sınıf kullanmam kurucular ve fonksiyonlar gayet temiz ve güzel kullanımıda rahat sınıflara girince herşey karmaşık hal alıyor.

D'nin phobos kütüphanesinde sınıf yapısı çok azdır yoğunluk template,struct,void ile oluşmaktadır.
Bu mesaj darkofpain tarafından değiştirildi; zaman: 2013-11-03, 04:46.
Avatar
Salih Dinçer #4
Üye Ock 2012 tarihinden beri · 1912 mesaj · Konum: İstanbul
Grup üyelikleri: Üyeler
Profili göster · Bu konuya bağlantı
Go tarafını bilemeyeceğim...

Gerçi biraz bilir gibiyim ama çok değil. Sanırım o dilde bir "channel" kavramı vardı. Örneğin asal sayıları çıkaran algoritmasında (-bknz. A concurrent prime sieve) öyle bir şey hatırlıyorum. Yine de ikiside genç bir dil olduğu için gelecekte neler vadeder bilemeyiz.

Aslında bu, saf bir bakır çubuğu oluşturan atomların da çubukla aynı nitelikte olmasından çok farklı bir durum değil. Nesneler içerisindeki her bir üye, aynı zamanda işlevsel programlamada da geçerli şeyler. Sadece olaylar biraz daha derli toplu oluyor sanırım. Kod örnekleri ile açıklamaya çalışacağım:

Ben genelde bir sınıfı geliştirirken, önce main() içinde (sınıfın dışında bir yerde) çalışacak şekilde kodlarım. Örneğin elimizde Fibonacci Serisi oluşturan bir sınıfımız olsun:
 /* FibonacciSerisi.d
  * Yazan : Ali Çehreli
  * Kaynak: http://ddili.org/forum/thread/785
  */
  
  import std.string;
  import std.stdio, std.range;
     
  class FibonacciSerisi
  {
      int baştaki = 0;
      int sonraki = 1;
   
      enum empty = false;
   
      int front() const @property {
          return baştaki;
      }
   
      void popFront() {
          int ikiSonraki = baştaki + sonraki;
          baştaki = sonraki;
          sonraki = ikiSonraki;
      }
  }
 
void main()
{
     auto Fib = new FibonacciSerisi;
     
     foreach(f; Fib.take(10)) {
          f.write(" ");
     }
} /* Çıktısı: 
0 1 1 2 3 5 8 13 21 34 
*/
Az önce, basit bir (pratik) mantıkla, tekil olan sayıları nasıl alabileceğimi düşündüm ve sınıf dışında hemen kurguladım. Sonra sınıf içine alıp bir kaç basit düzenleme (veri kaynağını değiştirme vb.) yaptıktan sonra aşağıdaki 2 satır ile çalıştırdım
(Hemen altındaki ise bahsettiğim işlev!)
  auto xSay = 10;
  while(--xSay) Fib.tekler.write(" ");
  // 1 1 3 5 13 21
  auto tekler(FibonacciSerisi f) {
    scope(exit) f.popFront();
 
    char BS = 8//Back Space Character
 
    return f.front % 2 ? format("%s", f.front) : 
                         format("%s", BS);
  }
Özetle daha güvenilir bir yapı içinde kodumuzu geliştirmiş olduk. Temelde de hiç bir farkı olmadığını gördük. Tıpkı saf maddeyi oluşturan elementlerin de madde ile aynı özellikleri taşıması gibi. Umarım aydınlatıcı olmuştur.

Aslında D'de çok daha güzel olanaklar da var. Örneğin, bu seriyi şu şekilde tek satırda da elde edebiliyoruz:
recurrence!("a[n-1] + a[n-2]")(1, 1).take(10).writeln;
// [1, 1, 2, 3, 5, 8, 13, 21, 34, 55] 

Başarılar...
Bilgi paylaştıkça bir bakmışız; kar topu olmuş ve çığ gibi üzerimize geliyor...:)
acehreli (Moderatör) #5
Kullanıcı başlığı: Ali Çehreli
Üye Haz 2009 tarihinden beri · 4527 mesaj
Grup üyelikleri: Genel Moderatörler, Üyeler
Profili göster · Bu konuya bağlantı
Yanıtlanan mesaj #1
darkofpain:
C dilini örnek alırsak kurucular ve fonksiyonlar mevcut sınıflar olmadığı için kendi standartın da yazılıyor

O cümle(ler)i pek anlayamadım. C dilinde kurucular yok aslında ama ben şöyle düşünüyorum: "C'nin yapılarının keşke kurucuları olsaydı." Doğru. O yüzden D'nin yapıları süper.

o yüzden sorun yok C++ baktığımız da sınıf kavramı daha ağırlıklı

C++'ta yapıyla sınıfı ayıramıyoruz çünkü bir kaç erişim hakkı dışında tamamen aynı yeteneklere sahipler.

bu sefer fonksiyonlar ile yazıldığı zaman hor görülüyor.

Tabii, hiçbir konuda öyle fanatik olmamak gerek. NYP'nin ilk zamanlarında "herşey nesnedir" gibi yanlış bir takıntı vardı; artık pek duyulmuyor. Verilen sayının iki katını döndüren işlevi neden zorlayarak sınıf yapalım? Sonuçta, hiç değişken saklaması gerekmeyen basit bir algoritmadır.

D dili sınıfları,kurucuları,fonksiyonları ve şablonları destekleyen bir dil hal böyle olunca biraz karmaşaya yol açıyor

C++ gibi D de multi-paradigm'dır. Elimizdeki soruna hangisi uygunsa onu kullanalım gibi...

sınıfları çok seven biri değilim

Özellikle yüksek performans gerektiren durumlarda sorun yaratıyorlar:

  • Her nesnenin kendi üyelerine ek olarak iki tane de fazladan üyesi var: Çok şekilliliği sağlayan vtbl göstergesi ve her nesnenin kilit olarak kullanılabilmesini sağlayan monitor denen göstergesi. Bu, 64 bitlik bir ortamda fazladan 16 bayt demektir.

  • Her üye işlev varsayılan olarak sanal olduğundan normalde her çagrı vtbl üzerinde geçtiği için daha masraflı oluyor. (Ara not: Alt sınıflar tarafından tekrar tanımlanması düşünülmeyen sınıf üyelerini açıkça final olarak belirtin. O zaman vtbl üzerinden geçmez.)

  • Sınıf nesneleri C++'ta olduğu gibi doğrudan değil, Java'da olduğu gibi sınıf değişkeni üzerinden kullanılıyorlar. Sınıf değişkenleri perde arkasında gösterge olarak gerçekleştirildiklerinden her sınıf kullanımı bellek üzerinde bir de öyle zıplamaya neden oluyor. Bu gibi zıplamalar mikro işlemcinin ara belleğinin dışına düşülme şansını arttırdığından performansa kötü etki ediyorlar.

ama örnek veriyorum bir "HTTP Parser" yaptınız bu kurucular ve fonksiyonlar ile yaptığınız sonra paylaştınız akabin de hemen şu sözler gelmeye başlıyor sınıf olarak niye yazmadın bu ne kadar ilkel yapı filan gibi

İlkel olduğunu düşünenler yukarıdaki maddeleri göze alarak mı konuşuyorlar acaba?

Benim kuralım çok basit: Gerçekten sınıf gerekene kadar sınıf kullanma.

Sınıf da çok şekillilik kullanılacağı zaman gerekiyor. Klasik Hayvan sıradüzeninde olduğu gibi. Asıl türleri beni ilgilendirmeyen hayvanlar topluluğunu bir Hayvan dizisi olarak yazabilmek çok yararlı.

C dilinde de gördüğümüz gibi, sınıf kullanmadan ya yapılabilir ama çok külfetli.

Siz ne düşünürsünüz neden bu kadar sınıflar la yazma baskısı var

Her zaman için bıyık altından gülüp geçme hakkımız var. ;)

ayrıca D dilinde katı kurallar yok olmasını isterdim mesela C gibi sadece fonksiyonlar,kurucular ve şablonlar

Onu anlayamadım. (Aşağıdakine bakılırsa galiba D'nin katı kuralları olmasını istiyorsun.)

Burada kafamın neden karıştığını anladım: Sanırım "yok"tan sonra bir nokta olmasını düşünüyorsun. Ama dikkat edersen okuyucular senin ne düşündüğünü bilemiyoruz. Zaten yazı sistemleri ve yazım kuralları bunun için var: Senin düşündüklerini bize doğru olarak aktarabilmek. Hocam, bir noktayı esirgeme lütfen! ;)

bknz: Go dili kurucular,nesneler,fonksiyonlar kabul ediyor ayrıca katı kuralları var.

C, C++, ve D de katı kural yok gibi görünüyor ama hepsinin değişken isminden parantezlerin yerlerine kadar bir sürü kuralı var. Fark, bu kurallar programcılar tarafından getiriliyor. Haklısın, dil de uygulayabilirdi ama C'den ve C++'tan gelen programcılar herhalde garipserlerdi. Ne yapalım demekten başka çare yok. Bu noktadan sonra değişemez. :-/

Ali
Avatar
Salih Dinçer #6
Üye Ock 2012 tarihinden beri · 1912 mesaj · Konum: İstanbul
Grup üyelikleri: Üyeler
Profili göster · Bu konuya bağlantı
Yanıtlanan mesaj #3
darkofpain:
Bende sizin gibi düşünüyorum ancak öte yandan baktığımızda yep yeni dil Go dilinde bile sınıf kavramı yok.

Bazı dillerde var okadar karmaşık hal aldı ki kod yazımı artık nasıl yazağını kestiremiyorsun bana kalsa sınıf kullanmam kurucular ve fonksiyonlar gayet temiz ve güzel kullanımıda rahat sınıflara girince herşey karmaşık hal alıyor.
Bir süredir Go dilinin özelliklerini inceliyorum. Bundan önceki iletimde ifade ettiğim gibi biraz biliyordum ama şimdi sırf bu tartışmaya yön verebilmek için biraz okudum. Aslında D tarafını Ali hocam gayet güzel anlatmış; bunu öne çıkarmak için, ilgili bölümü aşağıya da alıntıladım. Hoş burası D forumu ve bunu konuşmalıyız ama güzel bir karşılaştırma fırsatı doğabilir...

Gerçtekten de Go'da, alıştığımız gibi bir sınıf sistemi yok. Zaten buna şaşırdım ama yapılar (struct) geleneksel biçimde kullanılmakta. İşte bu ikisi arasında kalan kısımda, belki kanal olayı ile de ilişkili bir sistem var. Belki bu dili bilmediğim için karıştırıyor olabilirim ama C++'a biraz benziyor. Yani yapı ile işlevler şu şekilde birbirine bağlanıyor:
// An empty struct.
struct {}
 
// A struct with 4 fields.
struct {
        x, y float64
        Length func()
        Scale func()
}
 
func (p *Point) Length() float64 {
    return math.Sqrt(p.x * p.x + p.y * p.y)
}
 
func (p *Point) Scale(factor float64) {
    p.x *= factor
    p.y *= factor
}
Kaynak: http://golang.org/ref/spec#Method_declarations

Hatta D'deki bir interface sistemi bile var.
// A simple File interface
interface {
    Read(b Buffer) bool
    Write(b Buffer) bool
    Close()
}
 
func (p T) Read(b Buffer) bool { return}
func (p T) Write(b Buffer) bool { return}
func (p T) Close() {}
Kaynak: http://golang.org/ref/spec#InterfaceTypes

Bence diller birbirine çok benziyor. Sadece ifade tarzları farklı olabilir. Hatta derlendiği zaman assembly tarafı belki de prensipte kesişiyor bile olabilirler. Ne dersiniz?

acehreli:
sınıfları çok seven biri değilim
Özellikle yüksek performans gerektiren durumlarda sorun yaratıyorlar:

  • Her nesnenin kendi üyelerine ek olarak iki tane de fazladan üyesi var: Çok şekilliliği sağlayan vtbl göstergesi ve her nesnenin kilit olarak kullanılabilmesini sağlayan monitor denen göstergesi. Bu, 64 bitlik bir ortamda fazladan 16 bayt demektir.

  • Her üye işlev varsayılan olarak sanal olduğundan normalde her çagrı vtbl üzerinde geçtiği için daha masraflı oluyor. (Ara not: Alt sınıflar tarafından tekrar tanımlanması düşünülmeyen sınıf üyelerini açıkça final olarak belirtin. O zaman vtbl üzerinden geçmez.)

  • Sınıf nesneleri C++'ta olduğu gibi doğrudan değil, Java'da olduğu gibi sınıf değişkeni üzerinden kullanılıyorlar. Sınıf değişkenleri perde arkasında gösterge olarak gerçekleştirildiklerinden her sınıf kullanımı bellek üzerinde bir de öyle zıplamaya neden oluyor. Bu gibi zıplamalar mikro işlemcinin ara belleğinin dışına düşülme şansını arttırdığından performansa kötü etki ediyorlar.
Bilgi paylaştıkça bir bakmışız; kar topu olmuş ve çığ gibi üzerimize geliyor...:)
darkofpain #7
Üye Ağu 2013 tarihinden beri · 58 mesaj
Grup üyelikleri: Üyeler
Profili göster · Bu konuya bağlantı
Düşüncelerinizi paylaştığınız için teşekkür ederim arkadaşlar haklı olduğunuz çok nokta var.

Ben şu görüşü savunuyorum her dilin katı kuralları olmalı ayrıca diller'de multi-paradigm yapısını destekleyen biri değilim.

Neden derseniz herkesin yazdığı kod bambaşka yapıda oluyor bakıyorsunuz biri sınıflarla yapmış bakıyorsunuz biri sadece fonksiyonlar'la yapmış tek olsa daha iyi olur düşüncesindeyim böylece kod karmaşasına yol açmaz ve kim ne yazarsa yazsın tek standartı olduğu için okuması çözümlemesi daha rahat olacaktır.
Bu mesaj darkofpain tarafından değiştirildi; zaman: 2013-11-08, 12:38.
Doğrulama Kodu: VeriCode Lütfen resimde gördüğünüz doğrulama kodunu girin:
İfadeler: :-) ;-) :-D :-p :blush: :cool: :rolleyes: :huh: :-/ <_< :-( :'( :#: :scared: 8-( :nuts: :-O
Özel Karakterler:
Bağlı değilsiniz. · Şifremi unuttum · ÜYELİK
This board is powered by the Unclassified NewsBoard software, 20100516-dev, © 2003-10 by Yves Goergen
Şu an: 2017-11-22, 06:55:06 (UTC -08:00)