design - sirve - sistemas de informacion orientado a objetos

¿Cuáles son los signos reveladores del diseño orientado a objetos malos?

Question

Al diseñar un nuevo sistema o al conocer el código de otra persona, ¿cuáles son algunas señales reveladoras de que algo ha fallado en la fase de diseño? ¿Hay pistas para buscar en los diagramas de clase y las jerarquías de herencia o incluso en el propio código que solo pide una revisión de diseño, especialmente al principio de un proyecto?

Answer 1

Aquí hay algunos:

• Dependencias circulares
• Usted con la propiedad XYZ de una clase base no estaba protegido / privado
• Desea que su idioma sea compatible con herencia múltiple

Answer 2

Código duplicado = Código que hace lo mismo ... Creo que, en mi experiencia, este es el mayor error que puede ocurrir en el diseño de OO.

Answer 3

Cuando no solo tiene una clase Money / Amount, sino una clase TrainerPrice, clase TablePrice, clase AddTablePriceAction, etc.

IDE Driven Development o Auto-Complete development. Combinado con extrema tipificación estricta es una tormenta perfecta.

Aquí es donde puede ver lo que podría ser una gran cantidad de lo que podrían ser los valores variables convertirse en nombres de clases y nombres de métodos, así como el uso gratuito de las clases en general. También verá cosas como que todas las primitivas se conviertan en objetos. Todos los literales como clases. Parámetros de función como clases. Luego, los métodos de conversión en todas partes. También verá cosas como una clase que envuelve a otra que entrega un subconjunto de métodos a otra clase, incluidas solo las que necesita actualmente.

Esto crea la posibilidad de generar una cantidad casi infinita de código que es excelente si tiene horas facturables. Cuando las variables, contextos, propiedades y estados se desenvuelven en clases hiper explícitas y demasiado específicas, esto crea un cataclismo exponencial ya que tarde o temprano esas cosas se multiplican. Piense en ello como [a, b] x [x, y]. Esto se puede complicar aún más con un intento de crear una interfaz completa y fluida, así como cumplir con tantos patrones de diseño como sea posible.

Los lenguajes de programación orientada a objetos no son tan polimórficos como algunos idiomas de escritura libre. Los lenguajes sueltos a menudo ofrecen polimorfismo de tiempo de ejecución en sintaxis superficial que el análisis estático no puede manejar.

En OOP, es posible que vea formas de repetición difíciles de detectar automáticamente que podrían convertirse en códigos más dinámicos utilizando mapas. Aunque estos idiomas son menos dinámicos, puede lograr características dinámicas con algo de trabajo extra.

El comercio de aquí es que usted ahorra miles (o millones) de líneas de código mientras potencialmente pierde funciones IDE y análisis estático. El rendimiento puede ir en cualquier dirección. El polimorfismo de tiempo de ejecución a menudo se puede convertir a código generado. Sin embargo, en algunos casos, el espacio es tan grande que es imposible cualquier otra cosa que no sea el polimorfismo en tiempo de ejecución.

Los problemas son mucho más comunes con los lenguajes OOP que carecen de genéricos y cuando los programadores OOP intentan escribir estrictamente el lenguaje dinámico de tipeo flojo.

Lo que sucede sin genéricos es donde deberías tener A para X = [Q, W, E] e Y = [R, T, Y] en lugar de eso ves [AQR, AQT, AQY, AWR, AWT, AWY, AER, AET, AEY]. Esto a menudo se debe al miedo o al uso de tipos o al pasar el tipo como una variable para perder compatibilidad con IDE.

Tradicionalmente, los lenguajes de tipeo flexible se hacen con un editor de texto en lugar de un IDE y la ventaja perdida a través del soporte de IDE a menudo se obtiene de otras maneras, como organizar y estructurar el código de manera que sea navegable.

A menudo, los IDE se pueden configurar para comprender su código dinámico (y vincularlo), pero pocos lo soportan adecuadamente.

Sugerencia: El contexto aquí es OOP ido horriblemente mal en PHP donde las personas que usan programación OOP Java simple tradicionalmente han intentado aplicar eso a PHP, que incluso con un poco de soporte OOP es un tipo de lenguaje fundamentalmente diferente.

