xcode class code-smell names

xcode - ¿Nombres de clase malolientes?



class code-smell (22)

En su experiencia, ¿cuáles son algunas palabras clave "olorosas" en los nombres de clases o funciones que podrían ser señales de advertencia de un diseño orientado a objetos malo?

Descubrí que las clases que contienen la palabra Manager o Base menudo son sospechosas. Por ejemplo, un FooManger menudo indica una encapsulación pobre o un diseño singleton que es difícil de reutilizar.

Una clase FooBase es típicamente una clase base abstracta que nunca se espera que se haga referencia directamente en el código de la persona que llama. Solo se usa para compartir alguna implementación de código sin una verdadera relación IS-A . Y el nombre de la clase Base expone los detalles internos de la implementación y no refleja un objeto del "mundo real" en un Modelo de dominio.

Las funciones que incluyen la palabra And o Or (por ejemplo, DoThisAndThat() o DoThisOrThat() ) son malolientes. La función es probablemente la falta de cohesión y está tratando de hacer demasiado. Y el nombre expone detalles de implementación interna.

"* Ayudante" ". Si una clase no puede hacer su trabajo, ¿quién puede?

¿Qué tal un prefijo "cls" o un sufijo de "Clase"? Esos olores

Creo que cualquier cosa que comience con class foo probablemente sea ilegible.

Sí, quiero decir eso literalmente. Tiendo a usar en exceso "foo" ...

DoThisAndThat () o DoThisOrThat () infringen inherentemente el principio de responsabilidad única. Un método debe hacer una cosa y una sola cosa (incluso si esa cosa es llamar a un montón de otros métodos)

El "olor" más común que he encontrado es la confusión de los conceptos de número. No desea una clase llamada Contacts si una instancia hace referencia a un "contacto". Usted lo llama Contact lugar.

El peor nombre de función que he encontrado en la vida real:

DoTheLogic();

He encontrado que esto es útil:

"Las clases y objetos deben tener nombres de frases nominales o nominales como Customer , WikiPage , Account y AddressParser . Evite palabras como Manager , Processor , Data o Info en el nombre de una clase. Un nombre de clase no debe ser un verbo".

(De Clean Code por Robert Martin, p25)

La palabra "Stuff" en cualquier tipo de nombre de clase / función va a ser un signo muy malo (siempre que no sea la forma del verbo). DoStuff (), ValidateStuff (), FetchStuffFromDatabase (), elige tu veneno.

Las clases de Util pueden ser bastante útiles, pero si el nombre es simple "Util" o "Utils" es bastante indescriptible.

Las palabras "Datos", "Información", "Estructura", "Grabar", etc. en un nombre de clase significan que alguien no ha estado pensando. Ohhhhh, ¡esa es la clase con los DATOS! ¿Entonces todas estas otras clases, no tienen ninguna? ...

(Sí, lo sé, interfaces. Pero incluso entonces, nombrar la implementación de una interfaz "InterfaceData" sería bastante tenue).

Los nombres de las clases son en gran parte arbitrarios, por lo tanto, elija lo que funciona para usted y los consumidores de su código. Pero algunos tipos de nombres de clase pueden ser indicativos de un problema mayor.

Para ilustrar un punto:

ClassName LongClassName VeryLongClassName VeryLongClassNameThatIsIndicativeOfExcessiveUseOfInheritance VeryLongClassNameThatIsNotIndicativeOfExcessiveUseOfInheritance SomewhatLongClassName ShortClassName ShortNameOfVeryLargeClass ShortClassNameThatAlsoHasTheWordShortInTheName

No te preocupes tanto por los nombres. Preocuparse por el diseño. Donde trabajo, rutinariamente hablamos de clases con nombres como F , P , V y $ , y no es un problema para nadie.

No estoy de acuerdo con "Manager", y al parecer tampoco Microsoft (¡no es que siempre tengan la razón!) Considere la clase ConfigurationManager. Es un uso legítimo de "Administrador" porque esta clase administra los archivos app.config / web.config. "ConfigurationReaderWriter" sería bizzare, y tener dos clases (ConfigurationReader y ConfigurationWriter) no tendría mucho sentido.

No estoy de acuerdo contigo en el punto Base . Por ejemplo, en ASP.NET (tanto WebForms como MVC) no es nada infrecuente con las clases base para muchas cosas diferentes: el uso más común que he visto es para los métodos que desea ejecutar cada vez que una página es cargado, o cada vez que se carga un grupo específico de páginas. A continuación, crea una clase PageBase que hereda de System.Web.UI.Page , que contiene el método que desea copiar, y hace que todas las páginas que desee ejecutar este método hereden su PageBase lugar del System.Web.UI.Page predeterminado. . Este no es necesariamente un diseño deficiente, es una de las muchas herramientas para tratar de seguir el principio DRY ("No repetir").

Nombres de clase que no son indicativos de lo que hacen. Hay muchas cosas simplemente llamadas ''Manager'' o ''Interface'' escondidas dentro de las bibliotecas en las que he trabajado en el pasado. Nunca se supone que debes llamarlos directamente ya que son estructuras internas para administrar sus funciones.

No está claro a qué ''interfaz'' se conecta; ¿es una interfaz de programación, se conecta a la red o al hardware? Para averiguarlo, tiene que ir y leer el código / documentos para la clase de interfaz.

Por supuesto, cuando digo ''interfaz'', me refiero a cualquier nombre de una sola palabra razonablemente vaga.

Para citar el código de Roedy Green''s How To Write Unmaintainable :

Sé abstracto

Al nombrar funciones y variables, haga un uso intensivo de palabras abstractas como, todo, datos, manejar, cosas, hacer, rutina, realizar y los dígitos, por ejemplo, rutina X48, PerformDataFunction, DoIt, HandleStuff y doargs_method.

Semifallo.

Si una clase no puede tener un nombre más específico que FooManager , entonces es posible que trate de hacer demasiadas cosas diferentes con Foo .

Nombrar todo depende del contexto en la aplicación en la que se utiliza. No existen reglas estrictas.

Si estás entrando en un proyecto que ya está en funcionamiento y están usando verbos para nombres de clase en todas partes, ¿por qué confundirías a los programadores y tomaría un enfoque de nombramiento diferente?

Piensa en el panorama general.

He visto interfaces llamadas InterfaceNameImpl . ¿Qué puede ser peor?

Mi mayor motivo de preocupación es uno con el que me he encontrado mucho en un gran proyecto de la vida real: Helper . A veces se trata de un conjunto de métodos de utilidad estáticos, a veces es un objeto de estrategia, por lo general es solo una burbuja de código sin un lugar bien considerado en el diseño.

Además, la Strategy es una mala señal, muy similar a Singleton como notó MSN. ¡Felicitaciones! ¡Estás usando un patrón de diseño!

Nunca me gustó Util para las clases de utilidad, pero eso es más una cuestión de gusto. (Prefiero el sustantivo pluralizado, como Arrays o Collections del JDK, para un conjunto de métodos estáticos relacionados con un tipo de objeto).

Funcionalidad de inicio de sesión orientada

Un gerente está a cargo de muchas entidades directamente relacionadas. El gerente es responsable de cómo esas entidades interactúan con un cliente. Algunas clases de administrador no tienen nombres bien definidos como matriz, pila y cola.