Definizioni di classi in metodi getter statici

Question

Definizioni di classi in metodi getter statici

#1 da (1 voti)

0

[Node.js / CommonJS]

Sto creando un singolo repository GitHub per il mio strumento che ha una libreria Core, Control, Server e Client. È improbabile che vengano utilizzati tutti allo stesso tempo.

Vorrei che i miei colleghi colleghi a require un punto di ingresso per tutte e quattro le librerie. Così ho implementato questa implementazione discutibile : esportando la classe Core con proprietà statiche che puntano alle altre classi.

Tool.js

class Core
{
    static get Control(){return require("./control")};
    static get Server(){return require("./server")};
    static get Client(){return require("./client")};
    constructor(opts)
    {
    }
}
module.exports = Core;
// module.exports = {Core, Control, Server, Client};

index.js

//Create core instance
const Tool = require("Tool");
const tool = new Tool();

//Create server instance
const ToolServer = require("Tool").Server;

//etc
const ToolClient = require("Tool").Client;

Questo è un cattivo schema? Mi piacerebbe RTFM per quanto riguarda l'importazione di classi da proprietà statiche, ma non sono sicuro di dove trovare risorse che si tuffino in profondità nel funzionamento interno di JavaScript / Node.js / CommonJS.

object-oriented javascript design-patterns object-oriented-design node.js

posta Vic 25.05.2018 - 11:35

fonte

1 risposta

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

Modi efficaci per gestire gli avvisi dell'analizzatore statico causati dall'uso incidentale della riflessione Si dovrebbe usare un decoratore di proprietà Python senza setter o deleter?

score 1 · Answer 1

Come mi sembra questo funziona come spazio dei nomi, attualmente i moduli ES6 consentono qualcosa di simile con le parole chiave export e import :

Core.js

import * as Control from './control';
import * as Server from './server';

export {Control, Server}

Ho usato questo modello in molti progetti e aiuta sempre a mantenere il codice modulare.

L'unica cosa che cambierei nella tua implementazione di require potresti usare un oggetto invece di class , in questo modo è più leggibile e non ci sono funzioni coinvolte, qualcosa del tipo:

Core.js

const Control = require('./control');
const Server = require('./server');

module.exports = {Controle, Server};

// Another alternative would be

module.exports.Control = require('./control');
module.exports.Server = require('./server');

Se vuoi ancora fare un pigro require come presumo per avere funzioni, questa potrebbe essere un'alternativa:

module.exports = {
  Control = () => require('./control'),
  Server = () => require('./server')
}