Perderse en la OOP joungle cuando intenta poner un método en el lugar correcto, etc.

Question

No es que no entiendo el concepto de OOP, y qué se debe hacer cuando, pero a veces me pierdo mentalmente en eso.

¿Qué mejor que un ejemplo? Así que necesitaba descargar un archivo en una ruta temporal, decidí obtener la ruta temporal no por los métodos normales de dot net, debido a una razón irrelevante. Así que escribí mi propio método para este string GetTempFileSafe(string extension, out FileStream), lindo, ¿no? Pero, oye, espera un momento, este no es el lugar correcto para este método ... Este método podría usarse para otras cosas. Tiene que ser un método público estático en alguna parte. ¿pero donde? Bueno, supongo que tendré que abrir una nueva clase estática para eso. Espero agregarle más métodos algún otro día.

Así que definí public static class FileStreamUtils \\one hell of a name huh? y le agregué mi método. Pero espera ... ¿Dónde debería estar esta clase? Básicamente puedo usarlo desde cualquier proyecto ... no tiene nada que ver con este específico. Así que abrí una nueva biblioteca a la que llamé al MyUtils.

Agregué mi clase estática con mi único método estático, construí la biblioteca, agregué el dll como referencia a mi proyecto original ... y eso. (preste atención el método es más difícil de depurar, porque estoy usando el dll en lugar del código original)

Ahora no me malinterprete. Literalmente me encantan los conceptos y el orden de OOP, pero a veces me agota mentalmente ... tal vez porque trabajo solo.

¿Qué opinas? ¿Estoy llorando por nada, y cosas como abrir una biblioteca de utilidades se hacen más de una vez, y solo necesito cambiar mi actitud? ¿O crees que a veces es mejor no mantener tanto la pulcritud (en mi caso, por ejemplo, solo vivo el método allí, y en caso de que lo necesite de nuevo, lo muevo para uso público)?

Muchas gracias. Y por favor, si de alguna manera logras encontrar una razón para votar por mí, no hay problema, pero solo por favor deja un comentario, así podré no repetir mis errores aquí.

Answer 1

Siempre me sorprende cómo Robert Glass 'Rules of Three se encuentran en estas situaciones. No se preocupe por la reutilización hasta que tenga tres lugares donde su función pueda caber. Siempre me gusta escribir la función la primera vez que la necesito. Tenga en cuenta que lo estoy duplicando la segunda vez. Y la tercera vez haga el trabajo para volver a utilizarla (refactorizarla en una biblioteca de utilidades).

Answer 2

Para ser sincero, lo que ha hecho no es incorrecto. Sin embargo, lo que ha hecho y lo que veo es que la gente se da cuenta de cómo se deben hacer las cosas, lo que hace que se concentre en el trabajo, creando una buena pieza de software que desempeña alguna función interesante.

En su caso particular, no necesitaba una biblioteca de clases, ya que solo hay una función, así que simplemente la incluiría en una clase de Ayuda. Sin embargo, si planea agregar muchas funciones útiles, una biblioteca de clases es una buena manera de usar el código una y otra vez. Pero no agregue demasiadas capas a una aplicación que no lo necesite.

Answer 3

Mi regla general es que cada vez que escribo un método estático con al menos un parámetro, es un olor a código.

En OO, las operaciones deben vincularse a los objetos, por lo que en lugar de manipular uno o más objetos de una biblioteca auxiliar, es mejor mover el método a uno de los objetos.

Sé que es imposible si está trabajando con los tipos incorporados del BCL, pero el olor debería hacer que empiece a pensar en alternativas.

Veamos su ejemplo: No se puede agregar la caja fuerte GetTempFile a System.String ni FileStream, pero ¿alguno de los parámetros representa un concepto oculto que se modelaría mejor como un objeto?

Aunque no sé si es verdad en su ejemplo, pero la 'extensión' suena como un concepto para mí, ¿por qué no definir una clase de extensión de esta manera:

public class Extension 
{ 
    private readonly string extension; 

    public Extension(string extension) 
    { 
     // Guard Clauses go here 
     this.extention = extension; 
    } 

    public string GetTempFileSafe(out FileStream) 
    { 
     // implementation goes here, using this.extension... 
    } 
} 

Como paso siguiente, a continuación, puede cambiar esta API para deshacerse del parámetro out encapsulando la cadena resultante y el FileStream en un nuevo objeto.

Answer 4

parecer que estamos hablando de C#, que no sé, soy sobre todo una persona de Java en estos días, así que tal vez hay una diferencia técnica, pero ...

En Java se puede dividir en sus clases "paquetes". Puede compilar varios paquetes al mismo tiempo, mantenerlos juntos en un IDE, etc., pero también es fácil separarlos.

Cuando escribo un grupo de clases que creo que probablemente quiera volver a utilizar, las pongo en un paquete aparte. Todavía los conservo como parte del mismo proyecto a menos y hasta que realmente quiera usarlos en otro lugar. Si eso sucede, está bien, copié el paquete en su propio proyecto y construí una biblioteca a partir de él.

Por lo tanto, durante el desarrollo, sigue siendo parte del mismo proyecto, aún en el mismo espacio de trabajo, etc., por lo que es fácil de depurar y, en general, hacer un seguimiento de.

Si nunca lo uso en otro lugar, no lo dañen.

Si lo uso en otro lugar, a veces soy flojo y simplemente copio el paquete al nuevo proyecto. Occassionally Realmente lo hago una biblioteca independiente. (Y cuando digo "de vez en cuando", creo que en la vida real quiero decir que lo he hecho dos veces en los últimos diez años)

Como digo, no sé cómo C# agrupa las cosas, si hay un manera fácil de dividir un conjunto de clases en alguna "unidad" conveniente.

Answer 5

Añadiendo cosas en Jason's answer:

también, por eso reuniones diarias, la programación en parejas, revisión de código son para. En estas reuniones informales, usted dice lo que ha hecho (creó un archivo temporal) para el equipo, de modo que si alguien ya lo ha hecho, o si también lo necesitan, sabe que tiene que refactorizarse en una biblioteca de servicios públicos. De lo contrario, simplemente deja el método allí.

Sé que mencionaste que trabajas solo, pero la comunicación es clave para evitar la duplicación de código y muchos de esos code smells, por lo que este consejo es principalmente para equipos, no para programadores independientes.

Answer 6

La refabricación es buena. Si bien es posible que no desee comenzar leyendo this thesis about refactoring, es una buena lectura y lo pone todo en perspectiva. También es posible que desee comprobar las respuestas al https://stackoverflow.com/questions/441896/how-to-be-master-in-c-and-object-oriented-technology que tienen un libro sobre refactorización.

La conclusión es que no tiene que poner todo el código en el lugar correcto y organizarlo de la manera correcta. Haga algo que sea lo suficientemente bueno por ahora, anótelo en una lista de refactorización posible, y cuando tenga algo de tiempo, revise la lista y eche un vistazo al código. Tal vez lo suficientemente bueno, es lo suficientemente bueno. Si no, ayuda al código a EVOLVER en algo mejor.