¿Cuál es el punto de la programación orientada a objetos?

Question

Hasta donde puedo decir, a pesar de los innumerables millones o miles de millones gastados en educación, lenguajes y herramientas de programación orientada a objetos, la programación orientada a objetos no ha mejorado la productividad de los desarrolladores ni la confiabilidad del software, ni ha reducido los costos de desarrollo.Pocas personas utilizan la programación orientada a objetos en un sentido riguroso (pocas personas se adhieren o comprenden principios como el LSP);Parece haber poca uniformidad o coherencia en los enfoques que la gente adopta para modelar los dominios de los problemas.Con demasiada frecuencia, la clase se utiliza simplemente por su azúcar sintáctica;coloca las funciones para un tipo de registro en su propio pequeño espacio de nombres.

He escrito una gran cantidad de código para una amplia variedad de aplicaciones.Aunque ha habido lugares donde los verdaderos subtipos sustituibles desempeñaron un papel valioso en la aplicación, estos han sido bastante excepcionales.En general, aunque se habla mucho de "reutilización", la realidad es que, a menos que un fragmento de código funcione exactamente lo que usted quiere que haga, hay muy poca "reutilización" rentable.Es extremadamente difícil diseñar clases para que sean extensibles. En el camino correcto, por lo que el costo de la extensión es normalmente tan grande que simplemente no vale la pena "reutilizarlo".

En muchos aspectos, esto no me sorprende.El mundo real no es "OO", y la idea implícita en OO (que podemos modelar cosas con alguna taxonomía de clases) me parece fundamentalmente defectuosa (puedo sentarme en una mesa, en el tocón de un árbol, en el capó de un auto). , el regazo de alguien (pero ninguno de esos es una silla).Incluso si pasamos a dominios más abstractos, el modelado OO suele ser difícil, contrario a la intuición y, en última instancia, inútil (considérese los ejemplos clásicos de círculos/elipses o cuadrados/rectángulos).

Entonces, ¿qué me estoy perdiendo aquí?¿Dónde está el valor de la programación orientada a objetos y por qué todo el tiempo y el dinero no han logrado mejorar el software?

Answer 1

No hay evidencia empírica que sugiera que la orientación a objetos sea una forma más natural para que las personas piensen sobre el mundo.Hay algunos trabajos en el campo de la psicología de la programación que muestran que la OO no es de alguna manera más adecuada que otros enfoques.

Las representaciones orientadas a objetos no parecen ser universalmente más o menos utilizables.

No basta simplemente con adoptar métodos OO y exigir a los desarrolladores que los utilicen, porque eso podría tener un impacto negativo en la productividad de los desarrolladores, así como en la calidad de los sistemas desarrollados.

Que es de "Sobre la usabilidad de las representaciones OO" de Communications of the ACM Oct.2000.Los artículos comparan principalmente la OO con el enfoque orientado a procesos.Hay muchos estudios sobre cómo "piensan" las personas que trabajan con el método OO (Int.J.of Human-Computer Studies 2001, número 54, o Human-Computer Interaction 1995, vol.10 tiene todo un tema sobre estudios de OO), y por lo que leí, no hay nada que indique algún tipo de naturalidad en el enfoque de OO que lo haga más adecuado que un enfoque de procedimiento más tradicional.

Answer 2

El mundo real no es "OO", y la idea implícita en OO (que podemos modelar cosas con alguna taxonomía de clases) me parece fundamentalmente defectuosa.

Si bien esto es cierto y ha sido observado por otras personas (por ejemplo, Stepanov, inventor del STL), el resto son tonterías.La programación orientada a objetos puede tener fallas y ciertamente no es una solución milagrosa, pero simplifica mucho las aplicaciones a gran escala porque es una excelente manera de reducir las dependencias.Por supuesto, esto sólo es cierto para el "buen" diseño de programación orientada a objetos.Un diseño descuidado no dará ninguna ventaja.Pero un buen diseño desacoplado se puede modelar muy bien usando programación orientada a objetos y no bien usando otras técnicas.

