Troppo specifico di namespacing / packaging

Naviga le tue risposte
2

Sto per iniziare a costruire una libreria C # per la morfologia inglese e francese come progetto parallelo. La biblioteca sarà successivamente unita ad altri aspetti linguistici (fonologia, analisi delle frasi, ecc.). per altre lingue (giapponese e russo).

Purtroppo ho riscontrato un problema nel mio design: la mia gerarchia nello spazio dei nomi è un po 'pazza (secondo me).

Ecco lo spazio dei nomi per l'analisi della frase in inglese (fase di lexing):

Linguistics.English.Syntax.Parsing.Lex

Il suddetto spazio dei nomi includerebbe le classi necessarie per l'utilizzo di un lessico inglese esistente per analizzare un particolare testo.

L'equivalente giapponese sarebbe:

Linguistics.Japanese.Syntax.Parsing.Lex

Sarebbero separati perché il processo di lexing per ogni lingua è diverso. Un esempio più estremo del presente indicativo per coniugazioni di verbi francesi (inflessioni) sarebbe:

Linguistics.French.Inflection.Verb.Indicative.Present

So che posso solo fare using Linguistics.French.Inflection.Verb se sto lavorando alla generazione di tabelle di coniugazione dei verbi, ma l'organizzazione troppo specifica ?

Più specificamente, se / quando gli spazi dei nomi diventano troppo specifici ? Sono stupido o la mia preoccupazione è in realtà un potenziale problema?

    
posta Chris Cirefice 31.03.2015 - 16:00
fonte

2 risposte

1

La tua domanda è basata sull'opinione pubblica e aperta, quindi non sto offrendo nulla di indubbiamente accettabile, ma

  1. certamente una buona denominazione è difficile ← enfasi.

    Ho trovato molte volte che trovare un buon nome o un buon sistema di nomi se non possono essere facilmente modificati con l'uso di strumenti di refactoring più avanti, una volta che il pilota è stato consegnato alla natura, è più difficile quindi basta scrivere il codice tra i margini suggeriti dalla convenzione di codifica.

    Ad esempio, la ridenominazione delle tabelle del database e dei campi del database preservando i dati e non interrompendo le stored procedure con query dinamiche è un compito tecnico molto difficile, che è meglio evitare. Una buona nomenclatura dall'inizio può essere molto importante a volte.

  2. Ecco perché il mio consiglio è: prima di fissare le regole di un namespace, trarre ispirazione da il nome che trova il lavoro già svolto da altri sviluppatori che sviluppano librerie linguistiche in linguaggi di programmazione che supportano namespace come Python , Java , C# ...

    Alcuni elenchi di librerie linguistiche:

    Dagli elenchi di cui sopra, NLTK (Python) e Stanford NLP (Java) sembrano librerie da non sottovalutare.

  3. Dal punto di vista della progettazione del software, se nascondi i dettagli di implementazione specifici della lingua dietro le interfacce e dietro a modello di fabbrica , quindi le librerie specifiche per lingua possono utilizzare qualsiasi convenzione di denominazione interna che desiderano, senza esporre i nomi all'esterno e senza il rischio di rompere nulla.

    Questo è ciò che System.Data.Entity.Design.PluralizationServices.PluralizationService.CreateService Method fa

risposta data 01.04.2015 - 15:06
fonte
2

Avere la lingua (ad es. inglese, francese, giapponese) così lontano nel tuo spazio dei nomi è un odore. Se fossi in te manterrei gli identificatori di lingua solo nei nomi delle classi.

La struttura consigliata per uno spazio dei nomi è qualcosa come 

<company>.<project>.<namespace>.<subNamespace>.<andSoOn>

Quindi, nel tuo caso, potresti prendere in considerazione qualcosa come: 

CC.Linguistics.Syntax.Parsing.Lex

In cui avresti le classi EnglishLexicon , ItalianLexicon , ecc.

    
risposta data 31.03.2015 - 16:41
fonte

Leggi altre domande sui tag

Le implementazioni dell'interfaccia Node nell'API Web violano il principio di sostituzione di Liskov? Modelli per i costruttori di sottoclassi che variano leggermente il costruttore della classe genitore