División de objetos en sus partes más fundamentales

No estoy seguro de si el título capta lo que trato de decir aquí.División de objetos en sus partes más fundamentales

Al diseñar en OO debería dividir mis objetos en sus áreas más específicas, así que si tengo un objeto de fábrica que trata sobre la creación de objetos, más adelante encuentro una forma de crear objetos para otro propósito aunque pueden ser los mismos objetos, vale la pena crear un fcatorio separado o simplemente agregar al existente.

Mi mayor preocupación es aumentar las clases con toneladas de cosas, o dividir objetos y diluir mis proyectos en un mar de clases.

¿Algún ayuda?

EDIT:

supongo que en un/sub parte tópico nota al margen de mí quiere averiguar el nivel de granularidad que puedes usar en un programa. En cierto modo, ¿qué tan bajo deberías ir?

Fuente

2010-10-29 Julio

+1 para la pregunta interesante – posdef

su pregunta no está realmente enfocada. ¿En qué clases estás pensando crear? – hvgotcodes

solo en general ... pero si quieres clases de detalles mayores que sigan patrones de creación, en lugar de clases que son principalmente para almacenar datos con métodos no GRANDES – Julio

Mi mayor preocupación es adquirir más volumen clases con un montón de cosas, o objetos de división y diluyendo mis proyectos en un mar de clases

Este es un punto muy válido y, en todo, incluso de tamaño razonable proyecto, extremadamente difícil de conseguir desde el principio, especialmente porque, en realidad, los requisitos evolucionan con el tiempo en la mayoría de los casos. Aquí es donde entra en juego la "refactorización". Diseñas según lo que sabes en un momento determinado y no intentas dar demasiados pasos hacia la fe en cuanto a lo que crees que el sistema PUEDE evolucionar.

Dado que usted ya sabe lo que está construyendo en este momento, diseña sus clases tratando de hacer el mejor uso posible de los conceptos OO, por ejemplo, encapsulación/polimorfismo. Esto es en sí mismo, como otros han notado también, puede ser notoriamente difícil de lograr y es allí donde la experiencia, tanto en el diseño de sistemas OO como en el conocimiento del dominio, puede ser realmente útil.

Diseño basado en lo que sabe -> construirlo -> revisarlo -> refactorearlo -> Re-diseño -> y sigue y sigue ..

Fuente

2010-10-29 15:20:11 InSane

Me encanta esta respuesta. ¡Pocos SÍ! momentos leyéndolo Siempre trato de pensar que esto es una fortaleza pero también una debilidad. Siempre estoy pensando, pero ¿y si ... pero no soy vidente, solo puedo trabajar con lo que tengo/sé. Gracias por esto, merece más que mi voto exclusivo. – Julio

+1 Upvoted también para usted. Solo lea estos mismos sentimientos en un libro de Diseño Dirigido por Dominio el otro día. – wllmsaccnt

¿Qué libro era? – Julio

Encontrar el nivel correcto de detalle y responsabilidad es lo que hace que el diseño OOP sea tan difícil. Podemos ayudarlo con un caso específico pero no con algo tan general. Si hubiera algoritmos o metodologías estrictas sobre cómo resolver esto, todos podrían ser diseñadores de OOP.

Fuente

2010-10-29 15:07:40

, esta respuesta es una especie de lo que estaba buscando ... me hace sentir mejor sobre lo que estoy haciendo Es bueno saber que no me falta algo y sí, es difícil. – Julio

Realmente es solo experiencia. Cuando haces algo que más tarde decides que es demasiado complejo/no se puede mantener/que tiene un "olor a código" malo, tómate un momento para reflexionar sobre por qué eso es así y qué causó que sea así. – Flexo

Pero, de nuevo, OOP no es diferente de otras disciplinas de ingeniería; después de todo, los diseñadores de puentes deben decidir el nivel correcto de abstracción. Y, con mucho, tienen mucho más éxito en la definición de requisitos y especificaciones que la mayoría de los ingenieros de software. Este podría ser un punto digno de mención e investigar. – Schedler

Una regla práctica Me gusta decidir "¿esto se está haciendo demasiado grande ahora?" es "¿puedo explicar el propósito de forma concisa?" Si comienza a tener que introducir advertencias y muchas palabras de comadreja para explicar las funciones de un componente de su diseño (ya sea clase, variable de miembro, método o lo que sea), podría ser un buen indicador de que se está volviendo demasiado complejo y debería dividirse .

Fuente

2010-10-29 15:09:11 Flexo

¡Como un bono adicional, te da la primera oración de javadoc o cualquier sistema de documentación que estés usando gratis! – Flexo

En su caso específico, si ya tiene un objeto de fábrica, entonces el principio DRY (No repita) diría que es una mala idea crear otra fábrica que haga lo mismo.

¿Es este un problema real al que se enfrenta? ¿O simplemente un temor sobre cómo podría crecer tu código en el futuro?

Fuente

2010-10-29 15:12:50 Anon

Pude haber escrito las cosas mal en la Q. Creo que no me repetiría que es más un caso de dónde poner el código, podría agregarse a una fábrica existente que crea objetos de diseño para exportar datos a hojas de cálculo de Excel. Por otro lado, pude ver que también podría tener su propia fábrica para importar datos de Excel. Ambas fábricas producirían los mismos objetos pero el funcionamiento interno es completamente diferente. – Julio

@Franco: a partir de su comentario, parece que los objetos que esas fábricas crean son el problema real. Si aún no lo hace, le recomiendo crear un conjunto de interfaces "estrechas" que describan la funcionalidad que desea. Desde una perspectiva de implementación, puede hacer que el mismo objeto implemente múltiples interfaces (aunque rara vez se necesita). – Anon

¿Sería una buena idea teniendo en cuenta que esta fábrica probablemente sea la única fábrica de este tipo y ningún otro objeto alguna vez utilizará las interfaces? – Julio

Si está utilizando el mismo tipo de objeto para resolver problemas drásticamente diferentes, puede que necesite rediseñar la clase para centrarse en la separación de las preocupaciones. Si necesita una respuesta más específica, deberá proporcionar un ejemplo del tipo de clase que necesitaría esta funcionalidad.

cosas que podría haber redactado mal en el P. Supongo que no sería repitiendo mí es sólo más de un caso de donde poner el código, podría ser añade a una exsiting fábrica que crea objetos de diseño para exportar datos de a hojas de cálculo de Excel. En el por otra parte, pude ver que también podría tener tener su propia fábrica para importar excel de datos. Ambas fábricas producirían los mismos objetos pero las operaciones internas son completamente diferentes. -

Si no está haciendo o planea hacer abstracción de clase (subclases o uso de interfaces), puede que no necesite utilizar el patrón de fábrica. El patrón de fábrica generalmente es el más adecuado para el suministro de objetos de un tipo de clase base o que implementan una interfaz específica.

Fuente

2010-10-29 15:13:14 wllmsaccnt

Tanto las fábricas producirían los mismos objetos pero el funcionamiento interno es completamente diferente.

No estoy seguro de haber entendido bien, pero esto suena como un candidato para el patrón AbstractFactory.

Fuente

2010-10-29 15:28:41 Qwerky

Al leer los otros comentarios de Franco, creo que quiere decir que el funcionamiento interno de los objetos después de su creación es completamente diferente ... no solo el funcionamiento interno de ambas fábricas. – wllmsaccnt

Sí, está bien. Siempre que los objetos compartan una interfaz común, de eso se trata la fábrica abstracta. – Qwerky

División de objetos en sus partes más fundamentales

Respuesta

Cuestiones relacionadas