Hay modelos mucho mejores y más universales (Modelo tipo de Haskell (me viene a la mente), pero también suelen ser más complicados y/o difíciles de implementar de manera eficiente.La programación orientada a objetos es una buena compensación entre extremos.

Answer 3

La programación orientada a objetos no se trata de crear clases reutilizables, se trata de crear clases utilizables.

Answer 4

Con demasiada frecuencia, la clase se usa simplemente para su azúcar sintáctica;Pone las funciones para un tipo de registro en su propio pequeño espacio de nombres.

Sí, creo que esto también es demasiado frecuente.Esto no es programación orientada a objetos.Es programación basada en objetos y programación centrada en datos.En mis 10 años de trabajo con lenguajes OO, veo gente principalmente haciendo programación basada en objetos.OBP se descompone muy rápidamente en mi humilde opinión, ya que básicamente estás obteniendo lo peor de ambas palabras:1) Programación procesal sin adherirse a una metodología de programación estructurada probada y 2) POO sin adherirse a una metodología de programación estructurada probada.

La programación orientada a objetos bien hecha es algo hermoso.Hace que problemas muy difíciles sean fáciles de resolver y, para los no iniciados (sin tratar de parecer pomposos), casi puede parecer magia.Dicho esto, la POO es sólo una herramienta en la caja de herramientas de las metodologías de programación.No es la metodología definitiva.Resulta que se adapta bien a las aplicaciones de grandes empresas.

La mayoría de los desarrolladores que trabajan en lenguajes de programación orientada a objetos utilizan ejemplos de programación orientada a objetos realizados correctamente en los marcos y tipos que utilizan a diario, pero simplemente no son conscientes de ello.A continuación se muestran algunos ejemplos muy sencillos:ADO.NET, Hibernate/NHibernate, Logging Frameworks, varios tipos de colecciones de lenguajes, la pila ASP.NET, la pila JSP, etc.Todas estas son cosas que dependen en gran medida de la programación orientada a objetos en sus bases de código.

Answer 5

La reutilización no debería ser un objetivo de la programación orientada a objetos, ni de ningún otro paradigma.

La reutilización es un efecto secundario de un buen diseño y un nivel adecuado de abstracción.El código logra la reutilización haciendo algo útil, pero sin hacer tanto que lo vuelva inflexible.No importa si el código es OO o no: reutilizamos lo que funciona y no es trivial hacerlo nosotros mismos.Eso es pragmatismo.

La idea de OO como una nueva forma de llegar a la reutilización a través de la herencia es fundamentalmente errónea.Como observará, abundan las violaciones del LSP.En cambio, la OO se considera propiamente un método para gestionar la complejidad de un dominio problemático.El objetivo es la mantenibilidad de un sistema a lo largo del tiempo.La herramienta principal para lograr esto es la separación de la interfaz pública de una implementación privada.Esto nos permite que el compilador aplique reglas como "Esto solo debe modificarse usando ...", en lugar de la revisión del código.

Estoy seguro de que estará de acuerdo con que utilizar esto nos permite crear y mantener sistemas enormemente complejos.Hay mucho valor en eso y no es fácil de lograr en otros paradigmas.

Answer 6

Casi religioso, pero yo diría que estás pintando un panorama demasiado sombrío del estado de la programación orientada a objetos moderna.Yo diría que en realidad tiene redujeron costos, hicieron manejables grandes proyectos de software, etc.Eso no significa que haya resuelto el problema fundamental del desorden del software, y no significa que el desarrollador promedio sea un experto en programación orientada a objetos.Pero la modularización de funciones en componentes-objetos ciertamente ha reducido la cantidad de código espagueti que existe en el mundo.

Se me ocurren docenas de bibliotecas que son maravillosamente reutilizables y que han ahorrado tiempo y dinero que nunca podrán calcularse.

Pero en la medida en que la programación orientada a objetos ha sido una pérdida de tiempo, yo diría que se debe a la falta de capacitación de los programadores, agravada por la pronunciada curva de aprendizaje que implica aprender un mapeo de programación orientada a objetos específico del lenguaje.Algunas personas "obtienen" la programación orientada a objetos y otras nunca lo harán.

Answer 7

Creo que el uso de objetos de contexto opacos (HANDLE en Win32, FILE*s en C, por nombrar dos ejemplos bien conocidos; diablos, los HANDLE viven al otro lado de la barrera del modo kernel, y realmente no se mucho más encapsulado que eso) también se encuentra en el código de procedimiento;Me cuesta ver cómo esto es algo particular de la programación orientada a objetos.

HANDLEs (y el resto de WinAPI) es ¡Uy!C no soporta muy bien la programación orientada a objetos, por lo que no hay una sintaxis especial, pero eso no significa que no utilice los mismos conceptos.WinAPI es, en todos los sentidos de la palabra, un marco orientado a objetos.

