Pregunta

Recientemente tuve una discusión con un colega que no es un fan de POO . Lo que me llamó la atención fue lo que dijo:

"¿Cuál es el punto de hacer mi codificación de objetos? Si se trata de reutilizar entonces puedo simplemente crear una biblioteca y llamar a cualquier función que necesito para cualquier tarea que está a la mano. ¿Necesito estos conceptos de polimorfismo, herencia, interfaces, patrones o lo que sea? "

Estamos en una pequeña empresa de desarrollo de proyectos para pequeños sitios de comercio electrónico y los bienes raíces.

¿Cómo puedo tomar ventaja de programación orientada a objetos en un "todos los días, en el mundo real" configuración? O se POO realmente para resolver problemas complejos y no se destinen a "todos los días" desarrollo?

¿Fue útil?

Solución

Las cosas buenas de programación orientada a objetos provienen de atar un conjunto de datos a un conjunto de comportamientos.

Por lo tanto, si usted tiene que hacer muchas operaciones relacionadas en un conjunto relacionado de datos, puede escribir varias funciones que operan sobre una estructura, o puede utilizar un objeto.

Los objetos que dan un poco de ayuda reutilización de código en la forma de herencia.

IME, es más fácil trabajar con un objeto con un conjunto conocido de atributos y métodos que es para mantener un conjunto de estructuras complejas y las funciones que operan sobre ellos.

Algunas personas seguir sobre la herencia y polimorfismo. Estos son valiosos, pero el valor real en la programación orientada a objetos (en mi opinión) proviene de la forma agradable que encapsula y datos asociados con los comportamientos.

En caso de utilizar programación orientada a objetos en sus proyectos? Eso depende de qué tan bien su lenguaje soporta programación orientada a objetos. Eso depende de los tipos de problemas que hay que resolver.

Sin embargo, si usted está haciendo pequeños sitios web, usted todavía está hablando lo suficiente complejidad que iba a utilizar el diseño POO dado un apoyo adecuado en el lenguaje de desarrollo.

Otros consejos

Mi personalmente Vista: contexto

Cuando se programa en la programación orientada a objetos que tienen una mayor conciencia del contexto. Se le ayuda a organizar el código de tal manera que es más fácil de entender porque el mundo real también está orientado a objetos.

Más de conseguir algo que sólo el trabajo - el punto de su amigo, un diseño orientado a objetos bien diseñado es fácil de entender, para seguir, para ampliar, extender y poner en práctica. Es mucho más fácil, por ejemplo, para delegar trabajo que categóricamente son similares o para recoger datos que deben permanecer juntos (sí, incluso una estructura C es un objeto).

Bien, estoy seguro de que mucha gente va a dar mucho más académicamente responde correctamente, pero aquí está mi opinión sobre algunas de las ventajas más valiosas:

  • POO permite una mejor encapsulación
  • POO permite al programador a pensar en términos más lógicas, por lo que los proyectos de software más fácil de diseñar y entender (si están bien diseñados)
  • programación orientada a objetos es un ahorro de tiempo. Por ejemplo, mira las cosas que puede hacer con un objeto de cadena C ++, vectores, etc. Todo lo que la funcionalidad (y mucho más) viene de "libre". Ahora, esos son muy características de las bibliotecas de clases y no oop sí, pero casi todas las implementaciones de programación orientada a objetos vienen con bibliotecas de clases agradables. Se puede poner en práctica todas esas cosas en C (o la mayor parte de ella)? Seguro. Pero ¿por qué escribir usted mismo?

Mira el uso de patrones de diseño y verá la utilidad de la programación orientada a objetos. No se trata sólo de encapsulación y la reutilización, pero extensibilidad y mantenibilidad. Es las interfaces que hacen cosas de gran alcance.

A algunos ejemplos:

  • La implementación de una corriente (Decorator) sin objetos es difícil

  • Adición de una nueva operación a un sistema existente, tal como un (patrón de estrategia) nuevo tipo de cifrado puede ser difícil sin objetos.

  • Mira la forma en PostgreSQL es implementado en comparación con la forma en que su libro de la base de datos dice una base de datos debe ser implementado y verá un gran diferencia. El libro sugerirá nodo de objetos para cada operador. Postgres utiliza tablas y una miríada macros para tratar de emular a estos nodos. Es mucho menos bonita y mucho más difícil se extienden debido a eso.

