¿Cómo puedo practicar una mejor programación orientada a objetos? [cerrado]

He estado programando en lenguajes orientados a objetos durante años, pero en secreto miro algunas de las cosas que hacen mis colegas con envidia. Muchos de ellos parecen tener un instinto OO interno que yo no tengo, no importa cuánto lo intente. He leído todos los buenos libros sobre OO pero todavía parece que no puedo descifrarlo. Me siento como el tipo que dio el 110% para ser futbolista profesional pero simplemente no tenía el talento natural para hacerlo. Estoy perdido y pensando en cambiar de carrera, ¿qué debo hacer?

Yo diría que se centran menos en la programación OO y se centran más en el diseño OO . Coge un papel y un lápiz (o quizás una herramienta de modelado UML) y aléjate de la pantalla.

Al practicar cómo diseñar un sistema, comenzará a tener una idea natural de las relaciones entre objetos. El código es solo un subproducto del diseño. Dibuje diagramas y modele su aplicación en una forma puramente sin código. ¿Cuáles son las relaciones? ¿Cómo interactúan tus modelos? Ni siquiera pienses en el código.

Una vez que haya pasado tiempo diseñando ... luego tradúzcalo a código. Se sorprenderá de lo rápido que se puede escribir el código a partir de un buen diseño orientado a objetos.

Después de mucha 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.

La forma más fácil es aprender conceptos como SÓLIDO, SECO, FIT, DDD, TDD, MVC, etc. A medida que busque estos acrónimos, lo llevará por muchos otros agujeros de conejo y una vez que haya terminado con su lectura, debe tener un buena comprensión de lo que es una mejor programación orientada a objetos.

Podcasts SOLID: 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

SECO: http://en.wikipedia.org/wiki/Don%27t_repeat_yourself

AJUSTE: http://www.netwellness.org/question.cfm/38221.htm

DDD: http://dddcommunity.org/

Lectura obligatoria de DDD: 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 siempre es una buena idea. Haga un pequeño proyecto lo mejor que pueda. Entonces lee un artículo de arriba. Luego, refactorice su código para satisfacer las necesidades de lo que acaba de leer. Repita hasta que haya refactorizado completamente su código. Al final, no solo debe saber de qué se trata la OO, sino que también debe poder explicar por qué es importante y cómo obtenerla la primera vez. Aprender a refactorizar también es clave para un buen código. Lo que está bien ahora no está bien mañana.

Demasiada gente piensa en codificar primero y los objetos al final.

Puedes leer todos los libros que quieras, pero eso no te enseñará a pensar de una manera orientada a objetos, eso requiere práctica y cierta metodología.

1. Aquí hay algunos métodos que me han ayudado: Cuando estás fuera del trabajo y tienes la mente abierta, puedes practicar mirando todo como un objeto . No mire estos objetos y se pregunte cómo los va a programar, mírelos sólo como propiedades y funciones y cómo se relacionan o heredan entre sí. Por ejemplo, cuando ves a una persona, es un objeto y, por lo tanto, representaría una clase. Tienen propiedades como el color del cabello, el tono de la piel, la altura, etc. También cumplen determinadas funciones. Caminan, hablan, duermen, etc. Algunas de las funciones que realizan estas personas dan 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, coche, estrella, etc.

2. Antes de codificar un proyecto, diséñelo con notas adhesivas y una pizarra de borrado en seco. Esto será una buena práctica hasta que lo domines. Piense en su objeto / función / propiedad específicos. Cada uno de esos elementos tendrá su propia nota post-it. Colóquelos como una jerarquía en la pizarra de borrado en seco. En este sentido, la función / propiedades se colocarán debajo del objeto. Si tiene otro objeto, haga lo mismo con ese. Luego pregúntese, ¿alguna de estas notas post-it (objetos / funciones / propiedades) se relacionan entre sí? Si dos objetos usan la misma función, cree un objeto principal (nota adhesiva) y colóquelo encima de los demás con la función reutilizable debajo de la nueva nota. Dibuja una línea con el marcador de borrado en seco desde los dos objetos secundarios hasta el padre.

3. Cuando todo esto esté hecho, entonces preocúpese por los aspectos internos de cómo funciona la clase.

Mi sugerencia sería aprender algo diferente.

Aprenda programación funcional y aplique lo que aprenda de eso a la programación orientada a objetos. Si conoce C ++, juegue con la programación genérica.

Aprenda lenguajes no orientados a objetos.

No solo porque debería usar todas estas cosas también (debería hacerlo), o porque deberían reemplazar completamente la POO ( probablemente no deberían), sino porque también puede aplicar las lecciones de estas a la POO.

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.

Tratar ciegamente de aplicar OOP, o esforzarse por escribir el mejor código de OOP posible, tiende a generar grandes desordenes de ingeniería con demasiados niveles de abstracción e indirecta y muy poca flexibilidad.

No intente escribir un buen código OOP. Intenta escribir un buen código. Y use OOP cuando contribuya a ese objetivo.

