¿Cómo diseñas proyectos orientados a objetos? [cerrado]

No tengo suficiente reputación para hacer comentarios todavía (se unió hoy) o simplemente comentaría la respuesta de Scott Davies. Añadiendo a lo que tenía que decir:

1. Asegúrese absolutamente de saber de qué se trata su programa antes de comenzar. ¿Cuál es su programa? ¿Qué no hará ? ¿Qué problema está tratando de resolver?

2. Su primer conjunto de casos de uso no debe ser una lista de todo lo que el programa eventualmente hará. Comience con el el conjunto más pequeño de casos de uso que puede idear que aún captura la esencia de lo que su programa es para. Para este sitio web, por ejemplo, los casos de uso principales podrían ser iniciar sesión, haga una pregunta, responder a una pregunta, y ver preguntas y respuestas. Nada sobre la reputación, la votación o el wiki de la comunidad, solo la esencia cruda de lo que estás buscando.

3. A medida que se te ocurren clases potenciales, no pienses en ellas solo en términos de qué sustantivo representan, pero qué responsabilidades tienen. He encontrado que esto es la mayor ayuda para averiguar cómo las clases se relacionan entre sí durante la ejecución del programa. Es fácil crear relaciones como "un perro es un animal" o " un cachorro tiene una madre."Por lo general, es más difícil encontrar relaciones que describan las interacciones en tiempo de ejecución entre objetos. Los algoritmos de su programa son al menos tan importantes como sus objetos, y son mucho más fáciles de diseñar si ha explicado lo que cada uno el trabajo de la clase es.

4. Una vez que tenga ese conjunto mínimo de casos de uso y objetos, comience a codificar. Consigue algo que realmente funcione tan pronto como sea posible, aunque no haga mucho y probablemente se vea como una mierda. Es un punto de partida, y te obligará a responder preguntas que podrías pasar por alto en el papel.

5. Ahora regresa y elige más casos de uso, escribe cómo funcionarán, modifica tu modelo de clase y escribe más código. Al igual que su primer corte, asumir como poco en un tiempo como puedas mientras añades algo significativo. Enjuague y repita.

Cuando tuve la oportunidad, normalmente uso lo que llamo la "regla de las tres iteraciones".

En la primera iteración (o inicio), ideo el diseño general de la aplicación de acuerdo con los objetos del modelo, los algoritmos y las direcciones futuras esperadas (realmente esperadas, no tal vez esperadas). No escribo documentos de diseño, pero si tengo que coordinar a varias personas, por supuesto, se necesita un esbozo del procedimiento, junto con un análisis de dependencias y tiempo estimado del tiempo necesario. Intenta mantener esta fase al mínimo si, como yo, prefieres un método más ágil. Hay casos en los que se necesita una fase de diseño fuerte, en particular cuando todo es conocido y verdadero sobre la lógica de su programa, y si planea tener muchas interacciones entre las características en su código. En este caso, los casos de uso o las historias de usuario proporcionan una buena idea de alto nivel, en particular para las aplicaciones GUI. Para aplicaciones de línea de comandos, y en particular bibliotecas, intente escribir "historias de programas" en las que codificas contra la biblioteca que tienes que desarrollar y comprobar cómo se ve. Estos programas se convertirán en pruebas funcionales de su biblioteca cuando se complete.

Después de esta primera iteración, tendrá una mejor comprensión de cómo interactúan las cosas, sacó los detalles y los puntos ásperos, resolvió problemas con un parche de cinta adhesiva abofeteada. Usted está listo para hacer uso de esta experiencia para mejorar, limpiar, pulir, dividir lo que era demasiado grande, unir lo que estaba demasiado fragmentado, defina y utilice patrones de diseño, analice cuellos de botella de rendimiento y problemas de seguridad no triviales. En general, todos estos cambios tendrán un gran impacto en las pruebas unitarias que escribió, pero no en las pruebas funcionales.

