¿Tiene mal olor el tener clases vacías en el medio de una jerarquía de clases?

A veces termino con una jerarquía de clases donde tengo una clase base abstracta con algunas funcionalidades comunes y un par de clases de implementación que se dividen en dos (raramente más) grupos que deseo tratar de manera diferente en algunos casos. Un ejemplo sería una clase abstracta de nodo de árbol y diferentes implementaciones de rama y hoja donde quiero distinguir ramas y hojas en algún punto.¿Tiene mal olor el tener clases vacías en el medio de una jerarquía de clases?

Estas clases intermedias solo se utilizan para las sentencias "is-a" en el control de flujo y no contienen ningún código, aunque he tenido casos en los que "crecieron" algunos códigos más adelante.

¿Te parece mal? En mi ejemplo de árbol, una alternativa sería agregar isLeaf()/isBranch() métodos abstractos a la clase base e implementarlos en las clases intermedias, pero eso no parecía ser mejor para mí, en realidad, a menos que quisiera tener clases que podrían ser múltiples cosas a la vez.

Fuente

2009-09-28 Hanno Fietz

+1 agradable exponerse usted mismo :-) – KLE

@KLE :-) Bueno, gracias por ser mi público.He estado trabajando para mí casi toda mi carrera y a veces puede ser difícil obtener una opinión externa. –

@Hanno Bueno, lo estás haciendo bien, no te preocupes. Solo continúa. ¡Estoy realmente impresionado con tus 158 preguntas! ;-) – KLE

En general, las clases vacías son un olor código.

Acepto que sus métodos isLeaf o isBranch son una alternativa correcta. Ellos agregan información sobre los objetos, que es útil. (Esto se debe a que, en la superclase, no se puede expresar que las subclases son "de hoja o rama").

Los dos métodos con resultados opuestos también podría considerarse como la duplicación de código.

Puede usar solo una ... Pero yo recomendaría devolver un valor numerado HOJA o RAMA.

Fuente

2009-09-28 09:33:52 KLE

Sí, las jerarquías de herencia profunda son un olor de código de todos modos.

Fuente

2009-09-28 09:31:44 parkr

Una clase que no contiene ningún código es definitivamente un código de olor ....

Fuente

2009-09-28 09:33:43 Quagmire

Para mí, utilizar las pruebas "is-a" en el control de flujo es tan desagradable como usar el interruptor/caja. En un buen diseño OO, ninguno es necesario.

Fuente

2009-09-28 09:34:14 Ber

Estoy de acuerdo, este es el problema más crítico. –

+1 Acepto. Aunque este tipo de diseño no OO podría usarse temporalmente antes de refactorizar, o también podría usarse si una clase diferente debe tener un aspecto (separación de responsabilidades). ** Encontrar el equilibrio exacto de las jerarquías de clases es un proceso difícil y evolutivo ** por lo general. – KLE

Estoy de acuerdo 100 por ciento. No puedo decirte cuántos argumentos he tenido respecto a que las declaraciones switch no son buenas OO. –

Sí, definitivamente un olor a código: no codifique estas clases vacías a menos que esté listo para escribir ese código en él. Piensa en YAGNI (no vas a necesitarlo), no lo hagas a menos que ya lo necesites.

Además, ¿ha considerado casos en los que estas clases solo están disponibles para proporcionar métodos abstractos o para agruparlos según las capacidades en términos de métodos o propiedades?

Si ese es el caso, tal vez lo que realmente necesita son interfaces, ¿no clases abstractas adicionales?

Fuente

2009-09-28 09:34:58

Gracias por las sugerencias adicionales. Sin embargo, en los casos de los que estoy hablando, las interfaces no me ayudarían. –

Me parece bien, si va a poner nuevas funcionalidades en el futuro.

Pero si no, generalmente se usa una enumeración aquí.

- Editar

Aunque estoy de acuerdo con Ber, que no se debe generalmente a utilizar 'is-a' de todos modos.

Fuente

2009-09-28 09:35:30

¿Tiene mal olor el tener clases vacías en el medio de una jerarquía de clases?

Respuesta

Cuestiones relacionadas