Bildirilen özellikler için nokta notasyonu ve mesaj notasyonu

Artık özellikler için "nokta" gösterimine sahibiz. Çeşitli gördüğüm arkasını ve forths nokta gösterimi vs mesajı gösterimde yararları hakkında. Cevapları lekesiz tutmak için soruya da cevap vermeyeceğim.

Mülk erişimi için nokta notasyonu ve mesaj notasyonu hakkındaki düşünceniz nedir?

Lütfen bunu Objective-C'ye odaklamaya çalışın - ortaya koyacağım tek önyargı, Objective-C'nin Objective-C olmasıdır, bu nedenle Java veya JavaScript gibi olma tercihiniz geçerli değildir.

Geçerli yorum, teknik konularla (işlem sıralaması, önceliklendirme, performans vb.), Netlik (yapıya karşı nesne doğası, hem olumlu hem de olumsuz!), Kısa ve özlük vb. İle ilgilidir.

Dikkat edin, kod geleneğinin ve kalitesinin çok önemli olduğu devasa projelerde çalışmış olan kodda titiz kalite ve okunabilirlik okulundanım (bin kere okuma paradigması).

Davranış için nokta kullanmayın. Genelde özellikler olarak bildirilen özellikler gibi özelliklere erişmek veya bunları ayarlamak için nokta kullanın.

x = foo.name; // good
foo.age = 42; // good

y = x.retain; // bad

k.release; // compiler should warn, but some don't. Oops.

v.lockFocusIfCanDraw; /// ooh... no. bad bad bad

Objective-C'ye yeni başlayanlar için, @property olarak bildirilen şeyler dışında hiçbir şey için noktayı kullanmamalarını tavsiye ederim. Dil konusunda bir fikriniz olduğunda, doğru olanı yapın.

Örneğin, aşağıdakileri tamamen doğal buluyorum:

k = anArray.count;
for (NSView *v in myView.subviews) { ... };

Clang statik analizörünün, noktanın yalnızca belirli modeller için kullanıldığını veya belirli diğer modeller için kullanılmadığını kontrol etmenize izin verme yeteneğini artıracağını bekleyebilirsiniz.

Programlamaya Visual / Real Basic ile başladığımı, sonra Java'ya geçtiğimi söyleyerek başlayayım, yani nokta sözdizimine oldukça alıştım. Ancak, sonunda Objective-C'ye geçip parantezlere alıştığımda, sonra Objective-C 2.0'ın ve nokta sözdiziminin tanıtımını gördüğümde, bundan gerçekten hoşlanmadığımı fark ettim. (diğer diller için sorun değil, çünkü böyle dönüyorlar).

Objective-C'de nokta sözdizimine sahip üç ana etkim var:

Sığır Eti # 1: Neden hata aldığınızı belirsizleştirir. Örneğin, şu satırım varsa:

something.frame.origin.x = 42;

Sonra bir derleyici hatası alacağım çünkü somethingbir nesnedir ve bir nesnenin yapılarını bir ifadenin değeri olarak kullanamazsınız. Ancak, eğer varsa:

something.frame.origin.x = 42;

Çünkü O zaman bu derler gayet, somethingbir NSRect üyesine sahip olan bir yapı kendisi olduğunu ve olabilir bir lvalue olarak kullanabilirsiniz.

Bu kodu benimsiyor olsaydım, ne somethingolduğunu anlamaya çalışmak için biraz zaman harcamam gerekirdi . Bir yapı mı? Bu bir nesne mi? Bununla birlikte, köşeli parantez sözdizimini kullandığımızda çok daha nettir:

[something setFrame:newFrame];

Bu durumda, somethingbir nesne olup olmadığı kesinlikle bir belirsizlik yoktur . Belirsizliğin girişi benim sığır etim # 1.

