In un mondo ideale, le nuove versioni introdurranno funzionalità aggiuntive pur restando al 100% retrocompatibili con le precedenti versioni dell'API. Sfortunatamente, il mondo ideale rimane sfuggente e non è sempre possibile mantenere la piena retrocompatibilità. Un suffisso con versione è lo schema appropriato in questo caso.
La convenzione di denominazione standard .NET è quello di utilizzare la numerazione incrementale, come Class, Class2, Class3, ecc .. Questo deriva dalla convenzione di denominazione per interfacce COM, progettate esattamente per il caso d'uso si sta descrivendo.Ad esempio, l'interfaccia IHTMLDocument ha attualmente 8 versioni, da IHTMLDocument fino a IHTMLDocument8.
Il Framework Design Guidelines libro originale, da Cwalina e Abrams, raccomandato esplicitamente questa pratica, con gli autori hanno a dire:
DO utilizzare un suffisso numerico per indicare una nuova versione API esistente, se il nome esistente dell'API è l'unico nome che ha senso (ovvero, è uno standard di settore) e l'aggiunta di qualsiasi suffisso significativo (o la modifica del nome) non è un'opzione appropriata.
// old API
[Obsolete("This type is obsolete. Please use the new version of the same class, X509Certificate2."]
public class X509Certificate { ... }
// new API
public class X509Certificate2 { ... }
La vecchia convenzione, seguito dal team originale di Windows, è stato quello di aggiungere il suffisso Ex a nuovi e migliorato versioni di un'API, che deriva dalla parola "estendere". Questo non è in grado di scalare bene, tuttavia, portando a funzioni confuse con suffisso ExEx. Non penso ci fosse un ExExEx; tutti avevano paura di toccare quelle API. I Framework di progettazione Linee guida consiglia esplicitamente contro questa pratica, la gente che ha continuato a all'architetto .NET aver imparato la lezione:
NON usare il "Ex" (o simili) suffisso per un identificatore per distinguerlo da una versione precedente della stessa API.
[Obsolete("This type is obsolete. ..."]
public class Car { ... }
// new API
public class CarEx { ... } // the wrong way
public class CarNew { ... } // the wrong way
public class Car2 { ... } // the right way
public class Automobile { ... } // the right way
Ovviamente, come loro ultimo codice sentori di esempio, se si sta aggiungendo il supporto per una specifica caratteristica nella nuova versione delle API, si sarebbe migliore fuori nominare la nuova classe/interfaccia con un riferimento a quella particolare caratteristica.
E sebbene quanto sopra si sia concentrato quasi esclusivamente su classi e interfacce, la stessa logica sarebbe valida per tutte le funzioni membro di quella classe che potrebbero essere aggiunte nelle revisioni successive. La funzione originale potrebbe mantenere il suo nome originale, con la funzione appena aggiunta con un nome diverso che riflette la sua iterazione o la sua funzionalità aggiunta.
Non sono sicuro se esiste una convenzione di denominazione per questo, ma vorrei usare 'MyClassVX' e contrassegnare i precedenti obsoleti. – thijmen321
Si potrebbe argomentare che questa domanda è principalmente basata sull'opinione, così come tutte le domande sulle convenzioni di denominazione. Forse la tua domanda potrebbe essere meglio accolta a [programmers.stackexchange.com] (http://programmers.stackexchange.com)? –