Quando usare "è un" o "ha un"? [chiuso]

Question

Quando usare "è un" o "ha un"? [chiuso]

#1 da (4 voti)

0

Nella mia applicazione node.js, ho una classe di coda che ha metodi push e pop e una proprietà data . Ho una classe Event che gestisce un evento e la spinge in coda.

Se penso orientato agli oggetti, la relazione tra coda ed evento è meglio modellata come "è a" (ereditarietà) o "ha a" (composizione)?

Primo approccio:

var util = require('util'),
    array = [];

function Q(source){
    this.data = source;
}

Q.prototype.push = function(x){
    this.data.push(x);
};

Q.prototype.show = function(){
    console.log(this.data);
};

function Event(y){
    Q.call(this, y);
}

util.inherits(Event,Q);

Event.prototype.trigger = function(bb){
 //some logic
 this.push(bb);
};

var x = new Event(array);
x.trigger('hi');
x.show();

Secondo approccio:

var array = [];
function Q(source){
    this.data = source;
}

Q.prototype.push = function(x){
    this.data.push(x);
};

Q.prototype.show = function(){
    console.log(this.data);
};

function Event(y){
    this.arr = new Q(y);
}

Event.prototype.trigger = function(bb){
    //some logic
    this.arr.push(bb);
};

var x = new Event(array);
x.trigger('hi');
x.show();

object-oriented javascript concepts node.js

posta Jafar Rasooli 12.01.2016 - 12:07

fonte

1 risposta

Leggi altre domande sui tag object-oriented javascript concepts node.js

Qual è il nome per metodi / funzioni definiti dall'utente che vengono chiamati implicitamente? [chiuso] L'istruzione condizionale 'OR' continua se già vera? [duplicare]

score 4 · Accepted Answer

Concettualmente, l'ereditarietà (is-a) è una specializzazione di composizione (ha-a). ( da Reg Braithwaite ) Entrambi realizzano la stessa cosa (ecco perché puoi chiedere a domanda come questa), ma l'ereditarietà manca della flessibilità della composizione. L'ereditarietà rende rigido il tuo codice.

Da un punto di vista pratico, ciò non importa tanto in JavaScript poiché JavaScript non è limitato all'ereditarietà singola. Ciò che chiamiamo ereditarietà è in realtà un prototipo di patching e delega delle funzioni. Non c'è nulla che ci impedisca di creare un mixin da diversi "tipi". Questo ha più in comune con composizione del tipo di Go rispetto al modello di ereditarietà di Java o C #. Non rende rigido il tuo codice.

Tuttavia, sembra strano affermare che Event è-a Queue . É davvero? Sembra più probabile che un Event sia un modello di qualche azione nella tua app e utilizza (ha-a) un Queue per gestire il suo flusso di lavoro. Se un Event è veramente un Queue , dovrei essere in grado di usarlo ovunque io usi un Queue senza pensarci due volte:

var q = new Event();
q.push("hi");
q.pop();

Questo non mi sembra giusto. È un tratto. Questo è un posto perfetto per evitare l'eredità a favore della composizione.

Vedi anche: Principio di sostituzione di Liskov