Sığır # 2: C'de, nokta sözdizimi yöntemler çağırmak yerine yapıların üyelerine erişmek için kullanılır. Programcılar bir nesnenin setFoo:ve fooyöntemlerini geçersiz kılabilir , ancak yine de onlara aracılığıyla erişebilirler something.foo. Aklımda, nokta sözdizimini kullanan ifadeler gördüğümde, bunların bir ivar'a basit bir atama olmasını bekliyorum. Bu her zaman böyle değildir. Bir dizi ve bir tablo görünümüne aracılık eden bir denetleyici nesnesi düşünün. Eğer myController.contentArray = newArray;ararsam, eski diziyi yeni diziyle değiştirmesini beklerdim. Ancak, orijinal programcı setContentArray:yalnızca diziyi ayarlamakla kalmayıp, aynı zamanda tablo görünümünü de yeniden yüklemeyi geçersiz kılmış olabilir. Çizgiden, bu davranışa dair bir gösterge yok. Eğer görseydim[myController setContentArray:newArray];, sonra "Aha, bir yöntem. Ne yaptığını bildiğimden emin olmak için bu yöntemin tanımını görmem gerekiyor." diye düşünürdüm.

Bence Beef # 2 ile ilgili özetim, nokta sözdiziminin anlamını özel kodla geçersiz kılabileceğinizdir.

Sığır eti # 3: Kötü göründüğünü düşünüyorum. Bir Objective-C programcısı olarak, sözdizimini parantez içine almaya tamamen alıştım, bu yüzden güzel parantezlerin satırlarını ve satırlarını okumak ve görmek ve sonra foo.name = newName; foo.size = newSize;vb. İle aniden kırılmak benim için biraz rahatsız edici. Bazı şeylerin nokta sözdizimi (C yapıları) gerektirdiğinin farkındayım, ama onları tek kullandığım zaman bu.

Elbette, kendiniz için kod yazıyorsanız, rahat ettiğiniz şeyi kullanın. Ancak açık kaynak oluşturmayı planladığınız bir kod yazıyorsanız veya sonsuza kadar korumayı beklemediğiniz bir şey yazıyorsanız, o zaman köşeli parantez sözdizimini kullanmayı şiddetle tavsiye ederim. Bu, elbette, sadece benim fikrim.

Nokta sözdizimine karşı son blog yayını: http://weblog.bignerdranch.com/?p=83

Yukarıdaki gönderiye yanıt verin: http://eschatologist.net/blog/?p=226 (nokta sözdizimi lehine orijinal makale ile: http://eschatologist.net/blog/?p=160 )

Ben yeni bir Cocoa / Objective-C geliştiricisiyim ve bu konudaki yaklaşımım şu:

Obj-C 2.0 ile başlamama ve nokta notasyonu daha tanıdık bir duygu olmasına rağmen (Java benim ilk dilim) mesajlaşma notasyonuna sadık kaldım. Bunun nedeni oldukça basit: Hala tam olarak anlamıyorum neden dile nokta notasyonu eklediler. Bana göre gereksiz, "saf olmayan" bir ekleme gibi görünüyor. Dile nasıl faydası olduğunu açıklayabilecek biri varsa, bunu duymaktan mutluluk duyarım.

Bununla birlikte, bunu stilistik bir seçim olarak görüyorum ve tutarlı ve okunabilir olduğu sürece , diğer stil seçimlerinde olduğu gibi (açılış küme ayracınızı ile aynı satıra koymak gibi) doğru ya da yanlış bir yol olduğunu düşünmüyorum . yöntem başlığı veya sonraki satır).

Objective-C nokta notasyonu, normal mesaj geçişine çevrilen sözdizimsel bir şekerdir, bu nedenle kaputun altında hiçbir şey değişmez ve çalışma zamanında hiçbir fark yaratmaz. Nokta notasyonu kesinlikle mesaj geçişinden daha hızlı değildir.

Bundan sonra küçük bir önsöze ihtiyaç duyduğumda, burada benim tarafımdan görülen artıları ve eksileri:

Nokta gösterimi artıları ve eksileri