En muchos campos hay un momento "eureka" en el que todo se junta.

Recuerdo que me sentí frustrado en la geometría de la escuela secundaria. No sabía qué teorema aplicar en cada paso de la demostración. Pero seguí en eso. Aprendí cada teorema en detalle y estudié cómo se aplicaban en diferentes demostraciones de ejemplo. Como entendí no solo la definición de cada teorema, sino cómo usarlo, construí una "caja de herramientas" de técnicas familiares que podía sacar según 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. También tienes que verlo en acción.

Así que intente leer más código , además de practicar cómo escribirlo usted mismo. Esa es una belleza del código abierto, puedes descargar mucho código para estudiar. No todo ese código es bueno, pero estudiar un código incorrecto puede ser tan educativo como estudiar un buen código.

¡Aprende un idioma diferente! La mayoría de los desarrolladores que utilizan solo Java (solo como ejemplo) tienen un conocimiento limitado 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 lenguajes funcionales.

La respuesta está en tu pregunta;)

Práctica práctica práctica.

Revise su propio código y aprenda de los errores.

TDD me ha ayudado más a mejorar mis habilidades generales, incluida la programación orientada a objetos.

Cuanto más código escriba, más notará 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 errores y podrá evitarlos. A veces, cuando escribo código, tengo esta picazón en el fondo de mi mente que me dice que puede haber una mejor manera de hacer esto, incluso si hace lo que necesito. Una de mis mayores debilidades de programación es "sobreanalizar" las cosas tanto que comienza a ralentizar drásticamente el tiempo de desarrollo. Estoy tratando de prevenir estas "picaduras" dedicando un poco más de tiempo al diseño, lo que generalmente resulta en mucho menos tiempo escribiendo código.

... en secreto miro algunas de las cosas que hacen mis compañeros con envidia. Muchos de ellos parecen tener algún instinto OO interno que yo no tengo, no importa cuánto lo intente ...

Creo que ha respondido a su propia pregunta aquí. Leer un buen código es un buen comienzo y comprender un buen código es aún mejor, pero comprender los pasos para llegar a ese buen código es lo mejor. Cuando veas algún código que envidia, quizás puedas preguntarle al autor cómo llegó a esa solución. Esto depende completamente 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 escribo, no dudo en decírselo porque sé que me gustaría que hicieran lo mismo por mí.

Los diseñadores de lenguajes han interpretado la "programación orientada a objetos" de diferentes formas. Por ejemplo, vea cómo Alan Kay, el hombre que utilizó por primera vez el término POO, lo definió:

Para mí, la programación orientada a objetos significa solo mensajería, retención local y protección y ocultación del proceso de estado y vinculación tardía extrema de todas las cosas. Se puede hacer en Smalltalk y en LISP. Es posible que existan otros sistemas en los que esto sea 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 Java y C ++ OOP! 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 ello. ¿Por qué Alan Kay consideró Lisp un lenguaje orientado a objetos pero no Java? Esa pregunta exige una seria consideración por parte de cualquiera que afirme comprender la POO.

Erlang tiene una implementación completamente diferente de OOP, Scheme tiene otra. Vale la pena considerar todas estas visiones alternativas. ¡Si es posible, aprenda todos estos idiomas! Eso le dará una perspectiva más amplia, pondrá algunas herramientas nuevas y poderosas en su mano y lo convertirá 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 .

       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.

        }
    }

Si no sabe cómo diseñar sistemas orientados a objetos, comience con los datos. Averigüe qué cosas necesita para realizar un seguimiento y qué información va naturalmente junta (por ejemplo, todas las especificaciones de un modelo de automóvil se agrupan muy bien).

Cada uno de estos tipos de cosas que decidas seguir se convierte en una clase.

Luego, cuando necesite poder ejecutar acciones particulares (por ejemplo, marcar un modelo de automóvil como retirado) o hacer preguntas específicas (por ejemplo, preguntar cuántos de un modelo de automóvil determinado se vendieron en un año determinado), carga esa funcionalidad en la clase con la que interactúa más intensamente.

En general, siempre debería haber un lugar bastante natural para que un fragmento de código determinado viva en la estructura de su clase. Si no lo hay, eso indica que hay un lugar donde se debe construir la estructura.

Hay demasiada información sobre los objetos. Lo más importante es dominar los conceptos básicos y todo encaja más fácilmente.

He aquí una forma de pensar en los objetos. Piense en estructuras de datos en lenguajes de procedimiento. Son un grupo de campos sin comportamiento. Piense en funciones que reciben punteros a esas estructuras de datos y manipulan estas últimas. Ahora, en lugar de separarlas, 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 así. En resumen, piense en los objetos como la combinación de estado (datos) y comportamiento (métodos, el nombre elegante de las funciones en OOP).

Este es el básico absoluto. Hay tres conceptos más que debes dominar absolutamente:

Herencia: se trata de reutilizar el 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 variable de referencia, sino el tipo de instancia real para saber qué comportamiento (método) se llama. Java no facilita que este concepto sea muy visible porque, por definición, todo es polimórfico. .Net hace que sea más fácil de entender a medida que decide qué es polimórfico y qué no, por lo que se nota la diferencia en el comportamiento. Esto se logra mediante la combinación de virtual y override.

Si estos conceptos se entienden muy bien, estará bien.

Un último consejo final: mencionas los mejores libros. ¿Ha leído " Pensando en Java " de Bruce Eckel? Recomiendo este libro incluso a las personas que se inician en .Net, ya que los conceptos de programación orientada a objetos están claramente establecidos.

Sea más ágil, aprenda pruebas junit y estudie sobre diseño dirigido por dominios. Sugiero el libro Domain-Driven Design: Tackling Complexity in the Heart of Software, aunque es un poco difícil en algunos puntos.

Las habilidades de OOP llegan con el tiempo. Leer 1, 2 ... 10 libros no es suficiente. Practica escribiendo código. Si está trabajando 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. Recuerde ... ninguna aplicación es perfecta desde cero, por eso hay refactorización.

Además ... no te dejes llevar demasiado por la programación orientada a objetos ... esto cambia con el tiempo. Preocúpese por desarrollar aplicaciones completamente funcionales.

Prueba algo de programación 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, estática, atributos, solo métodos. También es interesante el hecho de que cada objeto del sistema es también un objeto en la pantalla y viceversa.

Algunos de los artículos interesantes sobre Self son Construcción de aplicaciones basadas en prototipos usando SELF 4.0 (el tutorial de Self), Self: The Power of Simplicity y Organizing Programs Without Classes . Además, Self: The Video (Randall B. Smith; Dave Ungar) es excelente, ya que dos de los diseñadores del lenguaje explican las ideas de Self.

Esto funciona para casi cualquier concepto, de hecho, al menos para mí: encuentra el lenguaje que encarna más puramente el concepto que quieres aprender y simplemente úsalo.

OO finalmente hizo clic para mí después de que intenté programar un programa similar a un banco que manejaba transacciones, calculaba intereses y realizaba un seguimiento de todo. Lo hice mientras estaba aprendiendo Java. Sugeriría simplemente intentarlo, completarlo, y luego, cuando haya terminado, busque una BUENA solución y vea qué podría haber hecho mejor.

También creo que las habilidades de OOP se fortalecen principalmente con la práctica. Considere cambiar su empresa, si ha estado allí por más de 3 años. Ciertamente, esto no es válido para todos los trabajos, pero muchas veces un hombre se acostumbra a los proyectos y prácticas de una empresa y deja de avanzar con el paso del tiempo.

¡Arremángate y codifica!

Tú mismo dijiste la respuesta: practica. La mejor solución para esto es desarrollar un juego. Utilice los conceptos que aprendió en los libros.

¿Ha leído el capítulo sobre OO de la primera edición del libro "Effective C ++" de Scott Meyers? No llegó a ediciones posteriores, pero fue una gran explicación. El título era básicamente "diga lo que quiere decir, diga lo que dice" sobre convenciones adecuadas.

En realidad, le gustaría ver mi respuesta a una pregunta similar aquí .

HTH

salud,

Planifica las cosas. Pregúntese cómo quiere que sus objetos se relacionen entre sí y averigüe cómo se pueden cambiar y modularizar las cosas.

Codifique las cosas de tal manera que si desea cambiar 1 parte del código, solo tiene que cambiar esa 1 parte del código y no 50 instancias de él.

OOP no es algo que puedas dominar leyendo miles de libros. Más bien tienes que sentir los conceptos internos. Lea cualquier cosa, pero trate de sentir lo que lee. Construya un concepto en el fondo de su mente e intente igualar esos conceptos cuando se enfrente a un nuevo escenario. Verifique y actualice sus conceptos a medida que explora cosas nuevas.

¡Buena suerte!

la cerveza ayuda. seriamente. Acuéstese en un sofá con un bloc de notas de tamaño A3, un bolígrafo y una cerveza. Cierre al 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 demasiada) ayudan mucho.

La forma más fácil de refactorizar el código es no tener que hacerlo en primer lugar.

http://misko.hevery.com/code-reviewers-guide/

Esas pequeñas reglas simples te convertirán en un mejor programador de OO. Siga las reglas religiosamente mientras codifica y encontrará que su código es mejor de lo que sería de otra manera.

También querrá aprender los principios sólidos: http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod

Por mucho que estos principios y formas de programación provoquen debate, son la única forma de escribir realmente un código excelente.

Puede que ya escribas código de esta manera y no lo sepas; de ser así, genial. Pero si necesita un objetivo por el que esforzarse, este es el estándar de oro.

¡Rendirse! ¿Por qué necesitas ese OOP? Solo escribe una aplicación útil. No se mide usando OOP, procedimiento o enfoque funcional.

Cualquiera que sea el enfoque que elija, el lenguaje Python debería ser adecuado para practicarlo.

Eres mi público objetivo. Observe la construcción de habilidades en el diseño orientado a objetos

Quizás esto pueda ayudar.