Mira, este es el problema con cada discusión que involucra programación orientada a objetos o técnicas alternativas:nadie tiene clara la definición, todo el mundo habla de otra cosa y por tanto no se puede llegar a un consenso.Me parece una pérdida de tiempo.

Answer 8

Es un paradigma de programación.Diseñado para que a nosotros, los simples mortales, nos resulte más fácil dividir un problema en partes más pequeñas y viables.

Si no lo encuentras útil..No lo uses, no pagues por entrenar y sé feliz.

Por otro lado, lo encuentro útil, así que lo haré :)

Answer 9

En relación con la programación procedimental directa, el primer principio fundamental de la programación orientada a objetos es la noción de ocultación y encapsulación de información.Esta idea conduce a la noción de clase que separa la interfaz de la implementación.Estos son conceptos enormemente importantes y la base para establecer un marco para pensar en el diseño de programas de una manera diferente y mejor (creo).Realmente no se puede argumentar en contra de esas propiedades: no se hace ninguna compensación y siempre es una forma más limpia de modular las cosas.

Otros aspectos de la programación orientada a objetos, incluida la herencia y el polimorfismo, también son importantes, pero como otros han aludido, comúnmente se usan en exceso.es decir:A veces las personas usan la herencia y/o el polimorfismo porque pueden, no porque deberían hacerlo.Son conceptos poderosos y muy útiles, pero deben usarse sabiamente y no son ventajas ganadoras automáticas de la programación orientada a objetos.

Relativo a la reutilización.Acepto que la reutilización se vende en exceso para OOP.Es un posible efecto secundario de objetos bien definidos, típicamente de clases más primitivas/genéricas y es un resultado directo de los conceptos de encapsulación y ocultación de información.Es potencialmente más fácil reutilizarlo porque las interfaces de clases bien definidas son simplemente más claras y en cierto modo autodocumentadas.

Answer 10

El problema con la programación orientada a objetos es que estaba sobrevendido.

Tal como Alan Kay lo concibió originalmente, era una gran alternativa a la práctica anterior de tener datos sin procesar y rutinas globales.

Luego, algunos tipos de consultores de gestión se aferraron a él y lo vendieron como el mesías del software, y la academia y la industria, como si fueran lemmings, lo siguieron.

Ahora están dando tumbos como lemmings tras la sobreventa de otras buenas ideas, como la programación funcional.

Entonces, ¿qué haría diferente?Mucho, y escribí un libro sobre esto.(Está agotado; no recibo ni un centavo, pero aún puedes conseguir copias).Amazonas

Mi respuesta constructiva es considerar la programación no como una forma de modelar cosas en el mundo real, sino como una forma de codificar requisitos.

Eso es muy diferente y se basa en la teoría de la información (a un nivel que cualquiera puede entender).Dice que la programación puede verse como un proceso de definición de lenguajes, y la habilidad para hacerlo es esencial para una buena programación.

Eleva el concepto de lenguajes de dominio específico (DSL).Concuerda rotundamente con DRY (no te repitas).Le da un gran visto bueno a la generación de código.Esto da como resultado un software con una estructura de datos enormemente menor que la típica de las aplicaciones modernas.

Busca revitalizar la idea de que el camino a seguir pasa por la inventiva y que incluso las ideas bien aceptadas deben cuestionarse.

Answer 11

¡HANDLEs (y el resto de WinAPI) es programación orientada a objetos!

¿Pero lo son?No son heredables, ciertamente no son sustituibles, carecen de clases bien definidas...Creo que están muy por debajo de "OOP".

¿Alguna vez has creado una ventana usando WinAPI?Entonces debes saber que defines una clase (RegisterClass), crea una instancia del mismo (CreateWindow), llamar a métodos virtuales (WndProc) y métodos de clase base (DefWindowProc) etcétera.WinAPI incluso toma la nomenclatura de SmallTalk OOP, llamando a los métodos "mensajes" (mensajes de ventana).

Es posible que los identificadores no sean heredables, pero también hay final en Java.No les falta clase, ellos son un marcador de posición para la clase:Eso es lo que significa la palabra "manejar".Al observar arquitecturas como MFC o .NET WinForms, resulta inmediatamente obvio que, excepto por la sintaxis, no hay mucha diferencia con WinAPI.

Answer 12

Sí, la programación orientada a objetos no resolvió todos nuestros problemas, lo siento.Sin embargo, estamos trabajando en SOA que resolverá todos esos problemas.

Answer 13