• artıları

  • okunabilirlik: nokta notasyonu, iç içe geçmiş parantez masajlarından daha kolay okunur
  • Nitelikler ve Özellikler ile etkileşimi basitleştirir: özellikler için nokta notasyonu ve yöntemler için mesaj gösterimi kullanarak synthax seviyesinde durum ve davranış ayrımı elde edebilirsiniz.
  • Bileşik atama operatörü (1) kullanmak mümkündür .
  • kullanarak @propertyalma ve özelliği ayarlanırken iyi Bellek Yönetimi için kodu oluşturmak, sizin için bir sürü iş yapmak ve derleyici notasyonu nokta; bu nedenle nokta notasyonu Apple'ın resmi kılavuzları tarafından önerilmektedir.

• Eksileri

  • Nokta gösterimine yalnızca beyan edilen bir @property
  • Objective-C, standart C'nin (dil uzantısı) üzerindeki bir katman olduğundan, noktalı gösterim, erişilen varlığın bir nesne mi yoksa bir yapı mı olduğunu gerçekten netleştirmez. Genellikle, bir yapının özelliklerine erişiyormuşsunuz gibi görünür.
  • noktalı gösterimle bir yöntemi çağırmak, adlandırılmış parametrelerin okunabilirlik avantajlarını kaybedersiniz
  • karışık mesaj notasyonu ve nokta notasyonu iki farklı dilde kodluyormuşsunuz gibi göründüğünde

Kod Örnekleri:

(1) Bileşik operatör kullanım kodu örneği:

//Use of compound operator on a property of an object
anObject.var += 1;
//This is not possible with standard message notation
[anObject setVar:[anObject var] + 1];

Bir dilin tarzını, dilin kendisiyle tutarlı olarak kullanmak, burada en iyi tavsiyedir. Bununla birlikte, bu bir OO sisteminde (veya tersi) işlevsel kod yazma durumu değildir ve nokta gösterimi, Objective-C 2.0'daki sözdiziminin bir parçasıdır.

Herhangi bir sistem kötüye kullanılabilir. Önişlemcinin tüm C tabanlı dillerdeki varlığı gerçekten oldukça garip şeyler yapmak için yeterlidir; Ne kadar tuhaf olabileceğini tam olarak görmeniz gerekiyorsa , Gizlenmiş C Yarışmasına bakın. Bu, önişlemcinin otomatik olarak kötü olduğu ve onu asla kullanmamanız gerektiği anlamına mı geliyor?

Arayüzde olduğu gibi tanımlanan özelliklere erişim için nokta sözdiziminin kullanılması kötüye kullanıma açıktır. Potentia'da istismarın varlığı buna karşı bir argüman olmamalıdır.

