Motivos por trás da implementação não intuitiva do C # String.Split ()

Em C #, se eu quiser dividir um stringpor outro string, tenho que fazer algo assim:

testString.Split(new string[] { "anotherString" }, StringSplitOptions.None);

Na String.Splitdocumentação sobrecarregada do MSDN, podemos ver a implementação e por que essa ligação deve ser feita.

Vindo do Python , é difícil para mim entender corretamente por que essa ligação é necessária. Quero dizer, eu poderia usar Regex.Splitpara obter uma sintaxe semelhante à implementação do Python, mas precisaria fazê-lo com o custo de menos desempenho (tempo de configuração) para algo simples .

Então, basicamente, minha pergunta é por que diabos não podemos simplesmente fazer:

testString.Split("anotherString");

Observe que não estou sugerindo nenhum protótipo nem implementação. Entendo por que você não conseguiu implementar a versão acima, considerando a API atual. Meu objetivo era entender por que essa API poderia ter sido criada considerando o benefício que a sintaxe acima traz. A partir de agora, a flexibilidade parece ser o objetivo da corrente String.Splitque faz sentido, mas, para ser sincero, realmente pensei que havia algum tipo de ganho de desempenho em algum lugar. Eu acho que estava errado.

Às vezes, a divisão em mais de um caractere / sequência de caracteres é útil; portanto, a API permite que você forneça uma matriz, oferecendo a máxima flexibilidade. No caso de chars, você obtém simplicidade de sintaxe e flexibilidade, já que o parâmetro está marcado como paramspara que você possa escrever em Split('x')vez de Split(new[]{'x'}).

Então, por que não existe uma opção semelhante para strings, permitindo que você escreva Split("x")?

Essa talvez seja uma consequência infeliz de como a API é projetada. Inicialmente, ele só permitia dividir os caracteres. A divisão em strings foi adicionada na 2.0, provavelmente porque é mais complexa de implementar. Mas não foi possível adicionar String.Split(string)ou String.Split(string[])sobrecarregar, pois isso tornaria a expressão testString.Split(null)ambígua e esse código não seria mais compilado.

testString.Split(null) é, na verdade, um idioma bastante comum, pois divide a cadeia de caracteres em espaço em branco; portanto, essa quebra seria muito ampla para ser aceitável.

O uso de um nullparâmetro como uma opção para comportamentos especiais geralmente é considerado um design ruim hoje em dia, por isso acho justo dizer que essa API é falha.

Também não existe Split(string[], Int32), provavelmente por uma razão semelhante - seria ambíguo Split(char[], Int32)se o primeiro parâmetro fosse null. Não são sobrecargas semelhantes com os StringSplitOptionsparâmetros, mas estes foram todos adicionados ao mesmo tempo em 2,0, então há ambiguidade foi introduzido no código existente.

Nota

Para deixar claro, esta é apenas minha hipótese, não conheço o pensamento real dos designers de estrutura .net.

Não sendo o autor dos métodos, não sei por que esse conjunto de sobrecargas foi escolhido. No entanto, há duas coisas a serem observadas aqui:

1. Se você estiver dividindo em um único caractere, a public string[] Split(params char[] separatorversão) poderá ser usada assim:

   var splitValues = testString.Split(',');

   como o char[]é um paramsparâmetro

2. Você pode adicionar facilmente seu próprio método de extensão aqui para obter o que deseja:

   public static class StringExtensions
   {
       public static string[] Split(this string source, string separator)
           => source.Split(new string[] { separator }, StringSplitOptions.None);
   }

   e agora testString.Split("anotherString");funcionará para você.

Idiomas diferentes têm regras um pouco diferentes para conversões implícitas e sobrecargas, e o .NET Framework foi projetado para ser usado com qualquer um deles. No Option Strict Offdialeto do VB.NET, um valor do tipo Stringpode ser passado para uma função que espera um Char[]comportamento equivalente a chamar ToCharArray()a string.

Eu acho que a coisa mais sensata a fazer seria ter nomes separados para Split(que aceita um único Charou String) e SplitMulti(que aceitaria um Char[]ou String[]), mas o .NET às vezes parece preferir usar a sobrecarga sozinho para escolher diferentes tipos de operações. Infelizmente, não conheço nenhuma maneira de usar String.Splitpara acomodar quaisquer cenários de uso que exijam a distinção de diferentes tipos de delimitadores que não sejam divididos separadamente em cada um.

Outra omissão é uma opção para preservar delimitadores, incluindo-os no final da sequência anterior ou no início da sequência seguinte, ou com elementos de matriz com números ímpares serem delimitadores, enquanto elementos com números pares são o que há entre eles.