Lo haré simple. Tengo un stringwriter como miembro de la clase, por lo tanto, no puedo usar using(). Quiero un sw vacío cada vez que llamo a cierta función. ¿Debo llamar a Dispose() en el sw y asignar un nuevo objeto? o debería hacer algo como .close() y hacer algo más para vaciar el búfer?¿Debo disponer de un stringwriter? o reutilizar de alguna manera?
Si tiene una determinada función que necesita un StringWriter vacío cada vez, ¿por qué no simplemente crear un nuevo StringWriter en esa función?
Pero, volviendo a su pregunta original, utilicé .NET Reflector para ver qué hace StringWriter's Dispose. Todo lo que hace es volver a llamar a la clase base '(TextWriter) Dispose - que no hace nada.
Así que si realmente necesita "reutilizar" el StringWriter que está exponiendo, parece que sería seguro volver a crear una nueva instancia cuando lo necesite (aunque creo que debería reconsiderar su diseño de exponer un StringWriter como miembro público en una clase).
Estoy de acuerdo con el otro respondedor, que debe ver su diseño para ver si tener el escritor de cadenas de nivel de clase es realmente el camino a seguir.
Sin embargo, no estoy de acuerdo con el punto sobre
"Todo lo que hace es llamar de nuevo en la clase base (TextWriter) Desechar - que no hace nada."
Al consumir clases, si se implementa un tipo Dispose, que realmente debería llamarlo, ya sea explícita o con un "uso".
En este caso, es cierto que StringWriter.Dispose llama a TextWriter.Dispose que no hace nada, pero realmente no aconsejaría "simplemente ignorándolo".
El punto principal de la herencia y el polimorfismo es que este tipo se puede intercambiar por un tipo derivado.
StringWriter de hoy en su código, puede ser cambiado para mañana EvenBetterStringWriter que puede tener una implementación más significativa para Dispose.
Si implementa Dispose, y lo usa, debe pensar seriamente en llamar a deshacerse cuando haya terminado.
Tener un conocimiento privilegiado de las partes internas de esta implementación concreta concreta es peligroso cuando permite que guíe su diseño de esta manera. El autor de la clase StringWriter está claramente destinado a que se llame a Dispose, o no estaría allí.
+1. ¿Entonces sugieres que debería llamar a dispose y crear un nuevo stringwriter cada vez? ¿No hay forma de vaciar una existente? (o tal vez no hay un beneficio) –
El problema con el enfoque de reutilización es que tienes otros problemas que considerar: si escribes una cadena de 1MB y luego la reutilizas para un 2KB, ¿los otros 1022 KB se sientan? allí, no liberado, ¿o es elegible para la recolección de basura? Esto es sólo un ejemplo. En general, probablemente iría por la ruta de crearlo todo el tiempo, y solo me preocuparía si había un problema de rendimiento particular al hacer esto. –
"El autor de la clase StringWriter claramente significaba que se debía llamar a Dispose, o no estaría allí". - bueno no. Dispose está ahí porque StringWriter deriva del TextWriter más general. – mrec
partir de O'Reilly C# en pocas palabras:
Hay, sin embargo, tres escenarios para no disponiendo:
- ...
- ...
- Cuando método Dispose de un objeto es innecesaria por diseño, y la eliminación de ese objeto añadiría complejidad a su programa
La tercera categoría incluye las siguientes clases: WebClient, StringReader, Cadena escritor y BackgroundWorker (en System.ComponentModel). Estos tipos son desechables bajo la coacción de su clase base en lugar de a través de una genuina necesidad de realizar la limpieza esencial de . Si instancias y trabajas con un objeto como este en un solo método, envolverlo en un bloque de uso agrega poco inconveniente. Pero si el objeto es más duradero, mantener la pista de cuando ya no se usa para que pueda deshacerse de ella agrega complejidad innecesaria . En tales casos, simplemente puede ignorar la eliminación del objeto .
tl; dr: no, no necesita deshacerse de él.
Nunca dije que fuera público;). Es necesario para una devolución de llamada y no puedo pasar un stringwrite por lo que es un miembro. –