I metodi Unisci e Unisci hanno senso per una classe di percorsi?

1

Sto scrivendo una classe path che al momento ha un metodo chiamato Combine che funziona come .NET Path.Combine. Se un argomento è un percorso assoluto (approssimativamente perché inizia con \ ), quindi sostituisce qualsiasi elemento a sinistra, quindi:

Combine("c:\folder", "two"); // produces "c:\folder\two"
Combine("c:\folder", "\two"); // produces "c:\two"

Sono preoccupato che questo catturi le persone che si aspettano che il secondo produca anche "c: \ folder \ two" e mi chiedo come proteggersi da questo.

Un design alternativo dovrebbe avere un parametro enum per selezionare il comportamento:

enum CombineMethod { respectAbsolute, ignoreAbsolute };

Path Combine(CombineMethod combineMethod, Path a, Path b);

Questo sembra un po 'prolisso, quindi un'altra alternativa che sto considerando è avere due metodi:

Path Join( Path a, Path b );
Path Merge( Path a, Path b);

Merge("c:\folder", "two"); // produces "c:\folder\two"
Merge("c:\folder", "\two"); // produces "c:\two"

Join("c:\folder", "two"); // produces "c:\folder\two"
Join("c:\folder", "\two"); // produces "c:\folder\two"

Qualcuna di queste alternative sembra affatto intuitiva, pensi che sarebbe facile chiamare accidentalmente la funzione sbagliata. O hai migliori suggerimenti di progettazione in modo che gli utenti possano ottenere il comportamento desiderato senza accorgersi del comportamento sbagliato?

    
posta Scott Langham 12.02.2016 - 18:30
fonte

3 risposte

4

Il tuo problema è questo:

Combine("c:\folder", "\two"); // produces "c:\two"

Non è più combinabile, è sostitutivo.

L'intero punto di avere un metodo Combine è che il consumatore non deve preoccuparsi di gestire i separatori di percorsi. Questi dovrebbero avere tutti lo stesso risultato:

Combine("c:\folder", "two");
Combine("c:\folder\", "two");
Combine("c:\folder", "\two");
Combine("c:\folder\", "\two");

Quello che vuoi è una funzione per estrarre la lettera di unità e quindi combinare il risultato di quello. In .NET, che assomiglia a questo:

Path.Combine(Path.GetPathRoot("c:\folder"), "\two");
    
risposta data 12.02.2016 - 21:39
fonte
0

Non trovo Join / Unisci intuitivo. La mia preferenza è di omettere il supporto per ignorare completamente i percorsi assoluti, ma per offrire una funzione di assetto. Questo potrebbe essere un membro di Path o una funzione di utilità separata. Un membro del percorso rimuoverà spazi vuoti iniziali e finali e barre (e possibilmente gestirà .. ). Con una funzione di utilità, si fornisce un sovraccarico che supporta un predicato (l'approccio adottato da Boost) o un array di caratteri (l'approccio adottato da C #) per determinare quali caratteri tagliare.

Detto questo, ho trascorso molto più tempo con C # rispetto a C ++, quindi le mie preferenze sono strongmente orientate al C #.

    
risposta data 13.02.2016 - 08:33
fonte
0

Bene, la tua funzione, dato un percorso iniziale e un percorso potenzialmente relativo, restituisce il percorso risultante.

Sì, combine avrebbe senso, come membro statico della classe Path . Eppure, perché lo fai diventare membro? Se vuoi una funzione membro, sembra che dovrebbe essere un costruttore di due argomenti.

combinePaths è un buon nome per una funzione gratuita.

Per inciso, una funzione per inserire il separatore di percorso delle piattaforme tra i componenti del percorso passati è abbastanza inutile, è possibile fornire il separatore come una stringa costante e utilizzare un metodo di splicing delle stringhe generico senza alcun problema.

Pensa se non vuoi semplicemente usare / (forward-slash) come separatore di percorsi internamente e tradurlo in \ al volo su Windows per la presentazione e così via. Il più delle volte, puoi lasciare la conversione in WINAPI, come MSDN dice :

Note File I/O functions in the Windows API convert "/" to "\" as part of converting the name to an NT-style name, except when using the "\?\" prefix as detailed in the following sections.

    
risposta data 13.02.2016 - 16:45
fonte

Leggi altre domande sui tag