¿Cuál es la mejor manera de entender OOP?

Answer 1

Se trata de cómo se usan las cosas, no de las cosas. Una pieza de código que utiliza una cosa debe saber lo menos posible sobre ella para que funcione. Si esta situación existe, entonces la cosa debería ser un objeto.

Para un ejemplo extremadamente simple, supongamos que hay un conjunto de botones. Estos botones no son todos del mismo tipo de cosas, pero hay más de cien lugares diferentes en su código que necesitan introducir un botón de algún tipo y cientos de otros lugares en su código que necesitan presionar un botón que se pasa dependiendo de ciertas condiciones. Entonces, primero tenemos un botón entero que para activarlo debe darle un valor entero mayor que 4. Luego tiene otro botón, el botón bool que toma solo un verdadero booleano para activarlo. Luego hay un tercer botón, que tiene que llamarlo, el que establece un valor de texto en su lado y luego lo vuelve a llamar. Puede haber una docena de diferentes tipos de botones como este.

Entonces, ¿qué es lo que ahora haces? ¿Cientos de lugares diferentes en el código necesitan saber cómo activar cada tipo diferente de botón? ¡No! Este es un trabajo para OOP. Si tiene una clase de botón llamada “Botón” con un método virtual: “Activar” y cada tipo de botón se hereda de Botón e implementa Activar, entonces todos los botones se pueden pasar, no importa qué tipo son como una simple referencia o puntero. Botón y cuando sea el momento de activar el botón, todas las partes diferentes de su código hacen exactamente lo mismo, llame a Activate (); esta técnica se llama ocultación de información y es la cosa más poderosa sobre la POO. El 99% de su código solo necesita saber acerca de la clase Button y Button :: Activate ();

Supongamos que no usó OOP y que simplemente escribió todo este conocimiento para que en todas partes de su código haya varias declaraciones de interruptores que determinen cómo activar el botón en cuestión. En primer lugar, piense en la posibilidad de errores, el conocimiento de los botones se copia y se pega en su código, los errores se copian y se pegan en su código. Entonces alguien dice: hey, necesitamos agregar seis botones más y cambiar la forma en que funcionan los otros tres. Recuerda que este es un ejemplo simple. Sin la POO y la ocultación de la información, se deben reescribir con mayor frecuencia grandes cantidades de código.

OOP proporciona una forma de hacer un contrato con el 99% del código que no tendrá que cambiar aunque se introduzcan cosas completamente nuevas que siguen el contrato. Los lenguajes OOP como Java C ++, C #, etc. hacen buenos contratos herméticos.

Answer 2

A2A.

Pero, ¿significan, literalmente, todos los objetos (botones, listas, ventanas, imágenes, etc.)?

Esa es la idea. Hay algunas implementaciones que llevan esto más lejos que otras. Por ejemplo, en Smalltalk, la implementación clásica de OOP, hay algunas cosas que no son objetos: encabezados de métodos, variables (que son solo marcadores de posición para objetos), operadores, varios delimitadores y modificadores, y 6 palabras clave. Todo lo demás es un objeto, incluyendo clases, numéricos, caracteres, coordenadas, y literales de cadena, y símbolos. Ciertamente, se incluirían elementos de nivel superior, como botones, listas, ventanas e imágenes. Por lo que sé, la mayoría de las API de UI modernas tienen botones, listas, ventanas e imágenes como objetos. No tienes que ir muy lejos para encontrar eso.

El Yo del lenguaje va hasta el final, literalmente haciendo que cada cosa que veas un objeto, incluidas las excepciones que enumeré anteriormente para Smalltalk.

La medida en que podrá hacer esto podría estar limitada por el entorno de desarrollo que está utilizando, a menos que esté pensando en crear un nuevo idioma / entorno.

Escribí la respuesta de Mark Miller a ¿Cuál es la definición de Alan Kay de Orientación a objetos ?, lo que podría ser útil. Vea la respuesta de Alan Kay a ¿Cuál es la definición de Alan Kay de Orientación a objetos? también.

Creo que una forma más adecuada de abordar cualquier proyecto es ver qué arquitectura es la que mejor apoya lo que usted quiere hacer. OO no es la solución para todo.

Answer 3

Al tratar con la POO, sea lo que sea lo que esté haciendo, se espera que lo haga con el objeto. Pero mientras que viene en Java como lenguaje, no puedes hacer cosas siempre con objetos. Deberíamos tener que hacer uso de tipos de datos premitivos también.

Así que depende de la tecnología que estemos usando.

Answer 4

¡Entendiendo tu entorno!

¿Qué quiero decir con esto?
Ah, bueno, es necesario tener una idea clara de distinguir entre un objeto y el nombre que asociamos al objeto.

Los objetos son aquello con lo que podemos “interactuar” en cierto sentido. Y sus nombres son generalizaciones de lo que es. Al igual que Maruti 800, tener una placa número 8134 es un verdadero objeto “CAR”. ¡Así que todos los autos con placa son objetos de la vida real! CAR es la clase que define todos los coches objeto.
Ahora, la metodología de programación es tratar cómo un objeto de automóvil interactúa con una palabra real. Proporcionamos estos comportamientos de objetos de coche, funciones como RunningOrNot (), FuelConsumptionRate () etc. También necesitamos definir propiedades del coche como what_type_of_fuel_it_consumes, color, licencia, etc.

Sabemos que todo lo que hacemos finalmente se empaqueta en 0s y 1s, por lo que este es solo un paradigma de programación, una abstracción de nivel superior.

Answer 5

Has notado el problema. Algunos lugares los objetos son una bendición. Pero eso no significa que todo deba ser un objeto. Los objetos tienen sus usos, pero también pueden ser excesivamente usados, lo que lleva a la lentitud del código y al aumento de código. Los objetos también se adaptan mal a las cosas que cambian o son indefinidas, como la estructura de una empresa. Por ejemplo, usted pensaría que sería una buena idea tomar el árbol de la compañía de una empresa principal, con subsidiarias y divisiones como objetos con la compañía como la matriz, pero ese suele ser un diseño muy deficiente. Una subsidiaria que en realidad es una sucursal canadiense tiene que seguir diferentes leyes fiscales. Una filial podría ser la sede principal, de nuevo por motivos fiscales. Y esa otra rama está dirigida por el yerno del CEO, de modo que esa rama no informa de la cadena de la misma manera. Y, por supuesto, la organización cambia cada 18 meses, por lo que es un gran trabajo de reprogramación.

Decidir qué objetar y qué no es una decisión difícil.

Answer 6

la mejor manera de entender es mantener la práctica, codificar y encontrar el error y pensar en la salida