Esta pregunta es oportuna para mí: ayer escribí casi exactamente ese código. Simplemente reemplace "Animal" con lo que sea relevante en mi proyecto, aunque me quedo con "Animal" por el bien de la discusión aquí. En lugar de una declaración de 'cambio', tuve una serie algo más compleja de declaraciones 'if', que involucran más que solo comparar una variable con ciertos valores fijos. Pero eso es un detalle. Un método estático de fábrica parecía una forma ingeniosa de diseñar cosas, ya que el diseño surgió de la refactorización de desorden de código rápido y sucio.
Rechacé este diseño debido a que la clase base tenía conocimiento de la clase derivada. Si las clases LandAnimal y SeaAnimal son pequeñas, ordenadas y fáciles, pueden estar en el mismo archivo fuente. Pero tengo grandes métodos complejos para leer archivos de texto que no cumplen con los estándares definidos oficialmente. Quiero que mi clase LandAnimal esté en su propio archivo fuente.
Eso conduce a la dependencia de archivos circulares: LandAnimal se deriva de Animal, pero Animal necesita saber que LandAnimal, SeaAnimal y otras quince clases existen. Saqué el método de fábrica, lo puse en su propio archivo (en mi aplicación principal, no en mi biblioteca de Animales). Tener un método de fábrica estático parecía lindo e inteligente, pero me di cuenta de que en realidad no resolvía ningún problema de diseño.
No tengo idea de cómo se relaciona esto con C # idiomático, ya que cambio mucho los idiomas, generalmente ignoro los modismos y las convenciones propias de los idiomas y las pilas de desarrolladores fuera de mi trabajo habitual. Si algo mi C # puede parecer "pythonic" si eso es significativo. Mi objetivo es la claridad general.
Además, no sé si habría alguna ventaja en el uso del método de fábrica estática en el caso de clases pequeñas y simples que probablemente no se extenderán en el trabajo futuro: tenerlo todo en un archivo de origen podría ser bueno en algunos casos.