La programación orientada a objetos se presta bien para programar estructuras internas de computadoras como "widgets" de GUI, donde, por ejemplo, SelectList y TextBox pueden ser subtipos de Item, que tiene métodos comunes como "mover" y "resize".

El problema es que el 90% de nosotros trabajamos en el mundo de los negocios donde trabajamos con conceptos comerciales como Factura, Empleado, Trabajo, Pedido.Estos no se prestan muy bien a la programación orientada a objetos porque los "objetos" son más nebulosos, sujetos a cambios según la reingeniería empresarial, etc.

El peor de los casos es cuando la OO se aplica con entusiasmo a las bases de datos, incluidas las atroces "mejoras" de OO a las bases de datos SQL, que son correctamente ignoradas excepto por los novatos en las bases de datos que asumen que deben ser la forma correcta de hacer las cosas porque son más nuevas.

Answer 14

En mi experiencia de revisión de código y diseño de proyectos por los que he pasado, el valor de la programación orientada a objetos no se comprende plenamente porque muchos desarrolladores tienen no conceptualizado adecuadamente el modelo orientado a objetos en sus mentes.Por lo tanto, no programan con diseño OO y muy a menudo continúan escribiendo código de procedimiento de arriba hacia abajo, lo que hace que las clases sean bastante bonitas. departamento diseño.(si es que puedes llamarlo "diseño" en primer lugar)

Da bastante miedo observar lo poco que saben los colegas sobre lo que es una clase o interfaz abstracta, y mucho menos diseñar adecuadamente una jerarquía de herencia para satisfacer las necesidades del negocio.

Sin embargo, cuando está presente un buen diseño OO, es pura alegría leer el código y ver cómo el código encaja naturalmente en componentes/clases intuitivos.Siempre he percibido la arquitectura y el diseño de sistemas como el diseño de los distintos departamentos y puestos de trabajo del personal de una empresa: todos están ahí para realizar una determinada tarea en el gran esquema de las cosas, emitiendo la sinergia necesaria para impulsar la organización/sistema hacia adelante.

Eso, por supuesto, es bastante extraño desafortunadamente.Al igual que la proporción entre objetos físicos bellamente diseñados y horrendamente diseñados en el mundo, lo mismo puede decirse de la ingeniería y el diseño de software.Tener buenas herramientas a nuestra disposición no necesariamente confiere buenas prácticas y resultados.

Answer 15

Quizás un capó, un regazo o un árbol no sean una silla, pero todos ellos son ISentables.

Answer 16

Creo que esas cosas del mundo real son objetos.

¿Tú haces?

¿Qué métodos tiene una factura?Oh espera.No puede pagarse a sí mismo, no puede enviarse a sí mismo, no puede compararse con los artículos que el proveedor realmente entregó.No tiene ningún método en absoluto;es totalmente inerte y no funcional.Es un tipo de registro (una estructura, si lo prefiere), no un objeto.

Lo mismo las otras cosas que mencionas.

El hecho de que algo sea real no lo convierte en un objeto en el sentido OO de la palabra.Los objetos OO son una combinación peculiar de estado y comportamiento que pueden actuar por sí solos.Eso no es algo que abunda en el mundo real.

Answer 17

He estado escribiendo código OO durante los últimos 9 años aproximadamente.Aparte de utilizar la mensajería, me resulta difícil imaginar otro enfoque.El principal beneficio lo veo totalmente en línea con lo que dijo CodingTheWheel:modularización.OO naturalmente me lleva a construir mis aplicaciones a partir de componentes modulares que tengan interfaces limpias y responsabilidades claras (es decir,código altamente cohesivo y poco acoplado con una clara separación de preocupaciones).

Creo que donde la OO colapsa es cuando la gente crea jerarquías de clases profundamente anidadas.Esto puede generar complejidad.Sin embargo, tener en cuenta la funcionalidad común en una clase base y luego reutilizarla en otras clases descendientes es algo profundamente elegante, ¡en mi humilde opinión!

Answer 18

En primer lugar, las observaciones son algo descuidadas.No tengo cifras sobre la productividad del software y no tengo ninguna buena razón para creer que no esté aumentando.Además, dado que hay muchas personas que abusan de la OO, un buen uso de la OO no necesariamente causaría una mejora en la productividad, incluso si la OO fuera lo mejor desde la mantequilla de maní.Después de todo, un neurocirujano incompetente probablemente sea peor que ninguno, pero uno competente puede ser invaluable.