Cuando complete esta segunda iteración, tendrá una pequeña joya, bien probada, bien documentada y bien diseñada. Ahora tienes la experiencia y el código para hacer la tercera iteración, extender. Agregará nuevas características y casos de uso para mejorar su aplicación. Usted encontrará puntos ásperos y eventualmente entrará en una cuarta iteración que es análoga a la segunda. Enjuague y repita.

Este es mi enfoque general para el diseño de software. Es similar al diseño espiral, con iteraciones cortas de tres meses y elementos de desarrollo Ágil, que le permite aprender los problemas y conocer su software y su campo de aplicación. Por supuesto, es una cuestión de escalabilidad, por lo que si la aplicación es tan grande que involucra a cientos de desarrolladores, las cosas son un poco más complejo que esto, pero al final supongo que la idea es siempre la misma, dividir et impera.

Resumiendo:

1. En la iteración uno, se obtiene una muestra de ella, y aprender
2. En la iteración dos, usted limpia su producto y lo prepara para el futuro
3. En la iteración tres, agrega nuevas características y aprende más
4. goto 2

La fuente más interesante que conozco con respecto a esto es la Parte D de Construcción de Software Orientado a Objetos, 2a Edición por Bertrand Meyer.

Parte D: Metodología orientada a objetos: aplicar bien el método

19: Sobre metodología, 20: Diseño patrón: multi-panel interactivo sistema, 21: Estudio de caso de herencia: "deshacer" en un sistema interactivo, 22: Cómo encontrar las clases, 23: Principios de diseño de clase, 24: Usando herencia bien, 25: Útil técnicas, 26: Un sentido del estilo, 27: Análisis orientado a objetos, 28: El proceso de construcción de software, 29: Enseñanza del método

Curiosamente, el capítulo 22. Cómo encontrar las clases está disponible en línea.

A menudo se repite, pero es completamente cierto: comprende tus datos.

Para OOP tus clases deben describir las piezas más destacadas de información y cómo interactúan.

Si tienes un modelo mental que describe bien el comportamiento y la vida útil de los datos, tendrás un viaje fácil que establece tus clases.

Esto es simplemente una extensión de: Sepa exactamente lo que está tratando de hacer.

Intente usar el desarrollo basado en el comportamiento. Será difícil romper tus viejos hábitos, pero he descubierto que BDD realmente es tu mejor opción cuando se trata de desarrollarte en el mundo real.

Http://behaviour-driven.org/

El problema con los proyectos grandes es que no puede supervisar todas las interacciones entre los componentes. Por lo tanto, es importante reducir la complejidad del proyecto. Los diagramas de clase y Secuencia son demasiado detallados para esta fase del diseño.

Primero intenta pensar desde un nivel de abstracción más alto. Piense en los componentes principales y sus responsabilidades (su interfaz con otros componentes), mire algunos patrones arquitectónicos para inspirarse (no, no patrones de diseño, estos son demasiado bajos nivel! MVC y Multi-Tier son ejemplos de patrones arquitectónicos). Para proyectos razonablemente grandes, tal vista debe tener alrededor de 3-5 componentes.

Solo entonces haces zoom en un determinado componente e intentas diseñarlo. Ahora estamos en el nivel de patrones de diseño y diagramas de clases. Trate de centrarse en esta parte del proyecto, si encuentra que necesita agregar una responsabilidad a uno de los otros componentes, simplemente agréguela a su lista de documentación/ todo. No pierdas el tiempo pensando en las implicaciones en este punto cambian demasiado rápido, revise cuando el diseño es más sólido.

No es necesario diseñar completamente cada componente en este punto, aunque probablemente sea aconsejable tener un fragmento de código que implemente la interfaz de componentes no implementados y genere respuestas simples pero útiles. De esta manera, puede iniciar el desarrollo (y el diseño) de un componente a la vez y probarlo en un grado razonable.

Por supuesto, cuando se completen nuevos componentes, debe probar cómo (y if) se integran entre sí antes de seguir adelante.