La lista es interminable.

El poder de la mayoría de los lenguajes de programación se encuentra en las abstracciones que ponen a disposición. la programación orientada a objetos proporciona un poderoso sistema de abstracciones de la manera que le permite gestionar las relaciones entre las ideas o acciones relacionadas.

Tenga en cuenta la tarea de calcular áreas para una arbitraria y creciente colección de formas. Cualquier programador puede escribir rápidamente las funciones que para el área de un círculo, cuadrado, triángulo, ect. y almacenarlos en una biblioteca. La dificultad viene cuando se trata de escribir un programa que identifica y calcula el área de una forma arbitraria. Cada vez que añada un nuevo tipo de forma, por ejemplo un pentágono, lo que se necesita para actualizar y extender algo así como una estructura IF o CASE para permitir que su programa para identificar la nueva forma y llamar a la rutina área correcta de su "biblioteca de funciones" . Después de un tiempo, los costos de mantenimiento asociados con este enfoque comienzan a acumularse.

Con la programación orientada a objetos, mucho de esto viene libre-- simplemente definir una clase Shape que contiene un método de área. Entonces realmente no importa lo que la forma específica que está tratando con en tiempo de ejecución, basta con cada figura geométrica de un objeto que hereda de forma y llamar al método del área. El paradigma orientado a objetos se encarga de los detalles de si en este momento en el tiempo, con esta entrada del usuario, qué necesitamos para calcular el área de un círculo, triángulo, cuadrado, pentágono o la opción de elipse que acaba de ser agregada hace más de medio minuto.

¿Qué pasa si usted decidió cambiar la interfaz detrás de la forma en que la función de zona se llamaba? Con la programación orientada a objetos que le acaba de actualizar la clase Shape y los cambios automagicamente propagar a todas las entidades que heredan de esa clase. Con un sistema orientado a objetos que no tendría que hacer frente a la tarea de penosamente a través de su "biblioteca de funciones" y la actualización de cada interfaz individual.

En resumen, la programación orientada a objetos proporciona una poderosa forma de abstracción que le puede ahorrar tiempo y esfuerzo mediante la eliminación de la repetición en el código y la racionalización de las extensiones y mantenimiento.

Todos los paradigmas de programación tienen el mismo objetivo: ocultar la complejidad innecesaria.

Algunos problemas se resuelven fácilmente con un paradigma imperativo, como utiliza su amigo. Otros problemas se resuelven fácilmente con un paradigma orientado a objetos. Hay muchos otros paradigmas . Los principales (programación lógica, programación funcional y programación imperativa) son equivalentes entre sí; programación orientada a objetos se suele considerar como una extensión de la programación imperativa.

Programación orientada a objetos se utiliza mejor cuando el programador es el modelado de objetos que son similares, pero no iguales. Un paradigma imperativo pondría a los diferentes tipos de modelos en una sola función. Un paradigma orientado a objetos separa los diferentes tipos de modelos en diferentes métodos en objetos relacionados.

Su colega parece estar atrapado en un paradigma. Buena suerte.

Alrededor de 1994 yo estaba tratando de hacer sentido de la programación orientada a objetos y C ++, al mismo tiempo, y me encontré frustrado, a pesar de que podía entender lo que en principio era el valor de la programación orientada a objetos. Estaba tan acostumbrada a ser capaz de meterse con el estado de cualquier parte de la aplicación de otras lenguas (idiomas básicos en su mayoría, de la Asamblea, y Pascal-familiares) que parecía como si estuviera renunciando a la productividad en favor de una abstracción académica. Desafortunadamente, mis primeros encuentros con los marcos OO como MFC hacen que sea más fácil de hackear, pero no necesariamente ofrecen mucho en el camino de la iluminación.

Fue sólo a través de una combinación de persistencia, la exposición a la alternativa (no C ++) maneras de tratar con objetos, y análisis cuidadoso de código OO que tanto 1) funcionó y 2) leer más coherente y intuitivamente que el código de procedimiento equivalente que empecé a ser realmente ella. Y 15 años más tarde, estoy regularmente sorprendido por nueva (para mí) descubrimientos de soluciones inteligentes OO, pero impresionantemente simples que no puedo imaginar haciendo tan limpiamente en un enfoque de procedimiento.