Dicho esto, OO es una forma diferente de organizar las cosas, adjuntando código de procedimiento a los datos en lugar de hacer que el código de procedimiento opere sobre los datos.Esto debería ser al menos una pequeña victoria por sí solo, ya que hay casos en los que el enfoque OO es más natural.Después de todo, no hay nada que impida a nadie escribir una API de procedimiento en C++, por lo que la opción de proporcionar objetos hace que el lenguaje sea más versátil.

Además, hay algo que OO hace muy bien:permite que el código antiguo llame al código nuevo automáticamente, sin cambios.Si tengo un código que gestiona las cosas de forma procesal y agrego un nuevo tipo de elemento que es similar pero no idéntico a uno anterior, tengo que cambiar el código de procedimiento.En un sistema OO, heredo la funcionalidad, cambio lo que me gusta y el nuevo código se usa automáticamente debido al polimorfismo.Esto aumenta la localidad de los cambios, y eso es algo bueno.

La desventaja es que una buena OO no es gratuita:se requiere tiempo y esfuerzo para aprenderlo correctamente.Dado que es una palabra de moda, hay muchas personas y productos que lo hacen mal, sólo por hacerlo.No es más fácil diseñar una buena interfaz de clases que una buena API de procedimientos, y hay todo tipo de errores fáciles de cometer (como jerarquías de clases profundas).

Piense en ello como un tipo diferente de herramienta, no necesariamente mejor en general.Un martillo además de un destornillador, digamos.Quizás con el tiempo salgamos de la práctica de la ingeniería de software que consiste en saber qué llave utilizar para clavar el tornillo.

Answer 19

@Sean

Sin embargo, tener en cuenta la funcionalidad común en una clase base y luego reutilizarla en otras clases descendientes es algo profundamente elegante, ¡en mi humilde opinión!

Pero de todos modos los desarrolladores "procedimentales" han estado haciendo eso durante décadas.La sintaxis y la terminología pueden diferir, pero el efecto es idéntico.La programación orientada a objetos es más que "reutilizar la funcionalidad común en una clase base", e incluso podría ir tan lejos como para decir que eso es difícil de describir como programación orientada a objetos;llamar a la misma función desde diferentes bits de código es una técnica tan antigua como el subprocedimiento mismo.

Answer 20

@Konrad

La programación orientada a objetos puede tener fallas y ciertamente no es una solución milagrosa, pero simplifica mucho las aplicaciones a gran escala porque es una excelente manera de reducir las dependencias.

Ese es el dogma.No veo qué hace que la programación orientada a objetos sea significativamente mejor en este sentido que la programación procedimental de antaño.Cada vez que hago una llamada a un procedimiento, me aislo de los detalles de la implementación.

Answer 21

Para mí, hay mucho valor en la propia sintaxis de programación orientada a objetos.Usar objetos que intentan representar cosas reales o estructuras de datos suele ser mucho más útil que intentar usar un montón de funciones planas (o "flotantes") diferentes para hacer lo mismo con los mismos datos.Existe un cierto "flujo" natural para las cosas con buena programación orientada a objetos que simplemente tiene más sentido leer, escribir y mantener a largo plazo.

No necesariamente importa que una Factura no sea realmente un "objeto" con funciones que puede realizar por sí mismo: la instancia del objeto puede existir solo para realizar funciones sobre los datos sin tener que saber qué tipo de datos están realmente allí.La función "invoice.toJson()" se puede llamar correctamente sin tener que saber qué tipo de datos es "invoice"; el resultado será Json, sin importar si proviene de una base de datos, XML, CSV o incluso otro objeto JSON. .Con las funciones de procedimiento, de repente tienes que saber más sobre tus datos y terminas con funciones como "xmlToJson()", "csvToJson()", "dbToJson()", etc.Eventualmente se convierte en un completo desastre y un ENORME dolor de cabeza si alguna vez cambia el tipo de datos subyacente.

El objetivo de la programación orientada a objetos es ocultar la implementación real abstrayéndola.Para lograr ese objetivo, debe crear una interfaz pública.Para facilitar su trabajo al crear esa interfaz pública y mantener las cosas SECO, debe usar conceptos como clases abstractas, herencia, polimorfismo y patrones de diseño.

Entonces, para mí, el verdadero objetivo primordial de la programación orientada a objetos es facilitar el mantenimiento y los cambios futuros del código.Pero incluso más allá de eso, realmente puede simplificar mucho las cosas cuando se hace correctamente de una manera que el código de procedimiento nunca podría hacerlo.No importa si no coincide con el "mundo real": de todos modos, programar con código no interactúa con objetos del mundo real.La programación orientada a objetos es solo una herramienta que hace mi trabajo más fácil y rápido; lo haré en cualquier momento.

