Quale modello di progettazione OOP JavaScript sfrutterà maggiormente le (nuove) funzioni di ECMAScript 5?

Question

ECMAScript 5 è in bozza finale ora e include nuove funzionalità relative a oggetti e prototipi. Mentre cercavo SO e Google per i modelli di design OOP, ho scoperto che c'erano diversi modi per "fare OOP" (tuttavia potresti definire OOP, dal tentativo di emulare OOP classico al semplice tentativo di ridurre l'inquinamento dello spazio dei nomi) in JavaScript.

Quale modello di design è la visione più lungimirante - & # 224; -vis la direzione ECMAScript 5 sta prendendo il mondo JavaScript? Quali sono i suoi vantaggi chiave? Quale di questi non era possibile o bello da implementare prima?

Answer 1

Non credo che ECMAScript 5 cambi il panorama di OOP in JavaScript. La OOP classica sarà ancora un fulmine per le persone che vogliono usarla.

La vera storia, secondo me, è che quando ECMAScript 4 è stato demolito, JavaScript e ActionScript divergevano e JavaScript NON aggiungeva classi come ha fatto ActionScript.

Sospetto che le librerie che supportano OOP (MooTools, Prototype, ecc.) si attengano principalmente a ciò che stanno facendo, ma forse possono usare alcune nuove funzionalità di ECMAScript 5 nelle loro implementazioni per consolidare le cose.

E probabilmente continueremo a vedere approcci interessanti come Joose e Class.js .

Ricorda che ci vorrà del tempo. Abbiamo ancora un gruppo di persone a due cifre che utilizza IE6. Quindi i primi luoghi utili per utilizzare ECMAScript 5 saranno probabilmente sui telefoni cellulari, Adobe AIR e server JavaScript, in cui il browser è (principalmente o rigorosamente) noto.

John Resig ha pubblicato un articolo sulle modifiche agli oggetti di ECMAScript 5 qui .

Answer 2

Penso che la standardizzazione di Object.create consentirà a più persone di usare l'OO basato sul prototipo sottostante senza vergogna. Cercando di nascondere il "nuovo Foo" La sintassi pseudo classica dietro un wrapper rende il codice confuso.