ES6 e OO Design: è una buona idea usare una classe come "Interfaccia"?

0

Di solito su Php o in Java e in altre lingue a orientamento intrinseco con singolo elemento ereditario, quando scrivo un software che utilizzo e interfaccia poi e successivamente implemento la classe che implementa la logica di business.

Ad esempio supponiamo di avere un Uploader di file che ci permette di caricare in vari modi nel nostro caso in un FtpServer o in un AmazonS3 Bucket.

Pertanto dichiaro un'interfaccia FileUploaderInterface

interface FileUploaderInterface 
{
   public function addFile(fromPath,toPath);
   public function removeFile(path);
}

E in seguito implemento un fileUploader separato per ogni modo separato in cui vogliamo caricare i dati:

ad es. per Ftp

class FtpFileUploader implements  FileUploaderInterface
{
   public function addFile(fromPath,toPath)
   {
     //Implement Method
   }
   public function removeFile(path)
   {
     //Implement Method
   }
}

ad es. E per Amazon S3

class AmazonS3FileUploader implements FileUploaderInterface
{
   public function addFile(fromPath,toPath)
   {
     //Implement Method
   }
   public function removeFile(path)
   {
     //Implement Method
   }
}

Con questo ho la flessibilità di avere un Unique Handling per i caricamenti di file indipendentemente da come funzionerà il meccanismo di caricamento stesso, quindi se voglio caricare usando un X api devo solo implementare l'interfaccia FileUploaderInterface .

Ma su ES6 trovo che sono un vero e proprio pesce fuor d'acqua int di software, quindi è una buona idea / pratica dichiarare una classe che ha tutti i metodi di base che vuole che interpreti il ruolo di un'interfaccia

Es: una classe generica per il caricamento di file in un file denominato "FileUploader.js"

export default class FileManager {

  addFile(fromPath,toPath,callback){

  }


  deleteFile(path, callback){

  }
 }

E per ogni modalità di caricamento, sviluppo solo una classe specifica:

ad es. Per il caricamento tramite FTP

import FileManager from './FileUploader.js'

export default class FtpUploadManager extends FileManager {

  addFile(fromPath,toPath,callback){
    // Implement method
  }


  deleteFile(path, callback){
    // Implement method
  }
}

ad es. Per il caricamento tramite Amazon S3

import FileManager from './FileUploader.js'

export default class S3UploadManager extends FileManager {

  addFile(fromPath,toPath,callback){
    // Implement method
  }


  deleteFile(path, callback){
    // Implement method
  }
}

Quali sono i lati positivi e negativi dell'utilizzo del seguente metodo?

La principale differenza che sto chiedendo di Ci sono dei principi OO che sono praticamente applicabili per Javascript? è se un modo specifico di usare classi Js è buono o meno e non generico.

    
posta Dimitrios Desyllas 08.06.2017 - 18:43
fonte

1 risposta

4

No, non dovresti farlo. Non ha senso.

ECMAScript non ha una nozione incorporata di protocol (come originariamente era stata chiamata in Smalltalk) o interface , e una classe con metodi vuoti non è un buona approssimazione.

L'approssimazione corretta di un'interfaccia in ECMAScript è la documentazione. Dovresti documentare i protocolli a cui i tuoi oggetti devono conformarsi. Dopo tutto, è perfettamente possibile che un oggetto si conformi al protocollo anche se non estende FileManager ! Ecco di cosa si tratta OO: finché un oggetto si conforma a un protocollo, puoi usarlo, senza conoscerne l'implementazione (compresa la sua classe / prototipo).

Nota: non sono abbastanza familiare con gli strumenti di documentazione ECMAScript e quanto bene supportano la documentazione del protocollo. (In Ruby, con cui sono più familiare, il supporto è praticamente inesistente, il che è un peccato.)

Un buon esempio dell'uso delle interfacce in ECMAScript sono le interfacce di iterazione definite in il specifica : it prima definisce cosa un'interfaccia è ( grassetto enfasi miniera, corsivo enfasi dalle specifiche):

An interface is a set of property keys whose associated values match a specific specification. Any object that provides all the properties as described by an interface's specification conforms to that interface. An interface is not represented by a distinct object. There may be many separately implemented objects that conform to any interface. An individual object may conform to multiple interfaces.

E poi descrive le diverse interfacce, ad es. l'interfaccia Iterable :

  • Property: @@iterator
  • Value: A function that returns an Iterator object.
  • Requirements: The returned object must conform to the Iterator interface.

Esistono progetti che aggiungono annotazioni di tipo a ECMAScript, ad es. JSDoc supporta le annotazioni sui tipi a scopo di documentazione. (Si noti che c'è una differenza tra digitare annotazioni e digitare controllo ! Le annotazioni sono utili per scopi di documentazione e comunicazione, cioè per umani anche se non controllato da una macchina .)

Esistono anche progetti in grado di comprendere queste annotazioni JSDoc e utilizzarle per il controllo del tipo statico effettivo, ad es. Google Closure Compiler .

Ultimo ma non meno importante, ci sono alcuni linguaggi che sono specificamente progettati per essere familiari agli sviluppatori di ECMAScript, che supportano vari livelli di digitazione. Ad esempio, il flusso di Facebook è un superset piuttosto conservativo di ECMAScript con supporto per le annotazioni di tipo e il controllo del tipo, TypeScript è anche un superset di ECMAScript che è un po 'più ambizioso di Flow (cioè supporta Union e Intersection Types e Generics, e non aggiunge solo la digitazione, ma aggiunge anche altre caratteristiche, ad esempio, supportava classi e generatori prima di ECMAScript, e supporta già async / await ). Fondamentalmente, la differenza tra i due è: entrambi sono superset di ECMAScript, ma Flow è solo un sistema di tipi, mentre TypeScript aggiunge un sistema di tipi e funzionalità aggiuntive.

Spostandosi più lontano da ECMAScript corretto (iniziando con annotazioni di tipo nei commenti di doc, controllori di tipi esterni e superset di ECMAScript), ci sono linguaggi che non intendono essere superset di ECMAScript e deliberatamente devia da esso, come Dart (che è ancora simile a ECMAScript e ha opzionale digitazione) in lingue come PureScript e Elm , che sono molto più nel campo linguistico funzionale strong, rigoroso, tipizzato staticamente e più vicino a Haskell e ML rispetto a ECMAScript, ma ancora esplicitamente progettato per essere utilizzabile come sostituzioni ECMAScript nel browser e sul lato server.

    
risposta data 08.06.2017 - 20:15
fonte

Leggi altre domande sui tag