Diseñar en contra de su plataforma para tratar de convertirlo en uno acostumbrado, diseñando para abastecer un IDE u otras herramientas, diseñando para adaptarse a Pruebas unitarias de soporte, etc. deben sonar todas las alarmas porque es una desviación significativa de diseñar software de trabajo para resolver una categoría dada de problemas o un conjunto de características determinado.

Answer 4

Dentro de un método largo, secciones rodeadas de #region / #endregion: en casi todos los casos que he visto, ese código se podía extraer fácilmente en un nuevo método O se necesitaba refactorizar de alguna manera.

Árboles de herencia excesivamente complicados, donde las subclases hacen cosas muy diferentes y solo se relacionan tangencialmente entre sí.

Violación de DRY - subclases que anulan un método base casi de la misma manera, con solo una pequeña variación. Un ejemplo: recientemente trabajé en algún código donde las subclases anulaban un método base y donde la única diferencia era una prueba de tipo ("x es ThisType" frente a "x es ThatType"). Implementé un método en la base que tomó un tipo genérico T, que luego utilizó en la prueba. Cada niño podría llamar a la implementación base, pasando el tipo que quería probar. Esto recortó aproximadamente 30 líneas de código de cada una de las 8 clases de niños diferentes.

Answer 5

En mi opinión, todo el código OOP degenera en código de procedimiento durante un lapso de tiempo suficientemente largo.

De acuerdo, si lees mi pregunta más reciente, quizás entiendas por qué estoy un poco hastiado.

El problema clave con OOP es que no hace obvio que el gráfico de construcción de objetos debe ser independiente de su gráfico de llamadas.

Una vez que solucionas ese problema, OOP comienza a tener sentido. El problema es que muy pocos equipos conocen este patrón de diseño.

Answer 6

Encuentre un programador que tenga experiencia con la base de código. Pídales que expliquen cómo funciona algo.

Si dicen "esta función llama a esa función", su código es de procedimiento.

Si dicen "esta clase interactúa con esa clase", su código es OO.

Answer 7

Esta pregunta hace la suposición de que orientado a objetos significa un buen diseño. Hay casos en que otro enfoque es mucho más apropiado.

Answer 8

Imposible probar la unidad correctamente.

Answer 9

Las cosas que sobresalen más para mí son " olores de código ".

En general, soy sensible a cosas que van en contra de las "buenas prácticas".

Cosas como:

• Métodos que hacen cosas distintas de lo que se podría pensar a partir del nombre (p. Ej .: FileExists () que elimina silenciosamente archivos de bytes cero)

• Algunos métodos extremadamente largos (signo de un contenedor de objetos alrededor de un procedimiento)

• Uso repetido de instrucciones de cambio / caso en el mismo miembro enumerado (signo de subclases que necesitan extracción)

• Muchas variables miembro que se usan para procesar, no para capturar el estado (puede indicar la necesidad de extraer un objeto de método)

• Una clase que tiene muchas responsabilidades (violación del principio de Repsonibilidad única)

• Largas cadenas de acceso de los miembros (esto. Está bien, esto. Que el otro está bien, pero mi.mucho.cadena.nivelada.de.acceso.del.memoria es frágil)

• Mala denominación de las clases

• Uso de demasiados patrones de diseño en un espacio pequeño

• Trabajando demasiado duro (reescribiendo funciones ya presentes en el marco, o en otro lugar en el mismo proyecto)

• Mala ortografía (en cualquier lugar) y gramática (en comentarios), o comentarios que son simplemente engañosos

Answer 10

Las siguientes son las características más destacadas de un mal diseño:

1. Rigidez
2. Fragilidad
3. Inmovilidad

Eche un vistazo al Principio de Inversión de Dependencia

Answer 11

Los objetos son buenos crea un montón de ellos es un mal diseño OO.

Answer 12

Mira esto. Es impresionante.

Malos olores: http://c2.com/xp/CodeSmell.html

