Jump to page: 1 2 3
Thread overview
Nitelikler
May 29, 2012
Salih Dinçer
May 29, 2012
zafer
May 29, 2012
Salih Dinçer
May 29, 2012
zafer
May 30, 2012
Salih Dinçer
May 30, 2012
Salih Dinçer
May 30, 2012
Salih Dinçer
May 30, 2012
Salih Dinçer
May 31, 2012
Salih Dinçer
May 30, 2012
zafer
May 31, 2012
Salih Dinçer
May 31, 2012
zafer
May 31, 2012
Salih Dinçer
Jun 01, 2012
zafer
Jun 01, 2012
Salih Dinçer
Jun 03, 2012
zafer
Nov 03, 2013
Salih Dinçer
May 29, 2012
zafer
May 29, 2012

Aslında bu konu şurada (http://ddili.org/forum/post/6039) tartıştığımız JSON konusunun devamıdır.

Acaba D.ershane'de, nitelik dersinin (Nitelikle (http://ddili.org/ders/d/nitelikler.html)r @property) kullanım anlamı, @safe ve pure gibi şeylerin anlatıldığı derste veya başka bir yerde bahsediliyor mu? Çünkü hala yapılar dışında kullanımının ne farkı olduğunu anlayamadım. Hatta varsayılan olarak bu şekilde (@property'li) kalması gerektiğini ve geriye uyumluluk için ön tanımlı olmaktan çıkarıldığını da yeni öğrendim...

Dip Not: Yukarıdaki paragrafta derdimi anlatamamış olabilirim çünkü diğer konuda uyarladım! Kısaca @property'nin yapı dışında kullanımını anlatan bir makale (İngilizce de olabilir) var mı? Bunun neyi fark ettirdiğini çok merak ediyorum...:)