He estado yendo a través de la misma serie de luchas que tratan de dar sentido a la paradigma de programación funcional en el último par de años. Parafraseando a Paul Graham, cuando se está mirando hacia abajo el continuo de energía, se ve todo lo que le falta. Cuando usted está buscando el continuo de energía, que no se ve el poder, que acaba de ver rarezas.

Creo que, con el fin de comprometerse a hacer algo de una manera diferente, usted tiene que 1) ver a alguien, obviamente, ser más productivo con construcciones más potentes y 2) suspender la incredulidad cuando usted se encuentra golpear una pared. Es probable que ayuda a tener un mentor que es al menos un poquito más adelante en su comprensión del nuevo paradigma, también.

A menos que el coraje necesario para suspender la incredulidad, si desea que alguien asimilar rápidamente el valor de un modelo orientado a objetos, creo que se podría hacer mucho peor que preguntar a alguien para pasar una semana con el libro programadores pragmáticos sobre rieles. Desafortunadamente hace dejar de lado muchos de los detalles de cómo funciona la magia, pero es una muy buena introducción a la potencia de un sistema de abstracciones OO. Si, después de trabajar a través de ese libro, su colega todavía no ve el valor de OO, por alguna razón, él / ella puede ser un caso perdido. Pero si están dispuestos a pasar un poco de tiempo de trabajo con un enfoque que tiene un diseño orientado a objetos muy obstinado que funciona, y los sufran de 0-60 mucho más rápido que hacer lo mismo en un lenguaje de procedimientos, puede ser sólo la esperanza. Creo que eso es cierto incluso si su trabajo no implica el desarrollo web.

No estoy tan seguro de que la educación de la "mundo real" sería tanto un punto de venta como un marco de trabajo para escribir buenas aplicaciones, porque resulta que, especialmente en lenguas tipos estáticos como C # y Java, el modelado el mundo real requiere a menudo abstracciones tortuosas. Se puede ver un ejemplo concreto de la dificultad de modelar el mundo real examinado miles de personas que luchan para modelar algo tan aparentemente simple como la abstracción geométrica de la "forma" (forma, elipse, círculo).

Para mí, el poder de la programación orientada a objetos no muestra en sí hasta que se empieza a hablar de la herencia y polimorfismo.

Si el argumento de uno de programación orientada a objetos se basa el concepto de encapsulación y la abstracción, así que no es un argumento muy convincente para mí. Puedo escribir una biblioteca enorme y sólo documentar las interfaces con lo que yo quiero que el usuario sea consciente de, o puedo confiar en construcciones a nivel de lenguaje como paquetes en Ada para hacer campos privados y solo exponer qué es lo que quiero exponer.

Sin embargo, la ventaja real viene cuando he código en una jerarquía genérica escrito para que pueda ser reutilizado después de tal manera que las mismas interfaces de código exacto se utilizan para la funcionalidad diferente para lograr el mismo resultado.

¿Por qué es útil? Porque puedo estar parado en los hombros de gigantes para cumplir mi tarea actual. La idea es que puedo hervir las partes de un problema hasta las partes más básicas, los objetos que componen los objetos que lo componen ... los objetos que componen el proyecto. Mediante el uso de una clase que define un comportamiento muy bien en el caso general, puedo usar el mismo código de construir una versión más específica de la misma cosa, y luego una versión más específica de la misma cosa, y luego todavía una aún más específica versión de la misma cosa. La clave es que cada una de estas entidades tiene en común que ya ha sido codificado y probado, y no hay necesidad de reimpliment de nuevo más tarde. Si yo no uso herencia para esto, me acaban de reimplementar la funcionalidad común o explícitamente la vinculación de mi nuevo código con el código antiguo, que proporciona un escenario para mí presentar errores de flujo de control.

