Perché utilizzare l'ereditarietà di stile OOP basata su classi in javascript?

Question

Se non sbaglio completamente ogni framework/libreria/approccio in javascript tende oggi a imitare l'ereditarietà di stile OOP basata sulla classe. Le ragioni di questo sembrano essere le persone che pensano che l'ereditarietà delle OOP basata sulla classe sia molto più facile da capire e che la maggior parte dei programmatori conosca l'OOP.

Nella mia esperienza non trovo prove per nessuna di queste opinioni. Penso che l'ereditarietà prototipale di javascript sia giusta (e dubito dell'utilità di forzare un altro paradigma su un linguaggio rispetto a quello su cui è costruito). La maggior parte degli sviluppatori che incontro non sono nemmeno così bravi nell'OOP classico. Quindi quali sono i motivi per scegliere l'ereditarietà classica dello stile OOP rispetto all'ereditarietà prototipale?

Answer 1

Penso che la risposta sia nella tua domanda: la maggior parte dei programmatori ha molta più familiarità con l'OOP basato sulla classe rispetto al prototipo.

In effetti, direi che la maggior parte non crede che tu possa avere oggetti senza classi.

Answer 2

Quando stavo scrivendo i miei primi script, era bello e pratico avere un linguaggio così semplice. Ma oggi non si desidera solo attivare un pulsanteColor, si desidera creare applicazioni complesse in JavaScript. Altri potrebbero voler usare la tua applicazione popolare e adorare vedere la community fornire plugin.

Ora, questo è molto più facile da realizzare con OOP, soprattutto perché molti programmatori hanno familiarità con i concetti OOP.

Answer 3

Un motivo potrebbe essere che il lato server è probabile che sia OO (ASP.NET, Java, ecc.), Quindi è più semplice pensare nello stesso paradigma sul client. Non necessariamente meglio, ma più facile.

Answer 4

nota che, anche se si sta discutendo per OOP prototipo-based, si chiama 'prototipale', e basato su classi OOP solo 'OOP'. quindi, tu stesso soffri di questo pregiudizio, pensando che OOP => classi, prototipi => qualcos'altro.

e poiché la maggior parte della gente pensa che OOP sia nel modo giusto indipendentemente dal problema, i prototipi devono essere inferiori.

così, per rispondere alla tua domanda, si tratta di due fattori:

1. una cattiva definizione: "OOP => classi"
   • di propaganda: "deve essere OOP, o non sei degno "

in quanto si sta ancora delimitato dal primo momento, si tenta di spiegare che i prototipi sono un'eccezione del secondo. molto più facile è correggerli:

1. ci sono molti modi per fare gli oggetti, le classi sono solo la più semplice per le lingue statiche. alla maggior parte delle persone viene insegnato a programmare con linguaggi statici e molti di loro cercano di usare qualsiasi lingua proprio come la prima che hanno imparato.

   • ci sono molti modi per strutturare una soluzione di programmazione, OOP sono grandi in alcuni e pessimi in altri.

Answer 5

direi che il linguaggio stesso dirige le persone nella mentalità classica con la sua scelta di "nuovo" come parola chiave, e con l'introduzione di concetti come "costruttori" nella specifica del linguaggio. In un certo senso questo è limitante: immagina il cambiamento di mentalità se invece avessimo una parola chiave clona e il concetto di tratti ala SELF.

Answer 6

mi sento come se si conosce già la risposta alla tua domanda, perché lei ha dichiarato una parte di esso quando hai detto

ragioni di questa sembrano essere le persone pensiero basato classe OOP eredità è molto più facile capisci e che la maggior parte dei programmatori conosce OOP .

Né il paradigma è più giusto dell'altro per affrontare un problema. Credo che la ragione principale sia che a tutti viene insegnato OOP attraverso Java in questi giorni. Quindi quando le persone incontrano OOP pensano "oh classi" perché è ciò che hanno familiarità con. E ogni volta che vogliono risolvere un problema, molto probabilmente useranno ciò che sanno.

Vorrei anche affermare che non ha alcun beneficio per il programmatore utilizzare un paradigma che non ha familiarità con. La maggior parte di noi deve utilizzare javascript per lo sviluppo web lato client e utilizzare un linguaggio OOP basato sulla classe sul server. Personalmente non vorrei che l'impedenza di impedenza di OOP ogni volta che dovevo guardare il lato JavaScript di un'applicazione.

Ad un certo livello il fatto che tutti stiano cercando di implementare OOP in classe in javascript è un problema educativo. Ad un altro livello è psicologico.

Answer 7

Per molto tempo ho considerato l'OOP basato su prototipo come versione debole, errata e errata di OOP basata su classi. Poi, dopo che una quantità critica di informazioni è trapelata nella mia testa, ora capisco l'OOP in modo più astratto e trovo entrambe le vie accettabili in generale.

Answer 8

Quindi quali sono i motivi per scegliere l'ereditarietà di stile OOP classica rispetto all'ereditarietà del prototipo? In realtà, credo che alcuni quadri siano "una specie di" combinazione di approcci. Prendiamo ad esempio il modello di ereditarietà della combinazione parassita. Questo è ciò che sta facendo YAHOO.lang.extend.

Utilizza l'ereditarietà prototipale e una funzione di supporto per ereditare i prototipi e il furto del costruttore. Wow, che suona complesso ... beh sì, è - ecco la mia implementazione e di test, ad esempio:

// Prototypal Inheritance 
Object.prototype.inherit = function(p) { 
    NewObj = function(){}; 
    NewObj.prototype = p; 
    return new NewObj(); 
}; 

// Paraphrasing of Nicholas Zakas's Prototype Inheritance helper 
function inheritPrototype(subType, superType) { 
    var prototype = Object.inherit(superType.prototype); 
    prototype.constructor = subType; 
    subType.prototype = prototype; 
}; 
function SubType(name, age) { 
    Parent.call(this, name); 
    this.age = age;  
}; 
inheritPrototype(SubType, Parent); 
SubType.prototype.getAge = function() { 
    return this.age; 
}; 

Ho un banco di prova per questo codice:

describe 'Parisitic Combination Inheritance' 
it 'should use inheritPrototype (to call parent constructor once) and still work as expected' 
    sub = new SubType("Nicholas Zakas", 29) 
    sub.toString().should.match /.*Nicholas Zakas/ 
    sub.getAge().should.eql 29 
    charlie = new SubType("Charlie Brown", 69) 
    charlie.arr.should.eql([1,2,3]) 
    charlie.arr.push(999) 
    charlie.arr.should.eql([1,2,3,999]) 
    sub.arr.should.eql([1,2,3]) 
    sub.should.be_an_instance_of SubType 
    charlie.should.be_an_instance_of SubType 
    (sub instanceof SubType).should.eql true 
    (sub instanceof Parent).should.eql true 
end 
    end 

E, naturalmente, se si' prestando attenzione ai miei letterali si vede: Nicholas Zakas, il ragazzo da cui ho preso questo;) Le grandi vittorie per questo: instanceof funziona (un grosso affare alcuni dicono e io sono d'accordo); le istanze non condividono lo stato sui tipi di riferimento come gli array (un biggie!); il costruttore genitore ha chiamato solo una volta (un grosso problema!).

BTW, non ho esempi della maggior parte dei modelli di eredità popolari qui: My TDD JS Examples