oop - orientado - programacion orientada a objetos y sus aplicaciones
¿Cómo puedo practicar una mejor programación orientada a objetos? (27)
¡Aprende un idioma diferente! La mayoría de los desarrolladores que usan solo Java (solo como ejemplo) tienen una comprensión limitada de OO porque no pueden separar las características y los conceptos del lenguaje. Si aún no lo sabe, eche un vistazo a Python. Si conoces Python, aprende Ruby. O elija uno de los idiomas funcionales.
He estado programando en lenguajes orientados a objetos desde hace años, pero en secreto miro algunas de las cosas que mis colegas hacen con envidia. Muchos de ellos parecen tener algún instinto interno de OO que yo no tengo, sin importar cuánto lo intente. He leído todos los buenos libros sobre OO pero todavía no puedo descifrarlo. Me siento como el tipo que dio el 110% de ser un futbolista profesional pero no tenía el talento natural para hacerlo. Estoy perdido y pensando en cambiar de carrera, ¿qué debo hacer?
¡Enrolla tus mangas y código!
¡Rendirse! ¿Por qué necesitas ese POO? Solo escribe alguna aplicación utilizable. No mide usando POO, enfoque procedimental o funcional.
Sea cual sea el enfoque que elijas, el lenguaje Python debe ser sutable para practicarlo.
¿Has leído el capítulo sobre OO de la primera edición del libro de Scott Meyers "Effective C ++"? No llegó a ediciones posteriores, pero fue una gran explicación. El título era básicamente "di lo que quieres decir, significa lo que dices" sobre las convenciones adecuadas.
En realidad, es posible que desee ver mi respuesta a una pregunta similar here .
HTH
aclamaciones,
Cuantos más códigos escribas, más notarás las trampas de ciertas prácticas de programación. Después de suficiente tiempo y suficiente código, podrá identificar las señales de advertencia de estos peligros y podrá evitarlos. A veces, cuando escribo el código, me da comezón en el fondo de la mente diciéndome que puede haber una mejor manera de hacerlo, aunque haga lo que necesito. Una de mis mayores debilidades de programación es "analizar demasiado" las cosas tanto que comienza a ralentizar drásticamente el tiempo de desarrollo. Estoy tratando de evitar estas "picazones" dedicando un poco más de tiempo al diseño, lo que generalmente resulta en mucho menos tiempo para escribir el código.
... secretamente veo algunas de las cosas que mis colegas hacen con envidia. Muchos de ellos parecen tener algún instinto interno de OO que yo no tengo, sin importar cuánto lo intente ...
Creo que has respondido tu propia pregunta aquí. Leer un buen código es un buen comienzo, y comprender un buen código es aún mejor, pero entender los pasos para llegar a ese buen código es lo mejor. Cuando vea algún código del que tenga envidia, tal vez podría preguntarle al autor cómo llegó a esa solución. Esto depende totalmente de su entorno de trabajo, así como de las relaciones con sus colegas. En cualquier caso, si alguien me pregunta el proceso de pensamiento detrás de cualquier código que escriba, no dudo en decirles porque sé que me gustaría que hagan lo mismo por mí.
Diría que se concentre menos en la programación de OO y se concentre más en el diseño de OO. Tome un papel y un lápiz (o tal vez una herramienta de modelado UML) y aléjese de la pantalla.
Al practicar cómo diseñar un sistema, comenzará a tener una sensación natural de las relaciones entre objetos. El código es solo un subproducto del diseño. Dibuja diagramas y modela tu aplicación en una forma puramente no codificada. ¿Cuáles son las relaciones? ¿Cómo interactúan tus modelos? Ni siquiera pienses en el código.
Una vez que haya dedicado tiempo al diseño ... luego tradúzcalo al código. Te sorprenderá lo rápido que se puede escribir el código de un buen diseño OO.
Después de una gran cantidad de práctica de diseño, comenzará a ver áreas comunes que se pueden modularizar o abstraer, y verá una mejora tanto en sus diseños como en su código.
El aswer está en tu pregunta;)
Práctica práctica práctica.
Revise su propio código y aprenda de los errores.
En muchos campos hay un momento "eureka" donde todo se combina.
Recuerdo sentirme frustrado en la geometría de la escuela secundaria. No sabía qué teorema aplicar en cada paso de la prueba. Pero lo seguí. Aprendí cada teorema en detalle y estudié cómo se aplicaban en diferentes ejemplos de pruebas. Como entendí no solo la definición de cada teorema, sino también cómo usarlo, construí una "caja de herramientas" de técnicas familiares que podía extraer cuando fuera necesario.
Creo que es lo mismo en programación. Es por eso que se estudian y analizan algoritmos, estructuras de datos y patrones de diseño. No es suficiente leer un libro y obtener la definición abstracta de una técnica. Tienes que verlo en acción también.
Intente leer más código , además de practicarlo usted mismo. Esa es una de las ventajas del código abierto, puedes descargar muchos códigos para estudiar. No todo ese código es bueno, pero estudiar el código incorrecto puede ser tan educativo como estudiar un buen código.
Eres mi público objetivo. Mira las habilidades de construcción en OO Design
Quizás esto puede ayudar.
Finalmente, OO me hizo clic después de que traté de programar un programa tipo banco que manejaba transacciones, calculaba intereses y hacía un seguimiento de todo. Lo hice mientras estaba aprendiendo Java. Yo sugeriría solo intentarlo, completarlo, y luego, cuando termines, ve una buena solución y ve lo que podrías haber hecho mejor.
Hay demasiada información sobre los objetos. Lo más importante es dominar los conceptos básicos y todo encaja más fácilmente.
Aquí hay una manera de pensar acerca de los objetos. Piense en las estructuras de datos en los lenguajes de procedimiento. Son un grupo de campos sin comportamiento. Piense en las funciones que reciben punteros a esas estructuras de datos y manipule las últimas. Ahora, en lugar de separarlos, defina las funciones dentro de la definición de las estructuras y asuma que las funciones generalmente reciben un puntero a la estructura de datos para manipular. Ese puntero se llama esto. En resumen, piense en objetos como la combinación de estado (datos) y comportamiento (métodos: el nombre elegante para funciones en OOP).
Este es el básico absoluto. Hay tres conceptos más que debes dominar absolutamente:
Herencia: se trata de la reutilización del código.
Encapsulación: se trata de ocultar la implementación de la interfaz. En pocas palabras, todo debe ser privado hasta que se demuestre lo contrario.
Polimorfismo: no importa el tipo de la variable de referencia, sino el tipo de la instancia real para saber qué comportamiento (método) se llama. Java no hace que sea fácil tener este concepto muy visible porque, por definición, todo es polimórfico. .Net lo hace más fácil de entender a medida que usted decide qué es polimórfico y qué no lo es, por lo tanto, observa la diferencia en el comportamiento. Esto se logra mediante la combinación de virtual y override.
Si estos conceptos son muy bien entendidos, estarás bien.
Un último consejo final: mencionas los mejores libros. ¿Has leído " Thinking in Java " de Bruce Eckel? Recomiendo este libro incluso a las personas que están comenzando en .Net, ya que los conceptos de OOP están claramente establecidos.
La forma más fácil es aprender conceptos como SÓLIDO, SECO, AJUSTE, DDD, TDD, MVC, etc. Al buscar estos acrónimos, te llevará a muchos otros agujeros de conejo y una vez que hayas terminado con tu lectura deberás tener un buena comprensión de lo que es una mejor programación orientada a objetos.
Podcasts SOLIDOS: http://www.hanselminutes.com/default.aspx?showID=168 , http://www.hanselminutes.com/default.aspx?showID=163
Desglose SÓLIDO: http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod
DRY: http://en.wikipedia.org/wiki/Don%27t_repeat_yourself
FIT: http://www.netwellness.org/question.cfm/38221.htm
DDD requiere lectura: http://www.infoq.com/minibooks/domain-driven-design-quickly
TDD: http://en.wikipedia.org/wiki/Test-driven_development
MVC: http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller
Y sí, arremangarse y codificar es siempre una buena idea. Haga un pequeño proyecto con sus mejores habilidades actuales. Luego lee un artículo de arriba. Luego refactorice su código para cumplir con las necesidades de lo que acaba de leer. Repite hasta que hayas refactorizado el código. Al final, no solo debe saber de qué se trata la OO, sino también debe poder explicar por qué es importante y cómo obtenerla por primera vez. Aprender a refactorizar también es clave para un buen código. Lo que está en este momento no está bien mañana.
Los diseñadores de idiomas han interpretado la "Programación Orientada a Objetos" de diferentes maneras. Por ejemplo, vea cómo Alan Kay, el hombre que utilizó por primera vez el término OOP, lo definió:
OOP para mí solo significa mensajería, retención local y protección y ocultamiento del proceso estatal, y enlace extremo de todas las cosas. Se puede hacer en Smalltalk y en LISP. Posiblemente haya otros sistemas en los que esto es posible, pero no los conozco.
(Citado de http://userpage.fu-berlin.de/~ram/pub/pub_jf47ht81Ht/doc_kay_oop_en ).
¡Puede parecer extraño que no considere los lenguajes OOP Java y C ++! Pero como diseñador de uno de los primeros y mejores lenguajes de programación orientada a objetos (Smalltalk) tiene sus propias razones válidas para eso. ¿Por qué Alan Kay consideraba que Lisp era un lenguaje orientado a objetos pero no Java? Esa pregunta exige una consideración seria por parte de cualquier persona que afirme comprender OOP.
Erlang tiene una implementación totalmente diferente de OOP, Scheme tiene otra. Vale la pena considerar todas estas vistas alternativas. ¡Si es posible aprende todos estos idiomas! Eso te dará una perspectiva más amplia, pondrás algunas herramientas nuevas y poderosas en tu mano y te convertirás en un mejor programador.
He resumido mis experimentos con la implementación de un lenguaje OOP, basado en ideas tomadas de Smalltalk, Scheme y Erlang en este artículo .
Mi sugerencia sería aprender algo diferente.
Aprenda la programación funcional y aplique lo que aprenda de eso a OOP. Si conoces C ++, juega con la programación genérica.
Aprende idiomas no orientados a objetos.
No solo porque deberías usar todas estas cosas también (deberías), o porque deberían reemplazar completamente el OOP ( probablemente no deberían), sino porque también puedes aplicar las lecciones de estos a OOP.
El secreto de OOP es que no siempre tiene sentido usarlo . No todo es una clase. No todas las relaciones o comportamientos deben modelarse como una clase.
Intento ciegamente aplicar OOP, o esforzarse por escribir el mejor código de OOP posible tiende a conducir a enormes desordenes enmascarados con demasiados niveles de abstracción e indirección y muy poca flexibilidad.
No intente escribir un buen código OOP. Intenta escribir un buen código. Y usa OOP cuando contribuye a ese objetivo.
OOP habilidades viene con el tiempo. Leer 1, 2 ... 10 libros no es suficiente. Practica escribir un código. Si trabajas en un entorno de programación ... eso puede ser útil. Si no, intente entrar en uno. Ofrezca desarrollar algunas aplicaciones de forma gratuita. Tienes que ensuciarte las manos. Recuerda ... ninguna aplicación es perfecta desde el principio. Por eso hay un nuevo factor.
Además ... no te dejes llevar demasiado por el OOP ... con el tiempo. Preocuparse por desarrollar aplicaciones completamente funcionales.
OOP no es algo que pueda dominar leyendo miles de libros. Más bien tienes que sentir los conceptos internos. Lee cualquier cosa, pero intenta sentir lo que lees. Construya un concepto en el fondo de su mente e intente hacer coincidir esos conceptos cuando enfrenta un nuevo escenario. Verifique y actualice sus conceptos mientras explora cosas nuevas.
¡Buena suerte!
Planea las cosas. Pregúntese cómo quiere que sus objetos se relacionen entre sí y busque cómo se pueden cambiar y modular las cosas.
Codifique las cosas de tal manera que si quiere cambiar 1 parte del código, solo tiene que cambiar ese 1 código y no 50 instancias del mismo.
Pruebe algunos programas en Self , uno de los lenguajes OO más puros que existen. Tan puro, de hecho, que ni siquiera tiene clases, solo objetos. Tampoco tiene variables, campos, estadísticas, atributos, solo métodos. También es interesante el hecho de que cada objeto en el sistema también es un objeto en la pantalla y viceversa.
Algunos de los trabajos interesantes sobre Self son la construcción de aplicaciones basadas en prototipos utilizando SELF 4.0 (Self tutorial), Self: The Power of Simplicity y organizando programas sin clases . Además, Self: The Video (Randall B. Smith; Dave Ungar) es excelente, ya que dos de los diseñadores del idioma explican las ideas de Self.
Esto funciona para casi cualquier concepto, en realidad, al menos para mí: encuentre el lenguaje que represente más puramente el concepto que desea aprender y simplemente utilícelo.
Sé más ágil, aprende pruebas junit y estudia el diseño impulsado por el dominio. Sugiero el libro Diseño orientado al dominio: abordar la complejidad en el corazón del software, aunque es un poco difícil en algunos puntos.
Si está perdido en cuanto a cómo diseñar sistemas orientados a objetos, comience con los datos. Averigüe de qué cosas necesita hacer un seguimiento y qué información va naturalmente unida (por ejemplo, todas las especificaciones de un modelo de grupo de automóviles juntas muy bien).
Cada uno de estos tipos de cosas que decide rastrear se convierte en una clase.
Luego, cuando necesite poder ejecutar acciones particulares (por ejemplo, marcar un modelo de automóvil como desmantelado) o hacer preguntas particulares (por ejemplo, preguntando cuántos de un modelo de automóvil dado se vendieron en un año determinado), carga esa funcionalidad en la clase con la que interactúa más.
En general, siempre debe haber un lugar bastante natural para que un determinado bit de código viva en la estructura de su clase. Si no lo hay, eso indica que hay un lugar donde la estructura debe construirse.
Tú mismo dijiste la respuesta: practica. La mejor solución para esto es desarrollar un juego. Usa los conceptos que aprendiste en los libros allí.
También creo que las habilidades de OOP se fortalecen principalmente con la práctica. Considere cambiar su compañía, si ha estado allí por más de 3 años. Ciertamente, esto no es válido para todos los trabajos, pero a menudo un hombre se acostumbra a los proyectos y prácticas en una empresa y deja de avanzar a medida que pasa el tiempo.
la cerveza ayuda. seriamente. acuéstese en un sofá con un bloc de notas tamaño A3, un bolígrafo y una cerveza. Bloquee el perro, el gato y la esposa afuera. Y piense en el problema mientras está relajado. ¡Ni siquiera te atrevas a dibujar una API en él!
Los diagramas de flujo, las tarjetas de responsabilidad (CRC) y la cerveza (pero no demasiado) son muy efectivos.
La manera más fácil de refactorizar el código es no tener que hacerlo en primer lugar.
http://en.wikipedia.org/wiki/Test-driven_development me ha ayudado más a mejorar mi conjunto de habilidades generales, incluido OOP.
http://misko.hevery.com/code-reviewers-guide/
Esas pequeñas reglas simples te harán un mejor programador OO. Sigue las reglas religiosamente mientras codificas y encontrarás que tu código es mejor de lo que sería de otra manera.
También querrás aprender los Principios Sólidos: http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod
Por mucho que estos principios y formas de programación causen debate, son la única forma de escribir realmente un código excelente.
Puede que ya escriba el código de esta manera y no lo sepa, de ser así, genial. Pero si necesita un objetivo al que aspirar, este es el estándar de oro.
Demasiadas personas piensan en codificar primero, objetos, último.
Puedes leer todos los libros que quieras, pero eso no te enseñará a pensar de forma orientada a objetos, eso requiere práctica y una cierta metodología.
Aquí hay algunos métodos que me han ayudado: cuando está lejos del trabajo y de mente abierta, puede practicar mirando todo como un objeto . No mire estos objetos y se pregunte cómo los va a programar, mírelos como propiedades y funciones únicamente y cómo se relacionan o heredan el uno del otro. Por ejemplo, cuando ves a una persona, es un objeto y, por lo tanto, representaría una clase. Tienen propiedades como el color del pelo, el tono de la piel, la altura, etc. También realizan ciertas funciones. Caminan, hablan, duermen, etc. Algunas de las funciones que estas personas realizan son resultados. Por ejemplo, su función de trabajo devuelve una cantidad en dólares. Puedes hacer esto con todo lo que ves porque todo es un objeto. Bicicleta, automóvil, estrella, etc.
Antes de codificar un proyecto, diseñe usando notas post-it y una pizarra de borrado en seco. Esto será una buena práctica hasta que te familiarices con esto. Piensa en tu objeto / función / propiedad específica. Cada uno de esos elementos tendrá su propia nota post-it. Colóquelos como una jerarquía en el tablero de borrado en seco. En este sentido, la función / propiedades se colocarán debajo del objeto. Si tiene otro objeto, haga lo mismo para ese. Luego pregúntese, haga que alguna de estas notas de post-it (objetos / funciones / propiedades) se relacionen entre sí. Si dos objetos usan la misma función, cree un objeto principal (nota post-it) y colóquelo sobre los demás con la función reutilizable bajo la nueva nota. Dibuje una línea usando el marcador de borrado en seco de los dos objetos secundarios para el padre.
Cuando todo esto termine, preocúpese por los aspectos internos de cómo funciona la clase.
public void MasteryOfOOP()
{
while(true)
/* My suggestion is: */
DO: find a lot of well-written object oriented code and read it. Then
try to use the insights from it on your own coding. Then do it again. Then
have a colleague who is a good OOP look at it and comment. Maybe post a chunk
of your code on SO and ask for how it could be improved.
Then read some more of those books. Maybe they make a little more
sense now...?
Now go back to the top of this post, and do it again.
Repeat Forever.
}
}