polimorfismo es muy útil en casos en los que necesito para lograr una cierta funcionalidad de un objeto, pero la misma funcionalidad se necesita también de similar, pero tipos únicos. Por ejemplo, en Qt, existe la idea de insertar elementos en un modelo para que los datos se pueden mostrar y se puede mantener fácilmente los metadatos para ese objeto. Sin polimorfismo, que tendría que molestar a mí mismo con mucho más detalle de lo que actualmente hacer MARCAS (que tendría que aplicar las mismas interfaces de código que realizan la misma lógica de negocio como el elemento que inicialmente estaba destinado a ir en el modelo). Debido a que la clase base de mi objeto enlazado a datos interactúa de forma nativa con el modelo, puedo insertar metadatos lugar en este modelo sin ningún problema. Me da lo que necesito fuera del objeto con ninguna preocupación por lo que necesita el modelo, y el modelo consigue lo que necesita con ninguna preocupación por lo que he añadido a la clase.

Consulte a su amigo para visualizar cualquier objeto en su misma habitación, casa o ciudad ... y si él puede decir un solo objeto tal cual un sistema en sí mismo y es capaz de hacer un trabajo significativo .
cosas como un botón isnt hacer algo solos - se necesita una gran cantidad de objetos para hacer una llamada telefónica. Del mismo modo
un motor de coche se hace del cigüeñal, pistones, bujías. OOPS conceptos han evolucionado a partir de nuestra percepción de procesos naturales o cosas en nuestras vidas.
El libro "Inside COM" dice el propósito de COM mediante la adopción de la analogía de un juego infantil de la identificación de los animales, haciendo preguntas.

Diseño supera a la tecnología y metodología. Los buenos diseños tienden a incorporar principios universales de la gestión de la complejidad como la Ley de Demeter, que se encuentra en el corazón de lo que las características del lenguaje orientado a objetos se esfuerzan para codificar.

El buen diseño no depende del uso de las características específicas del lenguaje OO aunque es típicamente en Ones mejor interés para usarlos.

No sólo hace

  • la programación más fácil / más fácil de mantener en la situación actual para otras personas (y usted)
  • Ya está permitiendo más fácil CRUD base de datos (crear, actualizar, eliminar) las operaciones.

Puede encontrar más información sobre ella mirando hacia arriba: - Java: Hibernate - Dot Net: Entity Framework

Consulte incluso cómo LINQ (Visual Studio) puede hacer su vida de programación mucho más fácil.

  • También, puede empezar a utilizar patrones de diseño para resolver problemas de la vida real (patrones de diseño son todos acerca OO)

Tal vez sea incluso divertido para demostrar con una pequeña demostración:

  • Digamos que necesita para almacenar los empleados, cuentas, miembros, libros en un archivo de texto de una manera similar.

.PS. He intentado escribir de una manera PSEUDO:)

de la manera OO

Código de llamar: io.file.save (objectsCollection.ourFunctionForSaving ())

objectsCollection clase

función ourFunctionForSaving () As String

Cadena _objetos

   for each _Object in objectsCollection
         Objects &= _Object & "-"
   end for

_objetos retorno fin del método

NO OO Camino

No creo que voy a escribir código abajo no oo. Pero pensar en ello:)

Ahora digamos

En la forma OO. La clase anterior es la clase padre de todos los métodos para guardar los libros, empleados, miembros, cuentas, ... ¿Qué pasa si queremos cambiar la forma de salvar a un archivo de texto? Por ejemplo, para que sea compactable con un estándar actual (.cvs).

Y digamos que nos gustaría añadir una función de carga, la cantidad de código es lo que necesita para escribir? En el camino OO- sólo es necesario el añadir un nuevo método Sub que puede dividir todos los datos en los parámetros (Esto sucede una vez).

Deje que su colega pensar en eso:)

En los dominios donde estado y el comportamiento están mal alineados, orientación a objetos reduce la densidad total de dependencia (complejidad es decir) dentro de estos dominios, lo que hace que los sistemas resultantes menos frágil.

Esto es porque el esencia de la orientación a objetos se basa en el hecho de que, organizativamente, no dustinguish entre el estado y el comportamiento en absoluto, el tratamiento tanto de uniforme como "características". Los objetos son simplemente conjuntos de características clumpled para minimizar general dependencia.

En otros dominios, orientación a objetos no es el mejor enfoque. Hay diferentes paradigmas de idiomas para diferentes problemas. desarrolladores experimentados saben esto, y están dispuestos a utilizar cualquier idioma está más cerca del dominio.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top