En muy breve: Tome el OO y el principio de ocultación de información, y tire hacia arriba otro nivel!

PS: Hacer un montón de bocetos durante el diseño,es como la arquitectura real!

PPS: Trate de abordar el asunto desde diferentes ángulos, piense fuera de la caja (aunque la caja podría ser el camino a seguir), discutir con compañeros puede ser muy útil para esto... y tienes algo de qué hablar durante el almuerzo.

Patrones De Diseño

Patrones de Diseño Creativo

Singleton - Asegúrese de que solo se crea una instancia de una clase y proporcione un punto de acceso global al objeto.

Factory(Versión simplificada del Método Factory)- Crea objetos sin exponer la lógica de instanciación al cliente y hace referencia al objeto recién creado a través de una interfaz común.

Método Factory: Define una interfaz para crear objetos, pero permite que las subclases decida qué clase instanciar y se refiere al objeto recién creado a través de una interfaz común.

Abstract Factory - Ofrece la interfaz para crear una familia de objetos relacionados, sin especificar explícitamente sus clases.

Builder: Define una instancia para crear un objeto, pero permite que las subclases decidan qué clase instanciar y permite un control más preciso sobre el proceso de construcción.

Prototype-Especifica los tipos de objetos que se instancia prototípica, y crear nuevos objetos copiando este prototipo.

Patrones de Diseño Conductual

Cadena de responsabilidad - Evita adjuntar el remitente de una solicitud a su receptor, dando de esta manera a otros objetos la posibilidad de manejar la solicitud también. - Los objetos se convierten en partes de una cadena y la solicitud se envía de un objeto a otro a través de la cadena hasta que uno de los objetos lo maneje.

Comando-Encapsular una solicitud en un objeto, Permite la parametrización de clientes con diferentes solicitudes y Permite guardar las solicitudes en una cola.

Intérprete: Dado un idioma, defina una representación para su gramática junto con un intérprete que use la representación para interpretar oraciones en el idioma / Mapee un dominio a un idioma, el idioma a una gramática y la gramática a un diseño jerárquico orientado a objetos

Iterador-Proporcionar una forma de acceder a los elementos de un objeto agregado secuencialmente sin exponer su representación subyacente.

Mediator - Define un objeto que encapsula cómo interactúa un conjunto de objetos. Mediator promueve el acoplamiento suelto al evitar que los objetos se refieran entre sí explícitamente, y le permite variar su interacción de forma independiente.

Observer - Define una dependencia de uno a muchos entre objetos para que cuando un objeto cambie de estado, todos sus dependientes sean notificados y actualizados automáticamente.

Estrategia-Definir una familia de algoritmos, encapsulan cada uno, y los hacen intercambiables. La estrategia permite que el algoritmo varíe independientemente de los clientes que lo usan.

Método de plantilla: Defina el esqueleto de un algoritmo en una operación, aplazando algunos pasos a subclases / Método de plantilla permite que las subclases redefinan ciertos pasos de un algoritmo sin permitirles cambiar la estructura del algoritmo.

Visitante-Representa una operación que se realizará en los elementos de una estructura de objetos / Visitante le permite definir una nueva operación sin cambiar las clases de los elementos en los que opera.

Objeto Null - Proporcionar un objeto como sustituto de la falta de un objeto de un tipo dado. / El Patrón de Objeto Nulo proporciona un comportamiento inteligente de no hacer nada, ocultando los detalles de sus colaboradores.

Patrones de Diseño estructural

Adapter - Convierte la interfaz de una clase en otra interfaz que los clientes esperan. / Adapter permite que las clases trabajen juntas, que no podría de otra manera debido a interfaces incompatibles.

Bridge - Componga objetos en estructuras de árbol para representar jerarquías de parte-todo. / Composite permite a los clientes tratar objetos individuales y composiciones de objetos de manera uniforme.

Composite - Componga objetos en estructuras de árbol para representar jerarquías de parte-todo. / Composite permite a los clientes tratar objetos individuales y composiciones de objetos de manera uniforme.

