2016-01-12 46 views
8

Bu yerleşik JavaScript prototipleri genişletilmiş (veya hiçbir şekilde değiştirilemez) gerektiğini predominant opinion geçerli:Yerleşik Javascript prototiplerinin sembollerle genişletilmesi de engellenmeli mi?

Array.prototype.empty = function() { return this.length === 0; } // don't try that 

bu kural ES2015 sembolleri için de geçerli mi? symbol yana

const empty = Symbol("empty"); 
Array.prototype[empty] = function empty() { return this.length === 0; } 

tanımla çakışmaları adlandırma bir nesne özelliği olabilir string (ilkel, değişmez) ve object (kimlik) 'in bir karışımıdır.

Normal nesne yansıma sembolleri etkilenmez: Reflect.ownKeys(Array.prototype) ile

Object.getOwnPropertyNames(Array.prototype).indexOf("empty"); // -1 

Ama ES2015 yansımasıdır.

Bu soru, gelecekte Reflect.ownKeys ve Object.getOwnPropertySymbols'u nasıl kullanacağımızla ilgilidir.

+1

Şu an yerleşik alt sınıfları listeleyebileceğinizi unutmayın, bu nedenle yerleşik prototiplerini genişletmemek için bir neden daha var – CodingIntrigue

+1

@RGraham Bu soruyu sormamın temel nedeni kullanım durumlarını daha iyi anlamaktır. veya göreceli olarak yeni bir özellik olduklarından sembollerin kenar durumları. Ben aslında yerleşik prototipleri genişletmeyeceğim. – rand

cevap

2

Evet.

  1. Sen adı çarpışmalar neden olabilir ve senonların kodu kırabilecek:

    "Size ait olmayan bir şeyi değiştirmeyin" kuralına iki bölümü vardır.

    Sahip olmadığınız bir şeye dokunarak, yanlışlıkla başka bir kitaplığın kullandığı bir şeyin üzerine yazabilirsiniz. Bu, kodlarını beklenmedik şekillerde kesecek.

  2. Sen sıkı bağımlılıkları oluşturabilir

    ve onlarsizin kodunu bozabilir.

    Kodunuzu başka bir nesneye çok sıkı bağlayarak, bazı önemli değişiklikler yaparsa (örneğin, sınıfı kaldırmak veya yeniden adlandırmak gibi), kodunuz aniden bozulabilir.

Sembollerin kullanılması # 1'den kaçınacak, ancak hala # 2'ye gireceksiniz. Böyle sınıflar arasındaki sıkı bağımlılıklar genellikle cesaret kırılır. Diğer sınıf hiç frozen ise, kodunuz hala kırılacaktır. this question numaralı telefondan answers hala biraz farklı nedenlerle geçerlidir.

loosely binding, daha iyi bir sınama (gevşek bağlamaların taklit edilmesi daha kolay) ve daha kolay bakım için bağımlılıklarınız üzerinde odaklanmak istersiniz (birkaç açık bağlantının belgelenmesi ve güncelleştirilmesi daha kolaydır). Net olmak için: isim çarpışmaları sadece sıkı sıkıya bağlı bağımlılıkların neden olduğu sorunların bir belirtisidir.

+0

@IvenMarquardt ES6 veya klasik prototipler, etki aynıdır.Kontratsız bir şeye iki yönlü bağımlılık yaratıyorsunuz. 'String.prototype.substr' kullanımı güvenli, tek yönlü bir bağımlılıktır: işlevi kullanırsanız, var olacağını ve nasıl davranacağını belirten bir sözleşme sağlar. 'String.prototype' içine bir şey enjekte etmek, daha fazla yuvarlaktır (ikisini de değiştirir ve kullanırsınız) ve genellikle mümkün olmayacağını söyleyen bir sözleşme sağlamazlar. – ssube

+0

Sonunda, bu "tehlikeli olabilir, ona dokunmayın" anlamına gelir. Bu gerçek hayatı sıkıcı hale getirecek olsa da, kodu * sabit * yapar. – ssube

+0

Ancak bir Array.prototype örneğini oluşturursanız ve bunu değiştirilemez (don) hale getirirseniz, "push" ve "pop" vb. Başka bir örnek verebilir misiniz? – rand