oop - oose - object oriented analysis and design pdf
¿Cómo desarrollar*habilidades de la vida real*oop? (12)
He estado estudiando OOP desde hace bastante tiempo y tengo una buena comprensión de la teoría. Leí el libro de Head First sobre OOP y, si bien reforzó gran parte de la teoría, encontré que los estudios de casos eran un tanto triviales.
Me parece que estoy aplicando los principios de OOP a mi código todos los días, pero no estoy seguro si los estoy aplicando correctamente. Necesito llegar al punto en el que pueda ver mi código y saber si estoy usando la herencia de manera apropiada, si mi objeto es lo suficientemente cohesionado, etc.
¿Alguien tiene alguna buena recomendación (libros, guías en línea, blogs, visitas, etc.) para dar el siguiente paso en el desarrollo de habilidades sólidas de OOP?
Estoy trabajando principalmente en .NET (Visual Basic), pero deseo recibir sugerencias que incorporen varias plataformas.
Lea Refactoring por Martin Fowler y aplíquelo a su propio trabajo.
Te llevará a través de una letanía de características malolientes de código de software que describen cómo detectar clases construidas incorrectamente, y aún más importante, cómo arreglarlas.
Mi Epifanía OOP vino del libro de Grady Booch, hace mucho tiempo. De repente me di cuenta de por qué los objetos eran buenos.
Mientras que el polimorfismo es bueno, la encapsulación es el 75% de por qué los objetos son geniales. Es una especie de interfaz: ves los botones pero no el cableado. Antes de los objetos, solo los codificadores más disciplinados mantenían sus dedos mugrientos fuera de los bits internos de los procedimientos de otras personas (se llamaba "programación estructurada").
Objeto hace que sea fácil hacer lo correcto. La herencia y el polimorfismo son pequeñas bonificaciones.
Una forma de aprender sobre los objetos es leer el código de otras personas. Aprendí mucho leyendo el código fuente del framework Delphi VCL. Incluso el solo hecho de mirar la documentación de Java lo ayudará a ver qué debe hacer una única clase de objeto y cómo está diseñado para ser utilizado por otros objetos.
Comience un proyecto propio y preste atención cuando desee subclasificar sus propias clases y descubra que tiene que retroceder y dividir algunos métodos protegidos para poder anular solo una parte de un proceso en lugar de reemplazarlo por completo. Vea cómo los antepasados hablan con los descendientes llamando funciones abstractas. En otras palabras, cometer muchos errores y aprender de ellos.
¡Disfrutar!
Si ya tiene lo básico, creo que solo la experiencia lo llevará más lejos. Usted dice que no está seguro si está aplicando los principios correctamente, pero no hay una forma correcta. El código que escribe hoy, lo verá dentro de 6 meses, y se preguntará por qué lo escribió de esa manera, y probablemente conozca una forma mejor y más limpia de hacerlo. También garantizo que después de 10 años, seguirás aprendiendo nuevas técnicas y trucos. No te preocupes demasiado por eso, vendrá, solo lee todo lo que puedas y trata de aplicar lo que lees en pequeños trozos.
Una cosa que definitivamente te ayudará es trabajar en un proyecto de código abierto conocido y respetado. Explore el código fuente y vea cómo se hacen las cosas o intente hacer algunas adiciones / modificaciones. Descubrirá que no hay un estilo o una respuesta correcta para la mayoría de los problemas, pero si mira varios proyectos, podrá obtener una visión amplia de cómo se pueden hacer las cosas. A partir de ahí, comenzará a desarrollar su propio estilo y, con suerte, hará algunas contribuciones al código abierto en el proceso.
Creo que debe intentar y no implementar las soluciones OO. Así es como lo hice de todos modos. Lo que quiero decir con el fracaso es que terminas escribiendo un código maloliente mientras entregas con éxito una solución de trabajo. Después de que esté escrito, tendrá una idea de dónde las cosas no se sentían bien. Puede tener algunas epifanías, y / o puede ir a buscar una solución más inteligente de otros programadores. Sin lugar a dudas, implementará una variación de los patrones de diseño estándar por accidente. En retrospectiva, una luz hará clic en (¡oh !, para eso está el visitante), y entonces la comprensión se acelerará.
Como han dicho otros, creo que es una buena idea utilizar herramientas con código fuente abierto de OO. Entonces está trabajando con programadores más experimentados que estarían dispuestos a criticar su trabajo. Sin embargo, la comprensión viene a través de hacer.
Es posible que desee intentar leer (y escribir) algunos Smalltalk por un tiempo. Squeak es una implementación gratuita que puede mostrarle el poder de un entorno totalmente orientado a objetos (a diferencia de Java o .net). Toda la fuente del código de la biblioteca está incluida. El lenguaje en sí es increíblemente simple. Descubrirá que java y c # están agregando lentamente las características conocidas de Smalltalk desde 1980.
Francamente, volver a leer los viejos documentos de David Parnas sobre ocultamiento de información me ayuda a tener el estado mental correcto. Es posible que los estudios de caso no sean directamente aplicables, pero debería poder obtener algunas generalizaciones útiles de ellos.
Mi epifanía ocurrió cuando traté de implementar un problema muy OO (creación de sentencias SQL de forma dinámica y recursiva) en VB6. La mejor forma de entender el polimorfismo o la herencia es necesitarlo y no poder usarlo.
Considere buscar patrones de diseño. Aunque parece que no se usan comúnmente en aplicaciones empresariales (las he visto más comúnmente usadas en API y Frameworks que en el código empresarial), podrían aplicarse para hacer que el software sea más simple o más robusto en muchas situaciones si solo los desarrolladores sabían cómo aplicarlos.
La clave es comprender primero los patrones de diseño, luego, con la experiencia, aprenderá cómo aplicarlos.
Hay un libro de Head First sobre patrones de diseño que enseña el concepto bastante simple, aunque si quieres un libro que realmente cubra los patrones de diseño en detalle, echa un vistazo al libro de patrones de diseño de Gang of Four , que es básicamente lo que hizo que los patrones de diseño referido casi cada vez que se menciona el tema.
Los patrones de diseño se pueden aplicar en casi cualquier lenguaje orientado a objetos en cierto grado u otro, aunque algunos patrones pueden ser exagerados o sobreingeniería en algunos casos.
EDITAR:
También quiero agregar que debes revisar el libro Code Complete 2 . Es un libro muy influyente en el mundo del desarrollo de software. Cubre muchos conceptos y teorías diferentes. Aprendo algo nuevo cada vez que lo leo. Es un libro tan bueno que si lo leo cada 6 meses a un año, lo veo desde una perspectiva diferente que me convierte en un mejor programador simplemente volviéndolo a leer. No importa cuánto creas que sabes, este libro te hará darte cuenta de lo poco que realmente sabes. Es realmente un gran libro. No puedo enfatizar cuánto debería poseer este libro.
Para comprender básicamente todo lo que hace falta, debe tener un conocimiento decente de al menos un nivel de abstracción arriba y un nivel debajo de él. En el caso de OO, otros han mencionado patrones de diseño como la capa por encima de OO. Esto ayuda mucho a ilustrar por qué OO es útil.
En cuanto a la capa debajo de OO, intente jugar con funciones de orden superior / encuadernación tardía por un tiempo y conozca cómo se usan estos constructos relativamente simples. Además, trate de comprender cómo se implementa OO bajo el capó (tablas, etc.) y cómo se puede hacer en C. puro. Una vez que asimile el valor de usar funciones de orden superior y vinculación tardía, se dará cuenta rápidamente de que OO es solo una sintaxis conveniente para pasar un conjunto de funciones relacionadas y los datos en los que operan.
Tortoise HG es una pieza extremadamente bien diseñada de software de código abierto OO (escrito en Python).
Si ya comprende los conceptos básicos, crear algo desde cero en un lenguaje completamente orientado a objetos será un buen paso para comprender completamente la arquitectura del software OOP. Si no conoce Python, Python Essential Reference lo guiará a través del idioma completo en unos pocos días a una semana.
Después de que comprenda el idioma, eche un vistazo a través del software anterior y tendrá todo tipo de epifanías.
Actualmente estoy a la mitad del siguiente libro:
http://www.amazon.com/Aplicación-UML-Patterns-Introduction-Object-Oriented/dp/0131489062
No puedo recomendar este libro con la suficiente fuerza en términos de aprender un enfoque práctico de la vida real y de nivel profesional para redactar y aplicar una estrategia de diseño bien formada e iterativa antes de sumergirme en el código.
Yo también leí el libro " Head First " y sentí que estaba mucho mejor por haberlo leído.
Después de algunos años de experiencia en el mundo laboral, ahora veo el libro de Craig Larman que recomiendo que sea el "siguiente paso" perfecto para mí.
Acerca de la presencia de "UML" en este libro Título:
Ya sea que tenga sentimientos positivos o sentimientos negativos sobre la notación UML, no permita que esto influya en su decisión de comprar el libro (ISBN 0131489062) en cualquier dirección.
La importancia de "UML" en el título es engañosa. Si bien el autor utiliza y explica la notación UML, estas explicaciones están muy bien entrelazadas en discusiones de diseño relevantes, y en ningún momento este libro se lee como una aburrida especificación UML.
De hecho, aquí hay una cita tomada directamente del libro:
Lo importante es saber cómo pensar y diseñar en objetos, lo cual es una habilidad muy diferente y mucho más valiosa que conocer la notación UML. Al dibujar un diagrama, debemos responder preguntas clave: ¿Cuáles son las responsabilidades del objeto? ¿Con quién colabora? ¿Qué patrones de diseño deberían aplicarse? ¡Mucho más importante que conocer la diferencia entre UML 1.4 y 2.0!
Este libro a veces parece que está "hablando con" un arquitecto principal o un gerente de proyecto. Lo que quiero decir con eso es que asume que el lector tiene un control significativo sobre la planificación y la dirección de un proyecto de software.
Sin embargo, incluso si usted es el único responsable de una parte muy pequeña de los proyectos y productos de su empresa, aún recomendaría este libro y lo alentaré a aplicar algunas modificaciones "a menor escala" del asesoramiento del libro a su pieza del proyecto.