Decorador-agregar responsabilidades adicionales dinámicamente a un objeto.

Flyweight - usa compartir para soportar un gran número de objetos que tienen parte de su estado interno en común donde la otra parte del estado puede variar.

Memento - captura el estado interno de un objeto sin violar la encapsulación y por lo tanto proporciona un medio para restaurar el objeto en el estado inicial cuando sea necesario.

Proxy - proporciona un "Marcador de posición" para que un objeto controle las referencias a él.

La técnica que he utilizado en proyectos reales con un éxito razonable es el Diseño impulsado por la Responsabilidad, inspirado en el libro de Wirfs-Brock.

Comience con las historias de usuario de nivel superior, y con los colegas, en una pizarra, bosqueje las interacciones de alto nivel que implican. Esto le da la primera idea de lo que son los grandes módulos; y una iteración o dos de alto nivel CRC-tarjeta como el juego debería haber estabilizado una lista de los principales componentes, lo que hacen y cómo interactúan.

Entonces, si alguna de las responsabilidades son grandes o complejas, refine esos módulos hasta que tenga cosas que son lo suficientemente pequeñas y simples como para ser objetos, al reproducir las interacciones dentro del módulo para cada una de las operaciones principales identificadas por las interacciones de nivel superior.

Saber cuándo parar es una cuestión de juicio (que solo viene con la experiencia).

Yo recomendaría usar BlueJ y también ActiveWriter para aprender y también para desarrollar una buena comprensión de los objetos. El libro recomendado también es un buen recurso.

De Wikipedia:

BlueJ es un Desarrollo Integrado Entorno para la programación Java lenguaje, desarrollado principalmente para fines educativos, sino también adecuado para software a pequeña escala desarrollo.

Además utiliza UML y para mí fue un buen recurso para comprender varias cosas sobre el modelado de objetos.

Texto alternativo http://www.ryanknu.com/ryan/bluej.png

ActiveWriter es una herramienta para modelar entidades y relaciones, también genera código y es fácil de hacer cambios. Le ahorrará tiempo y para el desarrollo ágil es muy adecuado.

Texto alternativo http://altinoren.com/activewriter/Images/Introduction_1.png

Creo que la respuesta aquí debería ser muy diferente dependiendo de la experiencia del mundo real del tipo que pregunta.

Si solo tienes uno o dos años de experiencia laboral, entonces debes ir al punto que es: ¿cómo llegas al punto en que realmente conoces tus datos y entiendes exactamente lo que estás tratando de hacer?

Sí, si ha estado trabajando en el mundo real más de 5 años, entonces elegiría entre cualquiera de los muchos modelos de procesos de desarrollo de software o técnica.

Pero no obtienes experiencia leyendo solo libros. Usted debe aprender trabajando en un buen grupo bajo un buen liderazgo.

Si eso no es posible, entonces deberías hacerlo solo. Comienza a iterar codificando un código probablemente muy desagradable, aprendiendo tus errores, descargándolo todo, codificando uno mejor y así sucesivamente.

Aprenderás mucho sobre tu base de código. Las herramientas son herramientas, no te enseñarán nada.

En primer lugar - el diseño debe venir de tu alma. Debes sentirlo por cada fibra. Suelo caminar dos o tres meses antes de empezar a hacer algo, simplemente caminando por las calles (realmente). Y pensando. Caminar es una buena meditación. Así que te permite concentrarte bien.

En segundo lugar - use OOP y clases solo donde exista una jerarquía de objetos natural. No lo "atornille" a eso artificialmente. Si no existe una jerarquía estricta (como en la mayoría de los negocios aplicaciones) - vaya por procedimientos / funcionales, o, al menos, use objetos solo como contenedores de datos con accesores aislados.

Y lo último - intenta leer esto: El Algoritmo del Pensamiento Creativo

Simplemente citando http://www.fysh.org / ~katie/computing/methodologies.txt

