Come evitare le somiglianze dei nomi tra le tue classi e quelle native? [chiuso]


9

Ho appena incontrato un "problema interessante", di cui vorrei la tua opinione su:

Sto sviluppando un sistema e per molte ragioni (significato: astrazione, indipendenza tecnologica, ecc.) Creiamo i nostri tipi per lo scambio di informazioni.

Ad esempio: se esiste un metodo che si chiama SendEmail ed è invocato dalla logica di business, ha un parametro di tipo OurCompany.EMailMessage, che è un oggetto completamente indipendente dalla tecnologia e contiene solo "dati rilevanti per l'azienda" (per istanza, nessuna informazione sulla codifica head).

All'interno della funzione SendEmail, otteniamo queste informazioni dal nostro oggetto EMailMEssage e creiamo un oggetto MailMessage (questo è specifico per la tecnologia) in modo che possa essere inviato sulla rete.

Come puoi già notare, la nostra classe ha un nome molto simile alla classe di lingua "nativa". Il problema è: questo è esattamente quello che sono, i messaggi e-mail, quindi è difficile trovare un altro nome significativo per loro.

Hai questo problema spesso? Come lo gestisci?

Modifica: @mgkrebbs ha appena commentato l'utilizzo di nomi completi. Questo è il nostro approccio attuale, ma un po 'troppo prolisso, IMHO. Vorrei qualcosa di più pulito, se possibile.


2
Usare sempre la qualifica sembra una soluzione praticabile, anche se un po 'prolissa. Usa OurCompany.EMailMessage per un tipo e SendEmailClass.EMailMessage (o qualsiasi altra cosa) per l'altro. C'è qualche problema con questo approccio?
mgkrebbs,

Sì, ci ho pensato, ma diventa prolisso. Vorrei qualcosa di "più pulito", ma la soluzione che hai proposto è la mia attuale. Aggiungerò questo alla spiegazione
JSBach,

3
I nomi vengono in un contesto. Di solito uno spazio dei nomi o qualcosa del genere. Quindi non dovrebbe essere un problema.
deadalnix,

+1, mi piace questa domanda. Una volta ho fatto questa domanda a un istruttore circa 7 anni fa e ha pensato che fossi un "...." completo
NoChance,

Che lingua stai usando? La risposta è specifica della lingua. In generale, la risposta è "usa uno spazio dei nomi". In una singola applicazione Java è abbastanza comune avere lo stesso nome di classe usato da una mezza dozzina di librerie.
Kevin Cline,

Risposte:


3

Questo è un problema relativo allo spazio dei nomi che utilizzerai per il tuo progetto.

Fondamentalmente uno spazio dei nomi è la raccolta delle parole chiave fornite da tutte le classi e / o da tutte le classi che si desidera utilizzare nel progetto (comprese le classi standard normalmente fornite con la lingua / compilatore / IDE).

Poiché uno spazio dei nomi è una raccolta, alcune regole vengono applicate in sostanza per impedire la creazione di un pasticcio di termini senza alcun comportamento correlato e alcuni linguaggi come C # consentono anche di definire il proprio spazio dei nomi come al solito e utilizzarlo anche in altre classi.

Non confondere lo spazio dei nomi con la parola chiave di base della lingua, sono entrambi una raccolta di parole chiave ma con una grande differenza tra i due: è possibile modificare uno spazio dei nomi ma di solito non è possibile modificare le parole chiave di base di una lingua. La somma tra lo spazio dei nomi che hai usato nel tuo progetto e le parole chiave di base della lingua che usi ti dà la quantità totale di parole chiave.

L'argomento è ampiamente discusso in rete, posso suggerire una ricerca di base con i termini "spazio dei nomi [la tua lingua]" o qualcosa del genere. Non rispondo direttamente alla tua domanda semplicemente perché puoi avere un approccio diverso per le diverse lingue.


3

Bene, il mio vecchio team di sviluppo usa per aggiungere l'acronimo dell'applicazione in ogni classe personalizzata. Abbiamo avuto ad esempio la classe ABCEmail .

Penso che sia più semplice che fare affidamento sullo spazio dei nomi, ma può anche essere una soluzione complementare all'utilizzo dello spazio dei nomi.

Ultimo ma non meno importante, dal momento che stai creando un nuovo oggetto, significa che l'oggetto nativo non risponde alle tue esigenze, quindi il tuo nome del tuo file e-mail potrebbe essere personalizzato e -mail, e-mail avanzata ... ecc


1
Concordato sul tuo ultimo punto, ma perché sarebbe OAEmailmeglio di OurApplication.Email? OAEMailha un impatto su ogni parte del software, mentre la notazione dello spazio dei nomi ha un impatto solo là dove avviene la conversione ed entrambe le classi sono usate nello stesso file sorgente.
Steven Jeuris,

