Razones detrás de la implementación no intuitiva de C # String.Split ()

En C # si quiero dividir un stringpor otro string, tengo que hacer algo así:

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

A partir de la String.Splitdocumentación sobrecargada de MSDN podemos ver la implementación y por qué se debe realizar dicha llamada.

Viniendo de Python , es difícil para mí entender correctamente por qué se necesita dicha llamada. Quiero decir que podría usar Regex.Splitpara obtener una sintaxis similar a la implementación de Python, pero tendría que hacerlo a costa de un menor rendimiento (tiempo de configuración) para cualquier cosa simple .

Básicamente, mi pregunta es por qué demonios no podemos simplemente hacer:

testString.Split("anotherString");

Tenga en cuenta que no estoy sugiriendo ningún prototipo ni implementación. Entiendo por qué no pudo implementar la versión anterior teniendo en cuenta la API actual. Mi objetivo era entender por qué podría haberse creado una API de este tipo teniendo en cuenta el beneficio que aporta la sintaxis anterior. A partir de ahora, la flexibilidad parece ser el objetivo de la corriente String.Splitque tiene sentido, pero para ser sincero, realmente pensé que había algún tipo de ganancia de rendimiento en alguna parte. Creo que estaba equivocado.

A veces es útil dividir en más de un char / string, por lo que la API le permite proporcionar una matriz, lo que le brinda la máxima flexibilidad. En el caso de chars, obtienes tanto la sintaxis como la flexibilidad, ya que el parámetro está marcado como paramspara que puedas escribir en Split('x')lugar de hacerlo Split(new[]{'x'}).

Entonces, ¿por qué no hay una opción similar para las cadenas, que le permite escribir Split("x")?

Esta es quizás una consecuencia desafortunada de cómo está diseñada la API. Inicialmente solo permitía dividirse en caracteres. La división en cadenas se agregó en 2.0, probablemente porque es más complejo de implementar. Pero no fue posible agregar String.Split(string)o String.Split(string[])sobrecargar, ya que esto haría que la expresión fuera testString.Split(null)ambigua y este código ya no se compilaría.

testString.Split(null) en realidad es un idioma bastante común, ya que divide la cadena en espacios en blanco, por lo que dicha rotura sería demasiado generalizada para ser aceptable.

El uso de un nullparámetro como un interruptor para un comportamiento especial generalmente se considera un mal diseño en estos días, por lo que creo que es justo decir que esta API es simplemente defectuosa.

Tampoco hay Split(string[], Int32)ninguno, probablemente por una razón similar: sería ambiguo Split(char[], Int32)si el primer parámetro es null. No son sobrecargas similares con los StringSplitOptionsparámetros, pero estos fueron añadidos al mismo tiempo en 2.0, así que no hay ambigüedad se introdujo en el código existente.

Nota

Para ser claros, esta es solo mi hipótesis, no sé el pensamiento real de los diseñadores de marcos .net.

Al no ser el autor de los métodos, no sé por qué se eligió ese conjunto de sobrecargas. Sin embargo, hay dos cosas a tener en cuenta aquí:

1. Si se está dividiendo en un solo carácter, entonces la public string[] Split(params char[] separatorversión) se puede usar así:

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

   como el char[]es un paramsparámetro.

2. Puede agregar fácilmente su propio método de extensión aquí para lograr lo que desea:

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

   y ahora testString.Split("anotherString");funcionará para ti.

Los diferentes idiomas tienen reglas algo diferentes para las conversiones implícitas y la sobrecarga, y .NET Framework está diseñado para ser utilizable con cualquiera de ellos. En el Option Strict Offdialecto de VB.NET, Stringse puede pasar un valor de tipo a una función que espera un Char[]comportamiento equivalente al de llamar ToCharArray()a la cadena.

Creo que lo más sensato hubiera sido tener nombres separados para Split(que acepta un solo Charo String) y SplitMulti(que aceptaría un Char[]o String[]), pero .NET a veces parece favorecer el uso de sobrecarga solo para elegir diferentes tipos de operaciones. Desafortunadamente, no conozco ninguna forma de usar String.Splitpara acomodar cualquier escenario de uso que requiera distinguir diferentes tipos de delimitadores que no sea dividir por separado en cada uno.

Otra omisión es una opción para preservar los delimitadores, ya sea incluyéndolos al final de la cadena anterior, o al comienzo de la siguiente cadena, o haciendo que los elementos de matriz impares sean delimitadores, mientras que los elementos pares son las cosas entre ellos.