language-agnostic - poo - programacion orientada a objetos c++ youtube
¿Cuál es el punto de OOP? (30)
Por lo que puedo decir, a pesar de los incontables millones o miles de millones gastados en educación, lenguajes y herramientas de OOP, OOP no ha mejorado la productividad del desarrollador o la confiabilidad del software, ni ha reducido los costos de desarrollo. Pocas personas usan OOP en ningún sentido riguroso (pocas personas se adhieren o entienden principios como LSP); parece haber poca uniformidad o consistencia en los enfoques que las personas adoptan para modelar los dominios problemáticos. Con demasiada frecuencia, la clase se usa simplemente por su azúcar sintáctico; pone 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 la subtipificación verdadera sustituible jugó un papel valioso en la aplicación, estos han sido bastante excepcionales. En general, aunque se habla mucho sobre la "reutilización", la realidad es que, a menos que una parte del código haga exactamente lo que usted quiere que haga, hay muy poca "reutilización" rentable. Es extremadamente difícil diseñar clases para que sean extensibles de la manera correcta , por lo que el costo de la extensión es normalmente tan grande que la "reutilización" simplemente no vale la pena.
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 una taxonomía de clase - me parece muy defectuosa (puedo sentarme en una mesa, un tocón de árbol, un cofre de auto , el regazo de alguien, pero ninguno de ellos es una silla). Incluso si pasamos a dominios más abstractos, el modelado OO suele ser difícil, contradictorio y, en última instancia, inútil (considere los ejemplos clásicos de círculos / elipses o cuadrados / rectángulos).
Entonces, ¿qué es lo que echo de menos aquí? ¿Dónde está el valor de OOP, y por qué todo el tiempo y el dinero no han mejorado el software?
HANDLEs (y el resto de WinAPI) es OOP!
¿Son ellos, sin embargo? No son heredables, ciertamente no son sustituibles, carecen de clases bien definidas ... Creo que quedan muy por debajo de "OOP".
¿Alguna vez has creado una ventana usando WinAPI? Entonces debe saber que define una clase ( RegisterClass ), crea una instancia de la misma ( CreateWindow ), llama a métodos virtuales ( WndProc ) y métodos de clase base ( DefWindowProc ) y así sucesivamente. WinAPI incluso toma la nomenclatura de SmallTalk OOP, llamando a los métodos "mensajes" (mensajes de ventana).
Los identificadores pueden no ser heredables, pero luego hay una final en Java. No les falta una clase, son un marcador de posición para la clase: eso es lo que significa la palabra "manejar". Si observamos arquitecturas como MFC o .NET WinForms, es obvio que, a excepción de la sintaxis, no hay mucho diferente de WinAPI.
¿Alguna vez has creado una ventana usando WinAPI?
Más veces de lo que me importa recordar.
Entonces debe saber que define una clase (RegisterClass), crea una instancia de la misma (CreateWindow), llama a métodos virtuales (WndProc) y métodos de clase base (DefWindowProc) y así sucesivamente. WinAPI incluso toma la nomenclatura de SmallTalk OOP, llamando a los métodos "mensajes" (mensajes de ventana).
Entonces también sabrá que no envía mensajes propios, que es un gran vacío. También tiene subclases de mierda.
Los identificadores pueden no ser heredables, pero luego, hay una final en Java. No les falta una clase, son un marcador de posición para la clase: eso es lo que significa la palabra "manejar". Si observamos arquitecturas como MFC o .NET WinForms, es obvio que, a excepción de la sintaxis, no hay mucho diferente de 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? Los mejores bits de OOP son simplemente ... ¿código de procedimiento tradicional? Ese es el problema?
Con demasiada frecuencia, la clase se usa simplemente por su azúcar sintáctico; pone las funciones para un tipo de registro en su propio pequeño espacio de nombres.
Sí, creo que esto también es muy 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 OO Languages, veo que la mayoría de las personas realizan programación basada en objetos. OBP se descompone muy rápido en mi humilde opinión, ya que esencialmente está recibiendo lo peor de ambas palabras: 1) programación procedimental sin adherirse a la metodología de programación estructurada probada y 2) OOP sin adherirse a la metodología OOP comprobada.
OOP hecho bien es una cosa hermosa. Hace que los problemas muy difíciles sean fáciles de resolver, y para los no iniciados (sin tratar de sonar pomposo), casi puede parecer mágico. Dicho esto, OOP es solo una herramienta en la caja de herramientas de metodologías de programación. No es la metodología de ser todo fin. Simplemente sucede que se adapta bien a aplicaciones de grandes negocios.
La mayoría de los desarrolladores que trabajan en lenguajes OOP están utilizando ejemplos de OOP hechos directamente en los marcos y tipos que usan día a día, pero simplemente no están al tanto. Estos son algunos ejemplos muy simples: ADO.NET, Hibernate / NHibernate, Frameworks de registro, varios tipos de colección de idiomas, la pila de ASP.NET, la pila de JSP, etc ... Todos estos elementos dependen en gran medida de OOP en sus bases de código.
Creo que el uso de objetos contextuales opacos (HANDLEs en Win32, FILE * s en C, por nombrar dos ejemplos conocidos - hell, HANDLEs vive en el otro lado de la barrera del kernel-mode, y realmente no funciona mucho más encapsulado que eso) también se encuentra en el código de procedimiento; Estoy luchando para ver cómo esto es algo particular de OOP.
HANDLE s (y el resto de WinAPI) es OOP! C no es compatible con OOP muy bien, 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.
Ver, este es el problema con cada discusión que involucra OOP o técnicas alternativas: nadie tiene clara la definición, todos hablan de otra cosa y por lo tanto no se puede llegar a un consenso. Me parece una pérdida de tiempo.
Creo que esas cosas del mundo real son objetos
¿Tú lo haces?
¿Qué métodos tiene una factura? Oh espera. No puede pagarse por sí mismo, no puede enviarse por sí mismo, no puede compararse con los artículos que realmente entregó el proveedor. 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.
Del mismo modo, 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 un acoplamiento peculiar de estado y comportamiento que puede actuar por sí mismo. Eso no es algo que sea abundante en el mundo real.
El mundo real no es "OO", y la idea implícita en OO - que podemos modelar cosas con una taxonomía de clase - me parece muy defectuosa
Si bien esto es cierto y ha sido observado por otras personas (tome Stepanov, inventor de la STL), el resto no tiene sentido. OOP puede ser defectuoso y ciertamente no es una panacea, pero hace que las aplicaciones a gran escala sean mucho más simples porque es una gran manera de reducir las dependencias. Por supuesto, esto solo es cierto para el diseño de OOP "bueno". El diseño descuidado no dará ninguna ventaja. Pero bueno, el diseño desacoplado se puede modelar muy bien utilizando OOP y no utilizando otras técnicas.
Hay modelos mucho mejores y más universales ( el modelo tipo Haskell viene a la mente) pero a menudo también son más complicados y / o difíciles de implementar de manera eficiente. OOP es una buena compensación entre los extremos.
@CodingTheWheel
Pero en la medida en que OOP ha sido una pérdida de tiempo, diría que es debido a la falta de capacitación de programadores, agravada por la pronunciada curva de aprendizaje de aprender un mapeo OOP específico de un idioma. Algunas personas "obtienen" OOP y otras nunca lo harán.
No sé si eso es realmente sorprendente, sin embargo. Creo que los enfoques técnicamente sólidos (LSP es lo obvio) hacen que sea difícil de usar , pero si no los utilizamos, el código se vuelve frágil e inextensible de todos modos (porque ya no podemos razonar sobre ello). Y creo que los resultados contraintuitivos que OOP nos lleva a hacer no sorprende que las personas no lo descubran.
De manera más significativa, dado que el software ya es fundamentalmente demasiado difícil para que los humanos normales escriban de manera confiable y precisa, ¿deberíamos elogiar una técnica que se enseña de manera consistente y que parece difícil de aprender? Si los beneficios fueran claros, podría valer la pena perseverar a pesar de la dificultad, pero ese no parece ser el caso.
@Jeff
En relación con la programación procedural directa, el primer principio fundamental de OOP es la noción de ocultar y encapsular la información. Esta idea lleva a la noción de la clase que separa la interfaz de la implementación.
¿Cuál tiene la implementación más oculta: los iostreams de C ++, o los ARCHIVOS * de C?
Creo que el uso de objetos contextuales opacos (HANDLEs en Win32, FILE * s en C, por nombrar dos ejemplos conocidos - hell, HANDLEs vive en el otro lado de la barrera del kernel-mode, y realmente no funciona mucho más encapsulado que eso) también se encuentra en el código de procedimiento; Estoy luchando para ver cómo esto es algo particular de OOP.
Supongo que eso puede ser una parte de por qué estoy luchando por ver los beneficios: las partes que obviamente son buenas no son específicas de OOP, mientras que las partes que son específicas de OOP ¡obviamente no son buenas! (Esto no quiere decir que sean necesariamente malas, sino más bien que no he visto evidencia de que sean ampliamente aplicables y consistentemente beneficiosas).
@Konrad
OOP puede ser defectuoso y ciertamente no es una panacea, pero hace las aplicaciones a gran escala mucho más simples porque es una gran manera de reducir dependencias
Ese es el dogma No estoy viendo lo que hace que OOP sea significativamente mejor en este aspecto que la programación de procedimientos de antaño. Cada vez que realizo una llamada de procedimiento me estoy aislando de los detalles de la implementación.
@Sean
Sin embargo, factorizar la finctionalidad común en una clase base, luego reutilizar eso en otras clases descendientes es una cosa profundamente elegante, ¡en mi humilde opinión!
Pero los desarrolladores de "procedimientos" han estado haciendo eso durante décadas de todos modos. La sintaxis y la terminología pueden diferir, pero el efecto es idéntico. Hay más en OOP que "reutilizar una funcionalidad común en una clase base", y podría llegar a decir que es difícil describirlo como OOP; llamar a la misma función desde diferentes bits de código es una técnica tan antigua como el propio subprocedimiento.
Creo que la calidad más beneficiosa de OOP es la ocultación / gestión de datos. Sin embargo, hay MUCHOS ejemplos donde OOP se usa mal y creo que aquí es donde entra la confusión.
Solo porque puedas hacer algo en un objeto no significa que debas hacerlo. Sin embargo, si hacerlo hace que su código sea más organizado / más fácil de leer, entonces definitivamente debería hacerlo.
Un gran ejemplo práctico donde OOP es muy útil es con una clase de "producto" y objetos que utilizo en nuestro sitio web. Since every page is a product, and every product has references to other products, it can get very confusing as to which product the data you have refers to. Is this "strURL" variable the link to the current page, or to the home page, or to the statistics page? Sure you could make all kinds of different variable that refer to the same information, but proCurrentPage->strURL, is much easier to understand (for a developer).
In addition, attaching functions to those pages is much cleaner. I can do proCurrentPage->CleanCache(); Followed by proDisplayItem->RenderPromo(); If I just called those functions and had it assume the current data was available, who knows what kind of evil would occur. Also, if I had to pass the correct variables into those functions, I am back to the problem of having all kinds of variables for the different products laying around.
Instead, using objects, all my product data and functions are nice and clean and easy to understand.
However. The big problem with OOP is when somebody believes that EVERYTHING should be OOP. This creates a lot of problems. I have 88 tables in my database. I only have about 6 classes, and maybe I should have about 10. I definitely don''t need 88 classes. Most of the time directly accessing those tables is perfectly understandable in the circumstances I use it, and OOP would actually make it more difficult/tedious to get to the core functionality of what is occurring.
I believe a hybrid model of objects where useful and procedural where practical is the most effective method of coding. It''s a shame we have all these religious wars where people advocate using one method at the expense of the others. They are both good, and they both have their place. Most of the time, there are uses for both methods in every larger project (In some smaller projects, a single object, or a few procedures may be all that you need).
El problema con OOP es que estaba sobrevendido.
Como Alan Kay lo concibió originalmente, era una gran alternativa a la práctica anterior de tener datos brutos y rutinas totalmente 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 del lemming cayeron tras ella.
Ahora están dando vueltas como si se tratara de una sobreventa de otras buenas ideas, como la programación funcional.
Entonces, ¿qué haría de manera diferente? Mucho, y escribí un libro sobre esto. (Está agotado: no recibo ni un centavo, pero aún puedes obtener copias). Amazon
Mi respuesta constructiva es mirar la programación no como una forma de modelar cosas en el mundo real, sino como una forma de codificación de requisitos.
Eso es muy diferente, y se basa en la teoría de la información (en un nivel que cualquiera puede entender). Dice que la programación puede considerarse como un proceso de definición de idiomas, y la habilidad para hacerlo es esencial para una buena programación.
Eleva el concepto de lenguajes específicos de dominio (DSL). Concuerda enfáticamente con DRY (no te repitas). Da un gran visto bueno a la generación de código. Resulta en software con una estructura de datos masivamente menor que la típica para las aplicaciones modernas.
Busca revitalizar la idea de que el camino a seguir reside en la inventiva, y que incluso las ideas bien aceptadas deben ser cuestionadas.
En mi experiencia de revisar el código y el diseño de los proyectos que he tenido, el valor de OOP no se realiza completamente porque muchos desarrolladores no han conceptualizado adecuadamente el modelo orientado a objetos en sus mentes. Por lo tanto, no programan con el diseño de OO, a menudo siguen escribiendo un código de procedimiento de arriba hacia abajo, lo que hace que las clases sean un diseño bastante plano . (si incluso puedes llamar a ese "diseño" en primer lugar)
Es bastante aterrador observar cómo los pequeños colegas saben 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 hay un buen diseño de OO, es pura alegría leer el código y ver cómo el código se adapta naturalmente a los componentes / clases intuitivos. Siempre he percibido la arquitectura y el diseño del sistema, como el diseño de los distintos departamentos y puestos de trabajo del personal en una empresa; todos están ahí para llevar a cabo un cierto trabajo en el gran esquema de cosas, emitiendo la sinergia requerida para impulsar la organización / sistema hacia adelante.
Eso, por supuesto, es bastante raro, lamentablemente. Al igual que la proporción de objetos físicos bellamente diseñados frente a horrendo diseño en el mundo, lo mismo se puede decir acerca de la ingeniería de software y el diseño. Tener las buenas herramientas a disposición no confiere necesariamente buenas prácticas y resultados.
En primer lugar, las observaciones son un poco descuidadas. No tengo cifras sobre la productividad del software, y no tengo buenas razones para creer que no va a subir. Además, dado que hay muchas personas que abusan de OO, un buen uso de OO no necesariamente provocaría una mejora de la productividad, incluso si OO fuera lo mejor desde la mantequilla de maní. Después de todo, es probable que un cirujano cerebral incompetente sea peor que ninguno, pero uno competente puede ser invaluable.
Dicho esto, OO es una forma diferente de organizar cosas, adjuntando código de procedimiento a los datos en lugar de tener código de procedimiento operando en los datos. Esto debería ser al menos una pequeña ganancia en sí misma, ya que hay casos en los que el enfoque OO es más natural. No hay nada que impida que alguien escriba una API de procedimientos en C ++, después de todo, 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 viejo llame al código nuevo automáticamente, sin cambios. Si tengo un código que gestiona los procedimientos de forma procesal, y agrego un nuevo tipo de cosa que es similar pero no idéntica a una 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 una buena cosa.
El inconveniente es que un buen OO no es gratuito: requiere tiempo y esfuerzo para aprenderlo correctamente. Dado que es una palabra de moda, hay muchas personas y productos que lo hacen mal, solo por el mero hecho de hacerlo. No es más fácil diseñar una buena interfaz de clase que una buena API de procedimientos, y hay todo tipo de errores fáciles de realizar (como las jerarquías de clase profunda).
Piense en ello como un tipo diferente de herramienta, no necesariamente en general mejor. Un martillo además de un destornillador, por ejemplo. Quizás eventualmente salgamos de la práctica de la ingeniería de software como saber qué llave inglesa usar para clavar el tornillo.
En relación con la programación procedural directa, el primer principio fundamental de OOP es la noción de ocultar y encapsular la información. Esta idea lleva a la noción de la clase que separa la interfaz de la implementación. Estos son conceptos muy importantes y la base para establecer un marco para pensar sobre el diseño del programa de una manera diferente y mejor (creo). Realmente no se puede argumentar en contra de esas propiedades: no se hace una compensación y siempre es una forma más limpia de modular las cosas.
También son importantes otros aspectos de OOP, incluida la herencia y el polimorfismo, pero, como han mencionado otros, comúnmente se usan demasiado. es decir: a veces las personas usan herencia y / o polimorfismo porque pueden, no porque deberían tener. Son conceptos potentes y muy útiles, pero deben usarse con prudencia y no son ventajas ganadoras automáticas de OOP.
Relativo a la reutilización. Estoy de acuerdo con que la reutilización se haya vendido por 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 ocultamiento de información. Es potencialmente más fácil ser reutilizado porque las interfaces de clases bien definidas son simplemente más claras y algo auto documentadas.
Es un paradigma de programación. Diseñado para que a los simples mortales les resulte más fácil descomponer un problema en piezas más pequeñas y trabajables.
Si no lo encuentras útil ... No lo uses, no pagues por el entrenamiento y sé feliz.
Yo, por otro lado, lo encuentro útil, así que lo haré :)
Estoy completamente de acuerdo con la respuesta de InSciTek Jeff, solo agregaré los siguientes refinamientos:
- Ocultamiento y encapsulamiento de información: Crítico para cualquier código que se pueda mantener. Se puede hacer teniendo cuidado en cualquier lenguaje de programación, no requiere características OO, pero hacerlo hará que su código sea ligeramente similar a OO.
- Herencia: hay un dominio de aplicación importante para el que todos los OO son un tipo de y contiene: las relaciones son un ajuste perfecto: Interfaces gráficas de usuario. Si intentas construir GUIs sin compatibilidad con el lenguaje OO, terminarás construyendo características tipo OO de todos modos, y es más difícil y propenso a errores sin soporte de idiomas. Glade (recientemente) y X11 Xt (históricamente) por ejemplo.
Usar funciones OO (especialmente jerarquías abstractas profundamente anidadas), cuando no tiene sentido, no tiene sentido. Pero para algunos dominios de aplicaciones, realmente hay un punto.
He estado escribiendo código OO durante los últimos 9 años más o menos. Además de usar mensajes, es difícil para mí imaginar otro enfoque. El principal beneficio lo veo totalmente en línea con lo que dijo CodingTheWheel: modularización. Naturalmente, OO me lleva a construir mis aplicaciones a partir de componentes modulares que tienen interfaces limpias y responsabilidades claras (es decir, un código débilmente acoplado y altamente cohesivo con una clara separación de preocupaciones).
Creo que la OO se rompe cuando las personas crean jerarquías de clase profundamente anidadas. Esto puede llevar a la complejidad. Sin embargo, factorizar la finctionalidad común en una clase base, luego reutilizar eso en otras clases descendientes es una cosa profundamente elegante, ¡en mi humilde opinión!
La reutilización no debe ser un objetivo de OOP, ni de ningún otro paradigma para el caso.
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 no tanto como para hacerlo 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 reutilizar a través de la herencia es fundamentalmente defectuosa. Como nota, abundan las violaciones de LSP. En cambio, OO se considera correctamente como 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 tener reglas como "Esto solo debería modificarse usando ..." impuestas por el compilador, en lugar de la revisión del código.
Usando esto, estoy seguro de que estarás de acuerdo, nos permite crear y mantener sistemas enormemente complejos. Hay mucho valor en eso, y no es fácil de hacer en otros paradigmas.
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 algo de trabajo en el campo de la psicología de la programación que muestra que OO no es de alguna manera más apropiado que otros enfoques.
Las representaciones orientadas a objetos no parecen ser universalmente más utilizables o menos utilizables.
No es suficiente simplemente adoptar métodos OO y exigir que los desarrolladores utilicen dichos métodos, ya que eso podría tener un impacto negativo en la productividad del desarrollador, así como en la calidad de los sistemas desarrollados.
Que proviene de "Sobre la usabilidad de las representaciones OO" de las Comunicaciones del ACM de octubre de 2000. Los artículos principalmente comparan OO con el enfoque orientado al proceso. 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, volumen 10 tiene un tema completo sobre los estudios OO), y por lo que leí, no hay nada que indique algún tipo de naturalidad en el enfoque OO que lo haga más adecuado que un enfoque de procedimiento más tradicional.
OOP no se trata de crear clases reutilizables, se trata de crear clases utilizables.
OOP se presta bien a la programación de estructuras internas de la computadora como "widgets" GUI, donde por ejemplo SelectList y TextBox pueden ser subtipos de Item, que tiene métodos comunes como "mover" y "cambiar tamaño".
El problema es que el 90% de nosotros trabajamos en el mundo de los negocios en el que trabajamos con conceptos comerciales como Factura, Empleado, Trabajo, Orden. Estos no se prestan tan bien a OOP porque los "objetos" son más nebulosos, están sujetos a cambios de acuerdo con la reingeniería comercial, etc.
El peor caso es cuando OO se aplica con entusiasmo a las bases de datos, incluidas las atroces "mejoras" OO a las bases de datos SQL, que se ignoran correctamente, excepto por los noobs de bases de datos que suponen que deben ser la forma correcta de hacer las cosas porque son más recientes.
Para mí, hay mucho valor en la sintaxis de OOP en sí. El uso de objetos que intentan representar elementos reales o estructuras de datos a menudo es mucho más útil que tratar de usar un conjunto de diferentes funciones planas (o "flotantes") para hacer lo mismo con los mismos datos. Hay un cierto "flujo" natural a las cosas con buen OOP que tiene más sentido para 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 en los datos sin tener que saber qué tipo de datos hay realmente allí. La función "invoice.toJson ()" se puede llamar con éxito 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 tiene que saber más sobre sus datos y terminar con funciones como "xmlToJson ()", "csvToJson ()", "dbToJson ()", etc. Con el tiempo se convierte en un completo desastre y un GRAN dolor de cabeza si alguna vez cambia el tipo de datos subyacente.
El objetivo de OOP es ocultar la implementación real abstrayéndola. Para lograr ese objetivo, debe crear una interfaz pública. Para hacer su trabajo más fácil al crear esa interfaz pública y mantener las cosas SECAS, debe usar conceptos como clases abstractas, herencia, polimorfismo y patrones de diseño.
Entonces, para mí, el objetivo primordial real de OOP es facilitar el mantenimiento y los cambios futuros del código. Pero incluso más allá de eso, puede simplificar mucho las cosas cuando se hace correctamente de manera que el código de procedimiento nunca pudo. No importa si no coincide con el "mundo real": la programación con código no está interactuando con objetos del mundo real de todos modos. OOP es solo una herramienta que hace que mi trabajo sea más fácil y más rápido; lo haré en cualquier momento.
Sí OOP no resolvió todos nuestros problemas, lo siento. Sin embargo, estamos trabajando en SOA que resolverá todos esos problemas.
Tal vez un sombrero, una falda o un árbol no es una silla, pero todos son indispensables.
Verdadero en lo religioso pero yo diría que estás pintando una imagen demasiado sombría del estado de la POO moderna. Yo diría que en realidad ha reducido los costos, ha hecho que los grandes proyectos de software sean manejables, y así sucesivamente. Eso no significa que haya resuelto el problema fundamental del desorden de software, y no significa que el desarrollador promedio sea un experto en OOP. Pero la modularización de la función en componentes del objeto ciertamente ha reducido la cantidad de código de espagueti que hay en el mundo.
Puedo pensar en docenas de bibliotecas que son bellamente reutilizables y que han ahorrado tiempo y dinero que nunca se pueden calcular.
Pero en la medida en que OOP ha sido una pérdida de tiempo, diría que es debido a la falta de capacitación de programadores, agravada por la pronunciada curva de aprendizaje de aprender un mapeo OOP específico de un idioma. Algunas personas "obtienen" OOP y otras nunca lo harán.
"The real world isn''t "OO","
De Verdad? My world is full of objects. I''m using one now. I think that having software "objects" model the real objects might not be such a bad thing.
OO designs for conceptual things (like Windows, not real world windows, but the display panels on my computer monitor) often leave a lot to be desired. But for real world things like invoices, shipping orders, insurance claims and what-not, I think those real world things are objects. I have a stack on my desk, so they must be real.
En el único blog dev que leí, por ese tipo de Joel-On-Software-Fundador-de-SO, leí hace mucho tiempo que OO no conduce a aumentos de productividad. La administración de memoria automática sí. Guay. ¿Quién puede negar los datos?
Todavía creo que OO es para no OO, lo que la programación con funciones es programar todo en línea.
(Y debería saberlo, cuando comencé con GWBasic.) Cuando refactoriza el código para usar funciones, lavariable2654 vuelve variable3 del método en el que se encuentra. O, mejor aún, tiene un nombre que puede comprender, y si la función es corto, se llama value y eso es suficiente para una comprensión completa. Cuando el código sin funciones se convierte en código con métodos, puede eliminar millas de código.
Cuando refactorizas el código para que sea verdaderamente OO, b , c , q Z convierten en this , this , this y this . Y como no creo en el uso de this palabra clave, puede 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 sean mejores que decir "este código sabe mal". Dicho esto, creo que OO no se trata de metáforas naturales y las personas que piensan que los objetos simplemente te salen son básicamente perder el sentido. Usted define el universo de objetos, y los mejores universos de objetos resultan en códigos más cortos, más fáciles de entender, que funcionan mejor o todos (y algunos criterios que olvido). Creo que a las personas que usan los objetos naturales de los clientes / dominios como objetos de programación les falta el poder de redefinir el universo.Por ejemplo, cuando haces un sistema de reserva de líneas aéreas, lo que llamas una reserva puede no corresponder a una reserva legal / comercial.
Algunos de los conceptos básicos son herramientas geniales
Creo que la mayoría de la gente exagera con ese todo "cuando tienes un martillo, son todos los clavos". Creo que la otra cara de la moneda / espejo es igual de cierta: cuando tienes un gadget como polimorfismo / herencia, comienzas a encontrar usos donde encaja como un guante / calcetín / lente de contacto. Las herramientas de OO son muy poderosas. La herencia única es, creo, absolutamente necesaria para que las personas no se dejen llevar, a pesar de mi propio software de herencia múltiple.¿Cuál es el punto de OOP?
Creo que es una gran manera de manejar una base de código absolutamente masiva. Creo que le permite organizar y reorganizar su código y le proporciona un lenguaje para hacerlo (más allá del lenguaje de programación en el que está trabajando) y modulariza el código de una manera bastante natural y fácil de entender.OOP está destinado a ser malinterpretado por la mayoría de los desarrolladores
Esto se debe a que es un proceso revelador como la vida: usted comprende cada vez más a OO con la experiencia, y comienza a evitar ciertos patrones y a emplear a los demás a medida que se vuelve más sabio. Uno de los mejores ejemplos es que deja de usar la herencia para las clases que no controla y prefiere el patrón Fachada .En cuanto a su 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) desde aquí :
Si les pides a los programadores principiantes que escriban un control de calendario, a menudo piensan para sí mismos: "¡Voy a escribir el mejor control de calendario del mundo! Será polimórfico con respecto al tipo de calendario. y mungers, y esto, aquello y lo otro ". Deben enviar una solicitud de calendario en dos meses. Ponen toda esta infraestructura en su lugar en el control, y luego pasan dos días escribiendo una aplicación de calendario horrible encima. Pensarán: "En la próxima versión de la aplicación, voy a hacer mucho más".
Sin embargo, una vez que empiezan a pensar cómo van a implementar realmente todas estas otras concretizaciones de su diseño abstracto, resulta que su diseño es completamente erróneo. Y ahora se han arrinconado y tienen que tirar todo el asunto. Lo he visto una y otra vez. Soy un firme creyente en ser minimalista. A menos que realmente resuelvas el problema general, no trates de establecer un marco para resolver uno específico, porque no sabes cómo debería ser ese marco.
I don''t care for reuse as much as I do for readability. The latter means your code is easier to change. That alone is worth in gold in the craft of building software.
And OO is a pretty damn effective way to make your programs readable. Reuse or no reuse.
The point of OOP is to give the programmer another means for describing and communicating a solution to a problem in code to machines and people. The most important part of that is the communication to people. OOP allows the programmer to declare what they mean in the code through rules that are enforced in the OO language.
Contrary to many arguments on this topic, OOP and OO concepts are pervasive throughout all code including code in non-OOP languages such as C. Many advanced non-OO programmers will approximate the features of objects even in non-OO languages.
Having OO built into the language merely gives the programmer another means of expression.
The biggest part to writing code is not communication with the machine, that part is easy, the biggest part is communication with human programmers.