Mülkiyet erişiminin yan etkileri olabilir. Bu, bu özelliği elde etmek için kullanılan sözdizimine ortogonaldir. CoreData, delegation, dinamik özellikler (ilk + son = tam), kapaklar altında mutlaka bazı işler yapacaktır. Ancak bu, "örnek değişkenleri" ile bir nesnenin "özellikleri" ni karıştırır. Özelliklerin olduğu gibi depolanması için bir neden yoktur, özellikle de hesaplanabiliyorsa (örneğin bir String'in uzunluğu). Yani foo.fullName veya [foo fullName] kullansanız da dinamik bir değerlendirme olacaktır.

Son olarak, bir özellik (bir olarak kullanıldığında davranışı lvalue ) bir kopyası alınır olup olmadığı gibi ya da muhafaza olup olmadığını, nesnenin kendisi tarafından tanımlanır. Bu, yöntemleri yeniden uygulamak zorunda kalmadan daha sonra - özellik tanımının kendisinde - davranışı değiştirmeyi kolaylaştırır. Bu, daha az (uygulama) hatanın ortaya çıkma olasılığı ile birlikte yaklaşımın esnekliğine katkıda bulunur. Hala yanlış yöntemi seçme olasılığı var (yani saklamak yerine kopyala), ancak bu uygulama sorunundan çok mimari bir sorun.

Nihayetinde, 'yapı gibi görünüyor mu' sorusuna gelir. Muhtemelen şimdiye kadarki tartışmalarda ana fark yaratan şey budur; Bir yapınız varsa, bir nesneye sahip olduğunuzdan farklı çalışır. Ama bu her zaman doğruydu; bir yapıya bir mesaj gönderemezsiniz ve yığın tabanlı mı yoksa referans / malloc tabanlı mı olduğunu bilmeniz gerekir. Kullanım açısından farklılık gösteren zihinsel modeller zaten var ([[CGRect tahsis] init] veya struct CGRect?). Davranış açısından hiçbir zaman birleşmemişler; her durumda neyle karşı karşıya olduğunuzu bilmeniz gerekir. Nesneler için özellik belirtimi eklemek, veri türlerinin ne olduğunu bilen herhangi bir programcının kafasını karıştırmaz; ve eğer yoksa, daha büyük sorunları var.

Tutarlılık konusuna gelince; (Amaç-) C kendi içinde tutarsızdır. = kaynak koddaki sözcüksel konuma bağlı olarak hem atama hem de eşitlik için kullanılır. * işaretçiler ve çarpma için kullanılır. BOOL'lar, EVET ve HAYIR'ın sırasıyla 1 ve 0 olmasına rağmen, bayt (veya başka bir tam sayı değeri) değil karakterdir. Tutarlılık veya saflık, dilin tasarlandığı şey değildir; işleri halletmekle ilgiliydi.

Yani kullanmak istemiyorsanız, kullanmayın. Farklı bir şekilde yaptır. Kullanmak istiyorsan ve anlıyorsan, kullanman sorun değil. Diğer diller, genel veri yapıları (haritalar / yapılar) ve nesne türleri (özelliklerle) kavramlarıyla ilgilenir ve biri yalnızca bir veri yapısı, diğeri ise zengin bir nesne olmasına rağmen genellikle her ikisi için aynı sözdizimini kullanır. Objective-C'deki programcılar, tercih ettiğiniz bir program olmasa bile, tüm programlama stilleri ile başa çıkabilmek için eşdeğer bir beceriye sahip olmalıdır.

Bunu mülkler için kullanıyorum çünkü

for ( Person *person in group.people){ ... }

okumaktan biraz daha kolay

for ( Person *person in [group  people]){ ... }

ikinci durumda okunabilirlik, beyninizi mesaj gönderme moduna sokarak kesintiye uğratılırken, birinci durumda grup nesnesinin people özelliğine eriştiğiniz açıktır.

Bir koleksiyonu değiştirirken de kullanacağım, örneğin:

[group.people addObject:another_person];

şundan biraz daha okunaklı

[[group people] addObject:another_person];

Bu durumda vurgu, iki mesajı zincirlemek yerine diziye bir nesne ekleme eyleminde olmalıdır.

Çoğunlukla Objective-C 2.0 çağında yetiştirildim ve nokta gösterimini tercih ederim. Bana göre fazladan parantez yerine kodun basitleştirilmesine izin veriyor, sadece bir nokta kullanabilirim.

Nokta sözdizimini de seviyorum çünkü bana bir mesaj göndermek yerine nesnenin bir özelliğine erişiyormuşum gibi hissettiriyor (tabii ki nokta sözdizimi gerçekten mesaj göndermeye dönüşüyor, ancak görünümler uğruna nokta farklı hissediyor). Eski sözdizimine göre "alıcı çağırmak" yerine, gerçekten doğrudan nesneden yararlı bir şey alıyormuşum gibi geliyor.

Bu konudaki tartışmalardan bazıları "Ama zaten nokta sözdizimimiz var ve bunun için structs!" İle ilgilidir. Ve bu doğru. Ama (ve yine, bu sadece psikolojik) temelde bana aynı geliyor. Nokta sözdizimini kullanarak bir nesnenin bir özelliği erişme hisseder (Bence) az ya da çok amaçlı etki olan bir yapının bir elemanı, erişim ile aynı.

**** Düzenleme: bbum'un belirttiği gibi, bir nesnede herhangi bir yöntemi çağırmak için nokta sözdizimini de kullanabilirsiniz (bunun farkında değildim). Bu yüzden nokta sözdizimi hakkındaki fikrimin, günlük mesaj gönderimi için değil, yalnızca bir nesnenin özellikleriyle ilgilenmek için olduğunu söyleyeceğim **

Daha çok mesajlaşma sözdizimini tercih ederim ... ama sadece öğrendiğim bu olduğu için. Sınıflarımın çoğunu ve Objective-C 1.0 stilinde olmayanları düşünürsek, onları karıştırmak istemem. Nokta sözdizimini kullanmamak için "alıştığım şey" dışında gerçek bir nedenim yok ... Bunun DIŞINDA, bu beni INSANE tahrik ediyor

[myInstance.methodThatReturnsAnObject sendAMessageToIt]

Neden bilmiyorum ama iyi bir sebep yokken beni gerçekten çileden çıkarıyor. Sadece yaptığını düşünüyorum

[[myInstance methodThatReturnsAnObject] sendAMessageToIt]

daha okunaklı. Ama her biri kendine!

Dürüst olmak gerekirse, bunun bir tarz meselesine bağlı olduğunu düşünüyorum. Ben şahsen nokta sözdizimine karşıyım (özellikle onu sadece değişkenleri okumak / yazmak için değil, yöntem çağrıları için kullanabileceğinizi öğrendikten sonra). Bunu kullanmak için gidiyoruz Ancak, ben güçlü öneriyoruz değil erişen ve değişkenleri değiştirerek başka bir şey için onu kullanıyor.

Nesne yönelimli programlamanın temel avantajlarından biri, nesnelerin iç durumuna doğrudan erişimin olmamasıdır.

Nokta sözdizimi bana, duruma doğrudan erişiliyormuş gibi görünmesini ve hissetmesini sağlama girişimi gibi görünüyor. Ama gerçekte, -foo ve -setFoo davranışları üzerinde sadece sözdizimsel şekerdir :. Ben de bir kürek kürek demeyi tercih ederim. Nokta sözdizimi, kodun daha özlü olduğu ölçüde okunabilirliğe yardımcı olur, ancak anlamaya yardımcı olmaz çünkü gerçekten -foo ve -setFoo: diye çağırdığınızı akılda tutmamak, sorun yaratabilir.

Sentezlenmiş erişimciler bana, duruma doğrudan erişilen nesneleri yazmayı kolaylaştırma girişimi gibi görünüyor. Benim inancım, bunun tam olarak nesne yönelimli programlamanın kaçınmak için yaratıldığı türden bir program tasarımını teşvik ettiği yönünde.

Dengede, nokta sözdizimini tercih ederim ve özellikler hiç tanıtılmamıştı. İnsanlara ObjC'nin Smalltalk'a daha çok benzemek için C'nin birkaç temiz uzantısı olduğunu söyleyebiliyordum ve bunun artık doğru olduğunu düşünmüyorum.

Bana göre nokta sözdizimi, Objective-C'yi Smalltalk-esque yapar. Kodun daha basit görünmesini sağlayabilir, ancak belirsizlik ekler. Bir mi struct, unionya da nesne?

Görünüşe göre pek çok kişi 'özellikleri' ile 'örnek değişkenleri' karıştırıyor. Özelliklerin amacı, bence nesnenin içini bilmek zorunda kalmadan nesneyi değiştirmeyi mümkün kılmaktır. Örnek değişkeni, çoğu zaman, bir özelliğin 'uygulamasıdır (ki bu da' arayüz '), ancak her zaman değil: bazen bir özellik bir ivar'a karşılık gelmez ve bunun yerine bir dönüş değeri hesaplar' anında'.

Bu yüzden, "nokta sözdiziminin sizi değişkene eriştiğinizi düşünmeniz için kandırdığı ve bu yüzden kafa karıştırıcı olduğu" fikrinin yanlış olduğuna inanıyorum. Nokta veya köşeli parantez, iç öğeler hakkında varsayımlarda bulunmamalısınız: bu bir Özellik, bir ivar değil.

Sanırım nokta notasyonu yerine mesajlaşmaya geçebilirim çünkü kafamda object.instanceVar sadece nesneye ait olan instanceVar'dır , bana göre bir yöntem çağrısı gibi görünmüyor , ki öyle, bu yüzden işler olabilir erişimcinizde ve instanceVar veya self.instanceVar kullanıp kullanmamanız , örtük ve açıktan çok daha fazla farka sahip olabilir. Sadece 2 ¢.

Noktalı gösterim, mesajların bir yapının üyesine erişim gibi görünmesini sağlamaya çalışır, ancak bunlar değildir. Bazı durumlarda iyi çalışabilir. Ama yakında birisi şöyle bir şey bulacak:

NSView *myView = ...;
myView.frame.size.width = newWidth;

İyi görünüyor. Ama değil. İle aynı

[myView frame].size.width = newWidth;

hangi çalışmıyor. Derleyici ilkini kabul eder, ancak haklı olarak ikinciyi kabul etmez. Ve ilki için bir hata veya uyarı verse bile, bu sadece kafa karıştırıcıdır.

Bana tembel deyin ama tek bir 'yazmam gerekirse.' aynı sonuçları almak için her seferinde iki [] 'ye karşılık tek bir tane tercih ederim. Ayrıntılı dillerden nefret ederim. Lisp'deki () beni çıldırttı. Matematik gibi zarif diller özlü ve etkilidir, diğerleri yetersizdir.

Noktalı gösterimi kullanın (ne zaman yapabiliyorsanız)

Bir değer döndüren örnek yöntemlerinde

Nokta notasyonu kullanmayın

Void döndüren örnek yöntemlerinde, init yöntemlerinde veya Class yönteminde.

Ve benim kişisel favori istisnam

NSMutableArray * array = @[].mutableCopy;

Ben şahsen kodda nokta notasyonu kullanmıyorum. Ben sadece gerektiğinde CoreData KVC bağlama ifadesinde kullanıyorum.

Benim için onları kodda kullanmamamın nedeni, noktalı gösterimin ayarlayıcı anlamını gizlemesidir. Bir özelliği noktalı gösterimde ayarlamak, ayarlayıcı anlamından (atama / tutma / kopyalama) bağımsız olarak her zaman atama gibi görünür. Mesaj notasyonunun kullanılması, alıcı nesnenin ayarlayıcıda neler olduğu üzerinde kontrol sahibi olduğunu görünür kılar ve bu etkilerin dikkate alınması gerektiğinin altını çizer.

KVC uyumlu veya bildirilmiş bir özelliğin değerini alırken nokta notasyonu kullanmak isteyip istemediğimi hala düşünüyorum çünkü kuşkusuz biraz daha kompakt ve okunabilir ve gizli anlambilim yok. Şu anda tutarlılık adına mesaj notasyonu kullanıyorum.

Tamam, Objective-C'deki nokta notasyonu gerçekten tuhaf görünüyor. Ama hala aşağıdakileri onsuz yapamıyorum:

int width = self.frame.size.width;

İyi çalışıyor, ancak:

int height = [[[self frame] size] height];

Bana "İşaretçi tipine dönüştürülemiyor" verir. Yine de, kodumun mesaj gösterimiyle tutarlı görünmesini sağlamak istiyorum.

Bu harika bir soru ve buna birçok farklı yanıt görüyorum. Birçoğu konulara değinmiş olsa da, buna farklı bir açıdan cevap vermeye çalışacağım (bazıları bunu dolaylı olarak yapmış olabilir):

'Nokta' gösterimini kullanırsak, yöntem için hedefin çözümlenmesi derleme zamanında yapılır. Mesaj geçirmeyi kullanırsak, hedefin çözünürlüğü çalışma zamanı yürütmeye ertelenir. Hedefler derleme zamanında çözülürse, çalıştırma zamanında hedeflerin çözülmesi birkaç ek yük içerdiğinden yürütme daha hızlıdır. (Zaman farkının çok önemli olacağından değil). Özelliği nesnenin arayüzünde zaten tanımladığımız için, bir özelliğin hedef çözünürlüğünün çalışma zamanına göre farklılaştırılmasının bir anlamı yoktur ve dolayısıyla, özelliğe erişmek için kullanmamız gereken gösterim noktalı gösterimdir.