Answer 22

@CodificaciónLaRueda

Pero en la medida en que la programación orientada a objetos ha sido una pérdida de tiempo, yo diría que se debe a la falta de capacitación de los programadores, agravada por la pronunciada curva de aprendizaje que implica aprender un mapeo de programación orientada a objetos específico del lenguaje.Algunas personas "obtienen" la programación orientada a objetos y otras nunca lo harán.

Aunque no sé si eso es realmente sorprendente.Creo que los enfoques técnicamente sólidos (el LSP es lo más obvio) hacen que difícil de usar, pero si no utilizamos tales enfoques, el código se vuelve frágil e inextensible de todos modos (porque ya no podemos razonar sobre ello).Y creo que los resultados contrarios a la intuición a los que nos lleva la POO no hacen que sea sorprendente que la gente no la comprenda.

Más importante aún, dado que el software ya es fundamentalmente demasiado difícil para que los humanos normales lo escriban de manera confiable y precisa, ¿deberíamos realmente ensalzar una técnica que constantemente se enseña mal y parece difícil de aprender?Si los beneficios fueran claros entonces podría valer la pena perseverar a pesar de la dificultad, pero no parece ser el caso.

Answer 23

@Jeff

En relación con la programación procedimental directa, el primer principio fundamental de la programación orientada a objetos es la noción de ocultación y encapsulación de información.Esta idea lleva a la noción de clase que separa la interfaz de la implementación.

Que tiene la implementación más oculta:¿Iostreams de C++ o FILE*s de C?

Creo que el uso de objetos de contexto opacos (HANDLE en Win32, FILE*s en C, por nombrar dos ejemplos bien conocidos; diablos, los HANDLE viven al otro lado de la barrera del modo kernel, y realmente no se mucho más encapsulado que eso) también se encuentra en el código de procedimiento;Me cuesta ver cómo esto es algo particular de la programación orientada a objetos.

Supongo que eso puede ser parte de por qué me cuesta ver los beneficios:Las partes que son obviamente buenas no son específicas de la programación orientada a objetos, mientras que las partes que son específicas de la programación orientada a objetos no son obviamente buenas.(Esto no quiere decir que sean necesariamente malos, sino más bien que no he visto evidencia de que sean ampliamente aplicables y consistentemente beneficiosos).

Answer 24

En el único blog de desarrollo que leí, Por ese tipo Joel-On-Software-Fundador-de-SO, leí hace mucho tiempo que la OO no conduce a aumentos de productividad.La gestión automática de la memoria sí lo hace.Fresco.¿Quién puede negar los datos?

Sigo creyendo que OO es para no-OO lo que programar con funciones es programar todo en línea.

(Y debería saberlo, ya que comencé con GWBasic). Cuando refactorizas el código para usar funciones, variable2654 se convierte variable3 del método en el que estás.O, mejor aún, tiene un nombre que puedes entender, y si la función es corta, se llama value y eso es suficiente para una comprensión completa.

Cuando un código sin funciones se convierte en código con métodos, puedes eliminar kilómetros de código.

Cuando refactorizas el código para que sea verdaderamente OO, b, c, q, y Z convertirse this, this, this y this.Y como no creo en usar el this palabra clave, puedes eliminar millas de código.En realidad, puedes hacer eso incluso si usas this.

No creo que OO sea una metáfora natural.

Tampoco creo que el lenguaje sea una metáfora natural, ni creo que los "olores" de Fowler son mejores que decir "este código sabe mal". Dicho esto, creo que OO no se trata de metáforas naturales y personas que piensan los objetos simplemente aparecen ante ti básicamente no entienden el punto. Tú defines el universo de objetos, y los mejores universos de objetos dan como resultado un código más corto, más fácil de entender, que funciona mejor o todo eso (y algunos criterios que estoy olvidando).Creo que las personas que utilizan los objetos naturales de los clientes/dominio como objetos de programación están perdiendo el poder de redefinir el universo.

Por ejemplo, cuando creas un sistema de reservas de aerolíneas, lo que llamas reserva puede no corresponderse en absoluto con una reserva legal o comercial.

Algunos de los conceptos básicos son herramientas realmente interesantes.