1
Penso che il prefisso sia una buona idea quando la tua lingua non supporta gli spazi dei nomi. Ma se il linguaggio supporta una qualche forma nello spazio dei nomi, allora usalo (questo è il problema che gli spazi dei nomi sono stati progettati per risolvere!). `
Martin York,

@Steven Jeuris: il nome della classe dovrebbe essere selezionato una volta creato. Successivamente, trovo una cattiva pratica cambiarlo ... a causa di tutti gli impatti inutili.
Amine,

@Loki Astari: non so quale IDE stai utilizzando, ma trovo che un nome di classe diverso sia più facile da gestire durante la ricerca o l'apertura di una determinata classe. Ho visto progetti con una versione personalizzata di "email" e ogni volta che volevo aprire il file dovevo sfogliare diversi spazi dei nomi. Il tuo punto è ancora valido, suppongo che sia soggettivo per l'organizzazione del pacchetto quante classi personalizzate verranno create.
Amine,

1
@Amine: Non mi ero reso conto che in realtà stavi litigando contro gli spazi dei nomi. Ti suggerisco di leggere un po 'di più gli spazi dei nomi per vedere tutti i vantaggi del loro utilizzo: incapsulamento, eliminazione dell'ambiguità, meno ridondanza, ... Ps: la maggior parte degli IDE moderni ha funzionalità di ricerca che ti consentono di trovare rapidamente un file sorgente senza dover sfogliare la gerarchia. Quanto al tuo commento per me: il refactoring costante fa parte dello sviluppo del software. Quando riesci a trovare un nome più adatto, di grande impatto o meno, dovresti considerare di rinominarlo. È comunque meglio discuterne prima con i colleghi.
Steven Jeuris,

3

Che lingua stai usando? La risposta è specifica della lingua. In generale, la risposta è "usa spazi dei nomi". Non avrei quasi mai manipolato il nome del tipo per evitare un conflitto con uno spazio dei nomi esterno.

In una singola applicazione Java è abbastanza comune avere lo stesso nome di classe (ad es. "Data") definito in mezza dozzina di spazi dei nomi. Se una classe deve utilizzare due classi Date separate, una delle classi Date deve essere pienamente qualificata ovunque appaia, poiché Java non supporta gli alias di tipo. In C ++ la vita è più facile; puoi semplicemente rinominarne uno con un typedef.


Stavo per pubblicare una risposta simile, ma invece dell'esempio di alias C ++ volevo menzionare l' uso della direttiva alias in C # .
Steven Jeuris,

@Steven: stavo per citare C # anziché C ++, ma sono passati alcuni anni da quando ho programmato in C # e non ne ero sicuro.
Kevin Cline,

2

Hai questo problema spesso? Come lo gestisci?

Dipende molto dalla lingua che usi. In c ++ e java, questo problema viene risolto utilizzando gli spazi dei nomi. Sto usando c ++ e succede che ho classi diverse con lo stesso nome. Non è un problema, poiché si trovano in spazi dei nomi diversi.

In altre lingue, non ci sono modi ma fornendo nomi diversi.


Per il computer non è un problema, ma per lo sviluppatore potrebbe esserlo, ad esempio EmailMessage e MailMessage.
JSBach,

@Oscar Ovviamente. Per il computer può essere xyz123e funziona ancora allo stesso modo. Non vedo altro modo quindi andare verboso (hai detto nei commenti che stai cercando di evitarlo).
BЈовић

2

La tua domanda è molto buona Che ne dici se aggiungi il prefisso al tuo metodo con un prefisso come U (ou) o cls (abbreviazione di classe)? Per esempio:

clsEMailMEssage o uEMailMEssage

Ciò non richiede molta digitazione e si può immediatamente dire che il tipo è "tuo".

Modifica - In risposta ai primi 2 commenti:

Vorrei attirare l'attenzione del lettore sul fatto che: non tutte le notazioni ungheresi sono uguali. Dovremmo distinguere tra sistema ungherese e app ungherese , suppongo che il suggerimento sopra segue il tipo di app ungherese, che non è dannoso.

Il danno associato alla notazione ungherese del sistema, come nel nominare un ID un intID, non è presente nel suggerimento sopra.

Per ulteriori informazioni, dai un'occhiata a: Far sembrare sbagliato il codice sbagliato - Joel On Software


3
Ogni volta che qualcuno raccomanda la notazione ungherese, Dio uccide un gattino.
Konamiman,

2
Anche BIgHUmpCAmelCAsing non aiuta.
Steven Jeuris,

I commenti sopra sono apprezzati. Vediamo le mie modifiche, anche se so che alcuni di noi non cambieranno idea, dopo tutto chi vuole che un gattino venga ucciso? :)
NoChance,

Ho rimosso il voto negativo ora che hai aggiunto un ragionamento valido. Tuttavia, non sono d'accordo sul fatto che Apps Hungarian sia più appropriato dei nomi in questo scenario. Quando la lingua supporta gli alias, questa è una soluzione molto più adatta. Vedi la risposta di kevin cline .
Steven Jeuris,

@Steven Jeuris, grazie per il tuo commento. Gli spazi dei nomi sono perfetti, tranne per il fatto che sono abbastanza lunghi da continuare a scrivere, controllerò il link che hai fornito.
NoChance,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.