Evitare lo spazio dei nomi e il nome della classe in conflitto

Naviga le tue risposte
4

Dire che sto sviluppando un'applicazione per il Calcolatore. Ha una classe chiamata: Calculator . Pertanto la struttura del mio spazio dei nomi sarebbe simile a questa: 

MyCompany.Calculator.Core.Calculator

Sfortunatamente, questo non è giusto perché lo stesso nome non dovrebbe essere usato per uno spazio dei nomi e un tipo in esso. Questo è spiegato dettagliatamente in questa altra domanda SO . Una delle risposta a questa domanda suggerisce di risolvere l'ambiguità usando un suffisso Util per lo spazio dei nomi, che quindi assomiglia a questo: 

MyCompany.CalculatorUtil.Core.Calculator

Risolve l'ambiguità di denominazione nel linguaggio di programmazione. Tuttavia, questo tipo di denominazione è in contraddizione con le buone pratiche di denominazione DDD: perché Util sembra essere una " parola donnola " secondo questo articolo sulla denominazione nella lingua ubiquitaria e questi dovrebbero essere evitati.

Qual è il modo migliore per evitare un conflitto qui nel caso di una calcolatrice?

L'applicazione che sto sviluppando è molto più complessa di una semplice calcolatrice, tuttavia il principio rimane valido.

    
posta w0051977 01.12.2017 - 12:14
fonte

2 risposte

2

Il nome della tua applicazione 'Calcolatrice'? se è così puoi scoprire che quel nome è già stato usato.

Ti consiglierei anche di NON usare myCompany come parte dello spazio dei nomi. So che è un modo standard, ma i nomi delle società cambiano.

Basta: 

MyApplicationsRealName.App
MyApplicationsRealName.LibraryName.ClassName
    
risposta data 01.12.2017 - 12:56
fonte
2

Say I am developing a Calculator application. It has one class called: Calculator

Che cosa pensi significhi il nome della classe Calculator ? Cosa ti aspetti di trovare lì, solo leggendo quel nome? L'interfaccia utente, la logica di dominio, i dati, il codice di avvio dell'applicazione? Non puoi dire, questo nome di classe è troppo ambiguo per dare un senso.

Quindi, se dovessi progettare un'applicazione Calcolatrice, potrebbe esserci una classe CalculatorDialog per l'interfaccia utente, un CalculatorController o CalculatorLogic per la logica del dominio, un CalculatorPresenter o CalculatorViewModel quando si effettua un Architettura MVP o MVVM e CalculatorState se si decide di inserire esplicitamente lo stato in alcuni oggetti per la persistenza. Potrebbero esserci ulteriori classi di infrastruttura come una classe Program per il punto di ingresso dell'applicazione. Ma non una classe chiamata Calculator , questo nome ha senso solo a livello di spazio dei nomi, ma non a livello di classe.

Questo non è limitato a questo specifico esempio. Un programma o una libreria si compone sempre di parti diverse, quindi dai alle parti un nome che le distingue chiaramente dal nome del programma e le rende distinguibili dalle altre parti, quindi il problema non si verificherà.

    
risposta data 01.12.2017 - 22:58
fonte

Leggi altre domande sui tag

Quale architettura dovrei scegliere per Microservices che sono sia asincroni che sincronizzati? Questo contratto su un utente API è inevitabile?