--
[ Bu gönderi, http://ddili.org/forum'dan dönüştürülmüştür. ]

May 30, 2012

Salih doğrusunu istersen bu konuyu öyle kısa bir mesajla anlatmak çok kolay değil, yinede bildiğim kadarıyla aktarmaya çalışayım yanlış veya eksiğim varsa Ali düzeltir diye düşünüyorum. Aklına takılanları zaten sen sorarsın.

class Ütü
{
	private int utuSicakligi;	// 0..100 derece

	public this()
	{
		this.utuSicakligi = 0;
	}

	public void ÜtüyüAyarlananSıcaklığaGetir()
	{
		// Gerekli işlemler
	}

	@property void ÜtüSıcaklığıAyarla(int sıcaklık)
	{
		enforce (sıcaklık > 100, "Ütü sıcaklığı bu değere ayarlanamaz.");

		utuSicakligi = sıcaklık;
	}
}

Ben her zaman ki gibi sınıflardan devam ediyorum. Elimizde Ütü isimli bir sınıf olduğunu düşünelim. Bu bildiğimiz ütü nesnesinin bilgisayar ortamına taşınmış hali. Ütümüz 0..100 derece arasındaki bir değere kadar ısınabiliyor. Bunu biz ütüSıcaklıgı isimli bir nitelik ile belirliyoruz. Ayrıca bu ısıtma işini yapan metodumuzuda ÜtüyüAyarlananSıcaklığaGetir() ismiyle tanımladık.

Dikkat ettiysen utuSicakligi niteliğimiz private yani dış dünyadan erişime kapalı olarak tanımlandı. Ancak bu sınıfı kullanan programcı doğal olarak bu sıcaklığı ayarlamak isteyecek oysa dışarı kapalı olan bu özelliğe ulaşması mümkün değil. Bunu aşmak için şöyle bir yol kulllanılıyor. Önce dışarıya açık public bir metot tanımlanıp buna gönderilen değer sınıf içinde ilgili nitelik değerine aktarılıyor. Bu yapıya NYP'de (Nesne Yönelimli Programlama) kapsülleme veya sarma ismi verilir. Neticede bu şekilde ilgili nitelik değeri düzenlenmiş olur. Bu tür nitelikler üzerinde işlem yapan metotlar özelleştirilmiş ve property anahtar sözcüğü ile tanımlanmaya başlamıştır. Property'nin espirisi budur.

Avantajı nedir dersen, örneğin sınıf içindeki utuSicakligi niteliğine direk erişebiliyor olsan şöyle bir kod yazmanı kimse engelleyemez.

utuSicakligi = 200; // Geçersiz

Oysa kapsülleme sayesinde örneğin benim geliştirip sana verdiğim ve senin kullandığın bir ütü sınıfında utuSicakligi değerine 100 'den büyük bir değer veremezsin. Çünkü bu değer ilgili niteliğe aktarım esnasında sınıf tarafından kontrol edilir. Böylece sınıfın bütünlüğü korunmakla birlikte programcının hata yapma riskinide düşürmüş olursun. Aslında bu konu çok daha derin ve büyük bir konu ama benim bildiklerim böyle.

--
[ Bu gönderi, http://ddili.org/forum'dan dönüştürülmüştür. ]

May 30, 2012

Kapsüllemeyi az/çok biliyorum ama JSON çalışmamızda bunları kullanmadan da çalışabileceğini görünce insan ister istemez ne farkı/avantajı olduğunu merak ediyor!

Parantezsiz kullanmaya gelince...

UCFS'den dolayı mı bilmiyorum (gerçi o zaman opCastJSONValue!Öğrenci.mixin; demeliydik) ama zaten parantezsiz kullanılabiliyor:

string opCastJSONValue(T)() {
   :    :    :
}
struct Öğrenci
{
   string isim;
   ulong numara;
   uint[string] notlar;
   // Katma (mixin) ifadeleri, derleme anında buraya gelecek...
   mixin(opCastJSONValue!Öğrenci);
}

Tıpkı tek türlü (T)ype işlevlerde ünlemden sonra paranteze ihtiyaç duymamamız gibi. Bunlar ilginç ve belki de çok önemli olmayan şeyler. Aslında @safe, @trusted, @system ve pure gibi türler (function type) üzerinde durmalı ki henüz onlara pek ihtiyaç duymuyorum. Ama kesinlikle kapsamlı projelerde (örn. siPIC-D (http://ddili.org/forum/thread/737) projemde) kullanmak gerekiyor.

Sevgiler, saygılar...

--
[ Bu gönderi, http://ddili.org/forum'dan dönüştürülmüştür. ]

May 30, 2012

Alıntı (acehreli):

>

Zafer, söylediklerin doğru ama @property'yi açıklamıyor çünkü sarmayı @property olmadan da yapabiliyoruz zaten.

Haklısın Ali, zaten C ve C++ gibi dillerde bildiğim kadarıyla property yapısı yok. Onun yerine get ve set metodlarını kullanıyorlar ancak Delphi, C#, Java ve D gibi modern dillere bakarsan bu get, set metodlarının yerini property olarak tanımlanmış metodların aldığını görürüsün.

Property özelleşmiş bir yapı, şöyle bir baktığında bir metotla property arasında bir fark görebiliyor musun? Sadece bir fark metot parantezlerinin kullanılmaması, o da property metotların daha temiz ve okunaklı yazılması için. Neticede bunlar arkaplanda sadece bir niteliği yönetmek için kullanılıyorlar. Tıpkı ütünün ısı ayarı düğmesi gibi görevi sadece ısıyı ayarlamak, ancak istersen sen ütünün içini açıp bunu yapabilirsin, bu düğme kapsülleme yaparak bu işlemi güvenli hale geitriyor.

Yani tersinden gidersek bizim property olarak nitelediğimiz yapı C ve C++ zamanında kullanılan ve get ve set işlemlerini yaptığımız basit metotların ta kendisi. Yanlışlarım olabilir konuyu böyle biliyorum. Yinede hep beraber bir araştıralım, mühim olan doğruyu öğrenmek :)

--
[ Bu gönderi, http://ddili.org/forum'dan dönüştürülmüştür. ]

May 30, 2012

Alıntı (Salih Dinçer):

>

Kapsüllemeyi az/çok biliyorum ama JSON çalışmamızda bunları kullanmadan da çalışabileceğini görünce insan ister istemez ne farkı/avantajı olduğunu merak ediyor!

Kapsülleme (Encapsulation) çok değerli bir özelliktir. Kesinlikle bu konuyu daha fazla araştırmanı ve bunu öğrenmeni öneririm. Kapsülleme programcıya nesneleri koruma gücünü verir.

--
[ Bu gönderi, http://ddili.org/forum'dan dönüştürülmüştür. ]

May 30, 2012

Alıntı (acehreli):

>

(Not: @propert'yi denemek isteyenler dmd'yi mutlaka -property seçeneği ile kullansınlar yoksa zaten her üye işlev parantezsiz çağrılabildiği için @property'nin anlamı kalmıyor.)

Şimdi anladım...:)

Bu parametreyi kullanmıyorsak aslında her işlevin yanında @property olduğu varsayılıyor, bu her şeyi açıklıyor...

Bu durumda UFCS'de çalışmayacaktır!

--
[ Bu gönderi, http://ddili.org/forum'dan dönüştürülmüştür. ]

May 30, 2012
import std.stdio;

string naim()
{
   return "UFFFFFFFFCS...:)";
}

void main()
{
   naim.writeln;
}

Çıktısı:
'salih@salih-NB:~/d.ders/JSON$ dmd ufcs
salih@salih-NB:~/d.ders/JSON$ dmd ufcs -property
ufcs.d(10): Error: not a property naim
salih@salih-NB:~/d.ders/JSON$ ./ufcs
UFFFFFFFFCS...:)'

--
[ Bu gönderi, http://ddili.org/forum'dan dönüştürülmüştür. ]

May 29, 2012

@property, yapılarda ve sınıflarda da olduğu gibi, parametre almayan işlevlerin parantezsiz olarak çağrılabilmelerini sağlar. Hayır, kitapta bu kullanım geçmiyor. İngilizceleştirdikçe geliştiriyorum; oraya gelince eklerim.

   int i = foo; // foo() @property olduğu için parantezsiz

Ali

--
[ Bu gönderi, http://ddili.org/forum'dan dönüştürülmüştür. ]

May 30, 2012

Yanlış anlaşılmasın UFCS demek istedim, UFFFF'dan çağrışım yapıyorum: vurgu...:)

Bir de yabancılar foo ve bar kullanıyor ya. Düşünüyorum da bizden bir şeyler kullanabilir miyiz diye?

Aklıma main'e benzeyen naim (bir Türk ismi mi?) ve varyasyonları anim, mina ve inam gibi şeyler geldi. Ne dersiniz?

--
[ Bu gönderi, http://ddili.org/forum'dan dönüştürülmüştür. ]

May 30, 2012

Zafer, söylediklerin doğru ama @property'yi açıklamıyor çünkü sarmayı @property olmadan da yapabiliyoruz zaten.

Ali

--
[ Bu gönderi, http://ddili.org/forum'dan dönüştürülmüştür. ]

« First   ‹ Prev
1 2 3