Buenos desafíos / tareas / ejercicios para aprender o mejorar las habilidades de programación orientada a objetos (OOP) [cerrado]

¿Cuál es un buen desafío para mejorar sus habilidades en la programación orientada a objetos?

La idea detrás de esta encuesta es proporcionar una idea de qué ejercicios son útiles para aprender OOP.

El desafío debe ser tan independiente del lenguaje como sea posible, requiriendo poco o ningún uso de bibliotecas específicas, o solo las bibliotecas más comunes. Trate de incluir solo un desafío por respuesta, de modo que un voto corresponda únicamente a los méritos de ese desafío. También sería bueno si se indicara el nivel de habilidad requerido, y también la razón por la que es un ejercicio útil.

Las soluciones a los desafíos podrían publicarse como respuestas a una pregunta de "Cómo ..." y vincularse desde aquí.

Por ejemplo:

• Desafío: implementar una pila de último en entrar, primero en salir
• Nivel de habilidad: principiante
• Justificación: da experiencia sobre cómo hacer referencia a objetos.

Building Skills in Object-Oriented Design es un libro gratuito que puede resultar útil.

[ EDITAR: El libro original parece tener bitrotted (404 para todos los formatos) pero Internet Archive tiene versiones como HTML , PDF y MOBI ]

La descripción es la siguiente:

"La intención de este libro es ayudar al diseñador principiante dándoles una secuencia de ejercicios interesantes y moderadamente complejos en el diseño de OO. Este libro también puede ayudar a los gerentes a desarrollar un nivel de comodidad con el proceso de desarrollo de software de OO. build son un paso por encima de lo trivial y requerirán un pensamiento y un diseño cuidadosos. Además, debido a que las aplicaciones son en gran parte de naturaleza recreativa, son interesantes y atractivas. Este libro permite al lector explorar los procesos y artefactos del diseño de OO antes de los plazos del proyecto hacer que un buen diseño parezca imposible ".

Escribe un programa desafiante desde cero . Intente que algunas personas (alrededor de cinco, eso debería ser factible) para usarlo. Responda a sus solicitudes de cambio.

Adapte el diseño de su programa. Empiece con algo pequeño y luego observe cómo crece. Gestione este crecimiento. Esto es duro. También tendrá que corregir errores y mantener el dispositivo a lo largo del tiempo, lo que para mí fue una lección muy valiosa.

Desafío: escriba un contenedor para su sitio web / API de servicio de su elección en el idioma que elija, que aún no exista (por ejemplo, un contenedor de API de ZenDesk escrito en C #). Libera el contenedor como código abierto para que otros lo usen.

Nivel de habilidad: principiante a intermedio

Justificación: aprender a extrapolar una API de servicios web de terceros a un conjunto significativo de objetos / clases, lo que facilita la reutilización de esa API en el idioma elegido.

Una vez que haya aprendido los conceptos básicos, estudie el libro de patrones de diseño "Gang of four".

http://www.amazon.com/Design-Patterns-Object-Oriented-Addison-Wesley-Professional/dp/0201633612/ref=pd_bbs_sr_1?ie=UTF8&s=books&qid=1221488916&sr=8-1

Este es un clásico y una lectura obligada para cualquier codificador que quiera entender cómo usar OO para diseñar soluciones elegantes a problemas comunes de codificación.

Tome un fragmento de código escrito de estilo procedimental e intente transformarlo en una solución basada en OOP. Durante el proceso, consulte un libro sobre refactorización y patrones de diseño. Un amigo mío pudo dar un gran paso adelante en la comprensión de los conceptos orientados a objetos exactamente de esta manera. Como con cualquier otra cosa, es posible que esto no funcione para todos.

He descubierto que las tarjetas CRC son bastante efectivas para aprender, enseñar y construir un buen diseño de OO.

Ciertamente, un buen desafío, aunque menos accesible que una asignación de "empezar desde cero", es refactorizar algún código existente que no usa herencia o no usa mucho para hacer un mayor uso de la herencia. El proceso de refactorización expondrá muchos de los beneficios y trampas de oop, como ciertamente lo ha hecho para mí en mi proyecto más reciente. También me impulsó a comprender los conceptos mejor que los proyectos anteriores en los que he creado mis propios diseños orientados a objetos.

Una tarea determinada tiene muy poco que ver con ser "OOP", es más en cómo la calificas.

Miraría el libro de Refactorización, capítulo 3, y me aseguraría de que ninguno de los malos olores de código exista en la solución. O, lo que es más importante, repase las que se aplican.

Lo más importante es que esté atento a la existencia de establecedores y captadores (lo que indica que está operando con valores de una clase y no le pide a la clase que opere en sus propios valores), o use "extiende" sin aplicar el principio de sustitución de Liskov, cosas como ese.