Y en el núcleo de RUP hay un área pequeña donde tienes que usar OO design talento.... si no los tienes, es como tener una metodología para corriendo los 100m.

"Paso 1: escribe sobre correr muy rápido. Paso 2: Ve y dibuja un plano de la pista de carreras. Paso 3: ve y compra shorts de lycra realmente ajustados. Paso 4: corre muy, muy, muy rápido. Paso 5: cruzar la línea primero "

Es ese paso 4 esa es la difícil. Pero si pones mucho énfasis en 1,2,3 y 5 es posible que nadie se dé cuenta y entonces usted podría probablemente hacer un montón de dinero vendiendo la metodología sería los atletas que piensan que hay algún "secreto" para ser un corredor de 100m sobre

Usted hizo una pregunta que muchos autores usan para escribir un libro. Hay una serie de metodologías y debes elegir una que te parezca "más bonita".
Puedo recomendar book "Domain Driven Design" de Eric Evans. Además, compruebe el sitio dddcommunity.org .

1. estudia y domina los Patrones de diseño.
2. A continuación, aprenda sobre el Diseño impulsado por el Dominio
3. Después de eso, aprenda la recopilación de requisitos

Tomé un curso de OOD unos semestres de vuelta y aprendí mucho de ella; como escribir UML y traducir requisitos documentos en objetos y clases. Aprendimos secuencia diagramas también, pero de alguna manera me perdí el conferencia o algo así, no lo hicieron quédate conmigo.

1. Sabes sobre el paso 3. Tienes que dominarlo. Quiero decir, a través de mucha práctica para que se convierta en tu segunda naturaleza. Eso es porque el método que aprendes, es simplemente en contra de la forma en que solíamos tener. Así que necesitas realmente dominarlo. De lo contrario, siempre se encontrará a sí mismo volver a su forma original de hacer las cosas. Esto es de alguna manera como un proceso impulsado por pruebas, donde muchos desarrolladores de Java lo abandonan después de algunos intentos. A menos que lo dominen completamente, de lo contrario es solo una carga para ellos

2. Escriba casos de uso, especialmente para cursos alternativos. El curso alternativo ocupa más del 50% de nuestro tiempo de desarrollo. Normalmente cuando su PM le asigna una tarea, por ejemplo, crear un sistema de inicio de sesión, pensará que es sencillo, puede tomar 1 día para terminarlo. Pero nunca tener en cuenta que es necesario tener en cuenta, 1. ¿qué pasa si la clave de usuario en la contraseña incorrecta, 2. qué pasa si el usuario introduce una contraseña incorrecta 3 veces, 3. qué pasa si el usuario no escribe el nombre de usuario y etc. Necesitas para enumerarlos y mostrárselos a su primer ministro, pídale que reprograme la fecha límite.

Me temo que esta no es una respuesta a la gente le gusta escuchar. De todos modos, déjame expresar mi opinión.

OOP debe ser visto como uno de los paradigmas, no como el paradigma superior. OOP es bueno para resolver cierto tipo de problemas, como desarrollar una biblioteca GUI. También encaja en el estilo de desarrollo de software generalmente seguido por grandes compañías de software: un equipo de élite de diseñadores o arquitectos establece el diseño de software en diagramas UML o en algún otro un medio similar y un equipo menos ilustrado de desarrolladores traducen ese diseño en código fuente. OOP ofrecen poco beneficio si usted está trabajando solo o con un pequeño equipo de programadores de gran talento. Entonces, es mejor usar un lenguaje que soporte múltiples paradigmas y te ayude a crear un prototipo rápido. Python, Ruby, Lisp / Scheme, etc. son buenas opciones. El prototipo es su diseño. Entonces mejora eso. Utilice el paradigma que es mejor para resolver el problema en cuestión. Si necesario, optimizar los puntos calientes con extensiones escritas en C o algún otro lenguaje de sistemas. Al usar uno de estos lenguajes, también obtienes extensibilidad de forma gratuita, no solo a nivel de programador sino también a nivel de usuario. Los lenguajes como Lisp pueden generar y ejecutar código dinámicamente, lo que significa que sus usuarios pueden extender la aplicación escribiendo pequeños fragmentos de código, en el idioma en el que está codificado el software. O si decide escribir el programa en C o C++, considere incrustar un intérprete para un idioma pequeño como Lua. Exponer funcionalidades como plugins escritos en ese lenguaje.