Creo que la mayoría de la gente exagera con eso de "cuando tienes un martillo, todos son clavos".Creo que la otra cara de la moneda/espejo es igualmente cierta:cuando tienes un dispositivo como polimorfismo/herencia, comienzas a encontrar usos donde cabe como un guante/calcetín/lentes de contacto.Las herramientas de OO son muy poderosas.Creo que la herencia única es absolutamente necesaria para que la gente no se deje llevar, la mía a pesar del software de herencia múltiple.

¿Cuál es el punto de la programación orientada a objetos?

Creo que es una excelente manera de manejar una base de código absolutamente masiva.Creo que te permite organizar y reorganizar tu código y te brinda un lenguaje para hacerlo (más allá del lenguaje de programación en el que estás trabajando) y modulariza el código de una manera bastante natural y fácil de entender.

La programación orientada a objetos está destinada a ser malinterpretada por la mayoría de los desarrolladores.

Esto se debe a que es un proceso revelador como la vida:Con la experiencia, comprendes cada vez más la OO y empiezas a evitar ciertos patrones y a emplear otros a medida que te vuelves más sabio.Uno de los mejores ejemplos es que dejas de usar la herencia para clases que no controlas y prefieres la Fachada patrón en su lugar.

Respecto a tu mini ensayo/pregunta

Quería mencionar que tienes razón.La reutilización es una quimera, en su mayor parte.Aquí hay una cita de Anders Hejilsberg sobre ese tema (brillante) de aquí:

Si pide a los programadores principiantes que escriban un control de calendario, a menudo piensan para sí mismos: "¡Oh, voy a escribir el mejor control del calendario del mundo!Será polimórfico con respecto al tipo de calendario.Tendrá exhibidores y mungers, y esto, eso y el otro ". Necesitan enviar una aplicación de calendario en dos meses.Pusieron toda esta infraestructura en su lugar en el control, y luego pasan dos días escribiendo una aplicación de calendario de mierda además de ella.Pensarán: "En la próxima versión de la aplicación, voy a hacer mucho más".

Sin embargo, una vez que comienzan a pensar en cómo van a implementar todas estas otras concretizaciones de su diseño abstracto, resulta que su diseño está completamente incorrecto.Y ahora se han pintado en una esquina, y tienen que tirar todo.Lo he visto una y otra vez.Creo firmemente en ser minimalista.A menos que realmente vaya a resolver el problema general, no intente establecer un marco para resolver uno específico, porque no sabe cómo debería ser ese marco.

Answer 25

¿Alguna vez has creado una ventana usando WinAPI?

Más veces de las que me gustaría recordar.

Entonces debes saber que defines una clase (RegisterClass), creas una instancia de ella (CreateWindow), llamas a métodos virtuales (WndProc) y métodos de clase base (DefWindowProc), etc.WinAPI incluso toma la nomenclatura de SmallTalk OOP, llamando a los métodos "mensajes" (mensajes de ventana).

Entonces también sabrás que no envía ningún mensaje por sí solo, lo cual es un gran vacío.También tiene subclases de mierda.

Es posible que los identificadores no sean heredables, pero en Java está el final.No les falta clase, son un marcador de posición para la clase:Eso es lo que significa la palabra "manejar".Al observar arquitecturas como MFC o .NET WinForms, resulta inmediatamente obvio que, excepto por la sintaxis, no hay mucha diferencia con WinAPI.

No son heredables ni en la interfaz ni en la implementación, son mínimamente sustituibles y no son sustancialmente diferentes de lo que los codificadores de procedimientos han estado haciendo desde siempre.

¿Es esto realmente así?Las mejores partes de la programación orientada a objetos son simplemente...¿Código procesal tradicional? Eso es ¿El gran problema?

Answer 26

Estoy completamente de acuerdo con InSciTek Jeffrespuesta, simplemente agregaré las siguientes mejoras:

• Ocultamiento y encapsulación de información:Crítico para cualquier código mantenible.Se puede hacer teniendo cuidado en cualquier lenguaje de programación, no requiere funciones OO, pero hacerlo hará que su código se parezca un poco a OO.
• Herencia:Hay un dominio de aplicación importante para el cual todos esos OO Es un tipo de y contiene una Las relaciones encajan perfectamente:Interfaces gráficas de usuario.Si intenta crear GUI sin soporte de lenguaje OO, terminará creando funciones similares a OO de todos modos, y es más difícil y más propenso a errores sin soporte de lenguaje.Glade (recientemente) y X11 Xt (históricamente), por ejemplo.