No es específico de la programación orientada a objetos, pero cubre una gran cantidad de bits. Aclamaciones.

Answer 13

Un olor son los objetos que tienen dependencias / referencias duras a otros objetos que no son parte de su jerarquía natural de objetos o composición relacionada con el dominio.

Ejemplo: Supongamos que tiene una simulación de ciudad. Si el objeto a Persona tiene una propiedad NearestPostOffice, probablemente tenga problemas.

Answer 14

Una cosa que odio ver es una clase base que desciende a una clase derivada. Cuando ves esto, sabes que tienes problemas.

Otros ejemplos pueden ser:

• Uso excesivo de declaraciones de interruptor
• Clases derivadas que anulan todo

Answer 15

Yo diría que la regla número uno del diseño pobre de OO (y sí, he sido culpable muchas veces) es:

• Clases que rompen el Principio de Responsabilidad Individual (SRP ) y realizan demasiadas acciones

Seguido por:

• Demasiada herencia en lugar de composición, es decir, clases que se derivan de un subtipo puramente para que tengan funcionalidad gratuita. Favorecer la composición sobre la herencia .

Answer 16

Anti-patterns

Diseño de software anti-patrones

• Inversión de la abstracción: no se expone la funcionalidad implementada requerida por los usuarios, para que puedan volver a implementarla utilizando funciones de nivel superior
• Punto de vista ambiguo: presentación de un modelo (generalmente OOAD) sin especificar su punto de vista
• Gran bola de barro: un sistema sin estructura reconocible
• Blob: Generalización del objeto de Dios a partir del diseño orientado a objetos
• Fábrica de gas: un diseño innecesariamente complejo
• Kludge de entrada: error al especificar e implementar el manejo de entrada posiblemente no válida
• Hinchamiento de la interfaz: hacer una interfaz tan poderosa que es extremadamente difícil de implementar
• Botón mágico: Codifica la lógica de implementación directamente dentro del código de la interfaz, sin usar la abstracción.
• Riesgo de carrera: no ver la consecuencia de diferentes órdenes de eventos
• Solución ferroviaria: una solución propuesta que, aunque es deficiente, es la única disponible debido a la previsión e inflexibilidad deficientes en otras áreas del diseño
• Reacoplamiento: introducción de dependencia de objetos innecesarios
• Sistema Stovepipe: un conjunto apenas mantenible de componentes mal relacionados
• Esquema Staralised: esquema de base de datos que contiene tablas de doble propósito para uso normalizado y de datamart

Antipatrones de diseño orientado a objetos

• Modelo de dominio anémico: el uso del modelo de dominio sin ninguna lógica comercial que no sea OOP porque cada objeto debe tener atributos y comportamientos
• BaseBean: Heredar funcionalidad de una clase de utilidad en lugar de delegarla
• Call super: requiere subclases para llamar al método reemplazado de una superclase
• Problema círculo-elipse: subtipificación de tipos de variables en función de los subtipos de valores
• Fallo de la subclase vacía: crear una clase que falla la "Prueba de la subclase vacía" al comportarse de forma diferente a una clase derivada de ella sin modificaciones
• Objeto de Dios: Concentrar demasiadas funciones en una sola parte del diseño (clase)
• Pozo de objetos: reutilización de objetos cuyo estado no se ajusta al contrato (posiblemente implícito) para su reutilización
• Objeto orgía: no encapsular adecuadamente los objetos que permiten el acceso irrestricto a sus partes internas
• Poltergeists: objetos cuyo único propósito es pasar información a otro objeto
• Acoplamiento secuencial: una clase que requiere que sus métodos sean llamados en un orden particular
• Singletonitis: el uso excesivo del patrón singleton
• Sin embargo, otra capa inútil: agregar capas innecesarias a un programa, biblioteca o marco. Esto se hizo popular después del primer libro sobre patrones de programación.
• Problema de yo-yo: una estructura (por ejemplo, de herencia) que es difícil de entender debido a una fragmentación excesiva

Answer 17

Al tener todos tus objetos, heredas una clase de utilidad básica para que puedas llamar a tus métodos de utilidad sin tener que escribir tanto código.