Creo que, la mayoría de las veces OOP y OOD crean software que son víctimas de sobre diseño.

Para resumir, mi forma preferida de escribir software es:

1. Utilice un lenguaje dinámico.
2. Escriba el diseño (prototipo) en ese lenguaje.
3. Si es necesario, optimice ciertas áreas usando C/C++.
4. Proporcionar extensibilidad por medio de el intérprete del lenguaje de implementación en sí.

La última característica permite que el software se adapte fácilmente a un usuario específico (¡incluyéndome a mí mismo!) requisito.

Si usted tiene experiencia en el dominio en el proyecto que va a trabajar como decir la banca. Es fácil estructurar sus objetos y usted sabe cómo esas mejoras vienen cada dos días.

Si no tienes esa experiencia, trabaja con alguien que tenga esa experiencia y convierte esas ideas en detalles técnicos.

Si está confundido acerca de cómo estructurar el diseño de su proyecto. Siga CIEGAMENTE el libro del "programador pragmático". Yo estaba en la misma situación antes, trate de leer un capítulo de ese libro. verá la diferencia, cambiará la forma en que piensa como desarrollador de software.

Utilizo Diseño basado en pruebas (TDD). Escribir la prueba primero realmente ayuda a llevarlo a un diseño que sea limpio y correcto. Véase http://en.wikipedia.org/wiki/Test-driven_development .

Aprenda patrones de diseño. Ha sido mi revolución personal los últimos dos años con respecto a la OOP. Consigue un libro. Te recomendaría este:

Patrones de Diseño de Cabeza Primero

Está en Java pero puede ser extensible a cualquier lenguaje.

Honestamente, un buen paso sería regresar y mirar los gráficos de flujo y la diagramación de secuencias. Hay un montón de buenos sitios que te muestran cómo hacerlo. Me parece que es invaluable cuando miro cómo quiero dividir un programa en clases, ya que sé exactamente lo que el programa necesita ingresado, computado y generado y cada paso se puede desglosar en una parte del programa.

Como se respondió en ¿Cuál es el flujo de trabajo que sigue para diseñar el software que está a punto de escribir?

Una técnica útil es relacionar la descripción de su problema único con algo que puede encontrar en el mundo real. Por ejemplo, usted está modelando un complejo sistema de salud que tomará al mundo por asalto. ¿Hay algún ejemplo que pueda utilizar fácilmente para modelar esto?

En efecto. Observe cómo operaría la farmacia lateral o la habitación del médico.

Reduce tu problema de dominio a algo comprensible para ti; algo con lo que puedas relacionarte.

Entonces una vez los "jugadores" dentro del dominio comienzan a parecer obvios, y usted comienza a modelar su código, opta por un enfoque de modelado "proveedor-consumidor", es decir, su código es el "proveedor" del modelo, y usted es el "consumidor".

Relacionarse con el dominio y entenderlo a un alto nivel es parte clave de cualquier diseño.

Durante mis aventuras de diseño de estructuras de clase, he notado que es muy útil comenzar escribiendo algún pseudo-código. Eso significa: Empiezo con "escribir" algunos fragmentos generales del código de la aplicación en un nivel más alto, juego con él y descubro los elementos que están apareciendo, de hecho, los elementos que yo, como programador, me gustaría usar. Es un muy buen punto de partida para diseñar la estructura general de los módulos y sus interacciones. Después de algunas iteraciones el conjunto la estructura comienza a parecerse más a un sistema completo de clases. Es una forma muy flexible de diseñar partes de código. Puedes llamarlo un diseño orientado al programador.