Usar características OO (especialmente jerarquías abstractas profundamente anidadas), cuando no tiene sentido, no tiene sentido.Pero para algunos dominios de aplicaciones, realmente tiene sentido.

Answer 27

Creo que la cualidad más beneficiosa de la programación orientada a objetos es la ocultación/gestión de datos.Sin embargo, hay MUCHOS ejemplos en los que se hace mal uso de la programación orientada a objetos y creo que aquí es donde entra la confusión.

Sólo porque puedas convertir algo en un objeto no significa que debas hacerlo.Sin embargo, si hacerlo hará que su código esté más organizado/más fácil de leer, entonces definitivamente debería hacerlo.

Un gran ejemplo práctico donde la programación orientada a objetos es muy útil es con una clase de "producto" y objetos que uso en nuestro sitio web.Dado que cada página es un producto y cada producto tiene referencias a otros productos, puede resultar muy confuso saber a qué producto se refieren los datos que tiene.¿Es esta variable "strURL" el enlace a la página actual, a la página de inicio o a la página de estadísticas?Seguro que podría crear todo tipo de variables diferentes que se refieran a la misma información, pero proCurrentPage->strURL es mucho más fácil de entender (para un desarrollador).

Además, adjuntar funciones a esas páginas es mucho más limpio.Puedo hacer proCurrentPage->CleanCache();Seguido de proDisplayItem->RenderPromo();Si simplemente llamara a esas funciones y hiciera que asumieran que los datos actuales estaban disponibles, quién sabe qué tipo de mal ocurriría.Además, si tuviera que pasar las variables correctas a esas funciones, volvería al problema de tener todo tipo de variables para los diferentes productos por ahí.

En cambio, al utilizar objetos, todos los datos y funciones de mi producto son agradables, limpios y fáciles de entender.

Sin embargo.El gran problema con la POO es cuando alguien cree que TODO debería ser POO.Esto crea muchos problemas.Tengo 88 tablas en mi base de datos.Sólo tengo unas 6 clases, y tal vez debería tener unas 10.Definitivamente no necesito 88 clases.La mayoría de las veces, acceder directamente a esas tablas es perfectamente comprensible en las circunstancias en las que lo uso, y la programación orientada a objetos en realidad haría más difícil/tedioso llegar a la funcionalidad principal de lo que está ocurriendo.

Creo que un modelo híbrido de objetos útiles y de procedimiento práctico es el método de codificación más eficaz.Es una pena que tengamos todas estas guerras religiosas en las que la gente defiende el uso de un método a expensas de los demás.Ambos son buenos y ambos tienen su lugar.La mayoría de las veces, ambos métodos tienen usos en cada proyecto más grande (en algunos proyectos más pequeños, un solo objeto o algunos procedimientos pueden ser todo lo que necesita).

Answer 28

No me importa tanto la reutilización como la legibilidad.Esto último significa que su código es más fácil de cambiar.Sólo eso vale oro en el oficio de crear software.

Y OO es una forma bastante eficaz de hacer que sus programas sean legibles.Reutilizar o no reutilizar.

Answer 29

"El mundo real no es "OO","

¿En realidad?Mi mundo está lleno de objetos.Estoy usando uno ahora.Creo que tener "objetos" de software que modelen los objetos reales podría no ser tan malo.

Los diseños OO para cosas conceptuales (como Windows, no ventanas del mundo real, sino los paneles de visualización del monitor de mi computadora) a menudo dejan mucho que desear.Pero para cosas del mundo real como facturas, pedidos de envío, reclamos de seguros y demás, creo que esas cosas del mundo real son objetos.Tengo una pila en mi escritorio, así que deben ser reales.

Answer 30

El objetivo de la programación orientada a objetos es brindarle al programador otro medio para describir y comunicar una solución a un problema en código a máquinas y personas.La parte más importante de eso es la comunicación con las personas.La programación orientada a objetos permite al programador declarar lo que quieren decir en el código a través de reglas que se aplican en el lenguaje OO.

Contrariamente a muchos argumentos sobre este tema, la POO y los conceptos OO están omnipresentes en todo el código, incluido el código en lenguajes que no son POO, como C.Muchos programadores avanzados que no son OO aproximarán las características de los objetos incluso en lenguajes que no son OO.

Tener OO integrado en el lenguaje simplemente le da al programador otro medio de expresión.

La parte más importante de escribir código no es la comunicación con la máquina, esa parte es fácil, la parte más importante es la comunicación con los programadores humanos.