class - guia - qgis manual
¿Cómo te ayudan las clases a administrar grandes aplicaciones? (11)
Objetivamente, ¿cómo sabes que el uso de clases no es la causa de que la aplicación sea grande para empezar?
Tome cualquier programa / aplicación grande que no haya sido escrita en un lenguaje OO (por ejemplo, C, COBOL, incluso SQL simple) y podrá ser testigo de que el tamaño del código no se atribuye directamente al paradigma del lenguaje. Para cada número de componentes C # o Java bien diseñados, altamente refinados y reutilizables, también hay un número igual de DLL C bien reutilizables, bien diseñados y altamente refinados. Por el contrario, hay un número igual de código horrible e hinchado.
El punto es que los buenos programadores pueden refinar sus diseños de sistema independientemente del idioma / plataforma.
Con respecto a OOP, al menos para mí, trae a la mesa un "potencial": una visión del mundo de la programación un poco más cerca de nuestro mundo real. Todos sabemos que nuestro mundo y este universo de materia están llenos de objetos compuestos por objetos más pequeños . Sigue haciendo zoom desde los sistemas de estrellas galatográficos hasta la molécula, el átomo y las partículas subatómicas, es realmente asombroso cómo la materia muy diferente está formada por las mismas partículas diminutas combinadas en varios patrones. Mire nuestra propia biología incluso, es alucinante a veces pensar que el 60% de nuestros cuerpos es en realidad solo agua cuando se descompone a su máxima expresión. Sin embargo, fíjate en todos los diversos sistemas y órganos que funcionan con química para mantenernos activos y vivos.
Cuando aprendamos a entender la simplicidad (oh, en verdad ... ja, ja) de los componentes básicos que forman los sistemas del mundo real que vemos en la naturaleza cotidiana, entonces deberíamos ser capaces de entender que el diseño y la construcción son extremadamente complicados o sofisticados los sistemas deberían comenzar con componentes pequeños que hacen muy poco ellos mismos. Y al combinarlos y unirlos lentamente en componentes cada vez más grandes, podemos obtener más funcionalidad y capacidad. Hasta que alcancemos el sistema deseado que imaginamos.
El uso (apropiado) de las clases es dividir un sistema en su mejor nivel. Como sea posible. Para que pueda ver algo a la vez y un nivel particular de abstracción y no sentirse abrumado por propósitos y lógica que no está tratando con su área de preocupación actual. Siempre que diseñe un sistema, piense en su propia anatomía; piensa cómo diseñarías el cuerpo humano. Siempre que diseñe un sistema, piense en comenzar una nueva compañía ; cuáles son las principales divisiones, los departamentos que necesita para operar el negocio. ¿Quiénes son el tipo de personal requerido para ejecutar esos departamentos? Los diversos equipos que necesitan usar e interactuar para llevar a cabo sus trabajos. ¿Cómo desglosa las operaciones comerciales en su máxima expresión para permitirte entenderlas mejor?
Cuando comprenda el principio básico de que algún objeto se compone simplemente de objetos más pequeños, estará en camino a crear células o moléculas altamente reutilizables.
Esto surgió en una conversación que estaba teniendo en línea, y se me ocurrió que no tengo idea de cómo se supone que funciona: muchos programadores parecen dar por hecho, de hecho, es obvio que las clases son un lenguaje necesario característica para administrar grandes proyectos de software.
No es obvio para mí cómo lo hacen.
Mi pregunta para ti es, ¿cómo lo sabes? ¿Qué medidas objetivas hay que demuestren que las clases aumentan la productividad, reutilizan el código y reducen la complejidad de la producción de un programa? ¿Qué aspectos de las clases los hacen ideales para que los equipos grandes colaboren?
Y ahora, hay una pregunta que me gustaría hacer, que es algo difícil de expresar. Lo siento si me equivoco y termino confundiendo o enojando a alguien:
Objetivamente, ¿cómo sabes que el uso de clases no es la causa de que la aplicación sea grande para empezar? Es decir, ¿es posible que se haya escrito un programa con una función equivalente, con mucho menos código, lo suficientemente pequeño como para no necesitar medidas especiales para "gestionarlo", utilizando alguna otra estrategia de reutilización de código? (hay muchos para elegir, como los de paradigmas de programación funcional o programación orientada a aspectos).
Eso último es algo que Steve Yegge ha estado insinuando en su blog. Pero soy un poco escéptico de ambos lados de la discusión, debido a la falta real de datos duros por parte de nadie, y no tengo suficiente experiencia para llegar a una conclusión por mi cuenta.
¿Qué piensas?
editar: en particular, me interesa saber por qué muchos programadores piensan que la herencia de estilo prototípico no está a la altura de las grandes aplicaciones. Lamento que esta pregunta sea vaga: es producto de mi falta de comprensión sobre este tema.
edit2: parece haber cierta confusión sobre lo que quiero decir con programación funcional. (No creo que alguna versión de VB fuera funcional, ciertamente no versiones anteriores). Por favor, consulte el artículo de Wikipedia. http://en.wikipedia.org/wiki/Functional_programming
edit3: y déjame enfatizar que estoy buscando medidas objetivas. Opiniones no subjetivas
Creo que al decir clases, deberías querer decir objetos. Las clases no son más que un lugar donde puedes poner tus objetos. El paradigma de OOP es tan exitoso por una razón. Una vez que tienes ese ''aha!'' momento en que piensas que finalmente has entendido el concepto de OOP, puedes comenzar a programar de una manera mucho más organizada.
He programado en Visual Basic 3 durante mucho tiempo, así que tenía mucha experiencia en programación funcional, luego ir a VB5 y descubrir objetos fue un gran alivio porque podía relacionar entidades del mundo real con mi código, y me ayudó mucho.
Ese es todo el sentido, recreando entidades del mundo real en tu código. Hace que la lectura y el trabajo sean más fáciles porque puedes recoger algo y hacer cosas con él o hacer cosas.
Creo que las clases pueden ayudar, porque corresponden al concepto cognitivo muy general de categorización , y por lo tanto pueden ayudar a describir grandes aplicaciones de forma natural.
De ninguna manera soy un fanático de ningún paradigma de programación, pero he estado operando de manera OO por un tiempo.
Personalmente, he tenido un montón de ''a-HA!'' momentos en que las clases me han ayudado a entender mejor el dominio en el que estoy trabajando.
En particular, en los casos en que hay confusión sobre por qué un sistema está funcionando mal, o qué se supone que debe hacer un sistema, las clases a menudo me han obligado a pensar acerca de qué debería hacer esta parte discreta del todo, y la mayoría de las veces para refactorizar las clases / métodos disponibles.
En resumen, la encapsulación realmente me hace una persona más feliz. ;)
Espero que ayude.
Dos cosas.
La primera es la idea de que una clase es una entidad de dominio opaco . Cuando se hace correctamente , los programas orientados a objetos introducen una capa de abstracción: en la siguiente capa más alta, alinea los objetos para hacer lo que quiera, en lugar de ocuparse de los detalles. No necesita saber cómo funcionan los objetos y las clases: solo lo que hacen. Este es un tipo de ocultación de información, y reduce la complejidad que un equipo debe tener en mente mientras trabaja.
El segundo es que la programación OO permite un tipo de reutilización de código: puede definir clases que anulan ciertos comportamientos en otras clases (herencia), o clases cuyas instancias incluyen instancias de otras clases, usándolas para lograr sus objetivos (encapsulación y composición) .
Usar correctamente las técnicas OO puede reducir la cantidad de código que necesita administrar y reducir el número de cosas que debe tener en cuenta a medida que trabaja o mantiene el sistema. En la práctica, este enfoque no siempre funciona.
Esta es una muy buena pregunta. Organizar el código en clases es una forma de que un equipo de desarrollo cree módulos pequeños y reutilizables. Además, estos módulos tienen interfaces expresivas y limitadas que expresan solo de qué es capaz la clase y no cómo lo hace. Cada clase es ortogonal a las demás y, por lo tanto, es altamente comprobable y modular en caso de error.
Ahora lo que acabo de describir es una escena extraña de un mundo perfecto. Pero cualquier buen desarrollador que trabaje en OOP debería esforzarse por algo como esto.
OOP es un reconocimiento de que nosotros, los desarrolladores, somos simplemente humanos y no podemos comprender un sistema completo a la vez. Así que dividimos el sistema en pequeñas partes reutilizables y nos centramos en ellas.
Tome un número de teléfono de diez dígitos de EE. UU. Como ejemplo. Es difícil recordar un número de diez dígitos en tu cabeza, así que hacemos lo que los psicólogos llaman "fragmentación". Esto significa que descomponemos mentalmente los números en trozos que podemos recordar mejor.
Entonces 1234567890 convierte en 123-456-7890 . Afortunadamente para nosotros, las compañías telefónicas también dividen estos números de la misma manera y le asignan el significado a los fragmentos. 123 es el código de área, 456 es el prefijo y 7890 es el número de línea. Cada uno de estos trozos es como una clase, todos tienen responsabilidades, formatos y significados individuales.
En conclusión, lo mejor que puedo decir es que OOP nos permite construir sistemas grandes y escalables que tienen funcionalidad centralizada y encapsulada. Nos permite no tener que ver la imagen completa todo el tiempo y ser capaces de enfocarse en hacer una cosa y hacerlo bien.
Las clases han sido de gran ayuda para mí en el aspecto de que puedo trabajar en un pequeño aspecto de un proyecto complejo a la vez. Ser capaz de desacoplar un aspecto del código del gran proyecto es muy útil para que no te sientas abrumado. Al final, la cohesión entre esas clases puede darle una visión general rápida de cómo funciona un programa sin tener que lidiar con las entrañas.
En lo que respecta a la mantenibilidad, es mucho más fácil ver un diagrama de clases UML y descubrir cómo se presenta todo que mirar una lista de funciones, en mi opinión.
Prefiero clases para poder dividir un gran problema en piezas manejables que puedan probarse como unidades individuales. En mi humilde opinión, la reutilización de código está sobrevalorada. Apenas he visto que suceda donde trabajo. Para mí, lo que más saco del buen OO es una buena capacidad de prueba.
El otro extremo es utilizar un conjunto de variables globales y atascar toda su lógica en public static void main (o Page_Load en ASP.NET) y llamar a los métodos estáticos que llaman a otros métodos estáticos y así sucesivamente ... (Me mareé en el fin de la última oración)
Lo único que rompería mi mentalidad OO es si estaba trabajando con un lenguaje funcional puro, que es algo que no he pensado desde la universidad, lamentablemente.
Probablemente sea posible sobre-diseñar un problema simple haciendo que sea innecesariamente complejo (OO hasta abajo). Sin embargo, para cualquier problema suficientemente grande, no creo que sea probable que el paradigma OO sea lo que causó que sea grande en primer lugar. Tomemos un sistema operativo, por ejemplo, es difícil imaginar que sea fácil de mantener (en cuanto al código) si no está escrito de una manera orientada a objetos.
Si tiene muchas funciones "simples" en una aplicación grande, es difícil hacer cambios en esas funciones.
- es más difícil ver quién está usando la función ("si cambio esto, ¿a quién afecta?")
- Es difícil hacer cambios en las funciones sin romper el código de otras personas.
Si ajusta las funciones en las clases, ayuda a aislar el alcance del código. No es una bala mágica, pero ayuda.
La teoría de la encapsulación proporciona una razón objetiva por la que las clases son mejores que no tener clases en absoluto.
La Organización Internacional para la Estandarización define la encapsulación como, ''La propiedad de que la información contenida en un objeto es accesible solo a través de interacciones en las interfaces soportadas por el objeto''.
Por lo tanto, como se puede acceder a cierta información a través de estas interfaces, cierta información debe estar oculta e inaccesible dentro del objeto. La propiedad que dicha información exhibe se denomina ocultación de información, que Parnas definió argumentando que los módulos deberían diseñarse para ocultar las decisiones difíciles y las decisiones que probablemente cambien.
Tenga en cuenta esa palabra: cambiar. El ocultamiento de información se refiere a eventos potenciales, como el cambio de decisiones de diseño difíciles en el futuro.
Considere una clase con dos métodos: método a () que es información oculta dentro de la clase, y método b () que es público y, por lo tanto, accesible directamente por otras clases.
Existe una cierta probabilidad de que un cambio futuro en el método a () requiera cambios en los métodos de otras clases. También hay una cierta probabilidad de que un cambio futuro en el método b () requerirá cambios en los métodos en otras clases. Sin embargo, la probabilidad de que tales cambios de ondulación ocurran para el método a (), será generalmente menor que para el método b () simplemente porque el método b () puede depender de más clases.
Esta reducción en la probabilidad de impactos de onda es un beneficio clave de la encapsulación.
Considere el número máximo potencial de dependencias de código fuente (MPE - el acrónimo es de teoría de grafos) en cualquier programa. Extrapolando de las definiciones anteriores, podemos decir que, dados dos programas que entregan funcionalidades idénticas a los usuarios, el programa con el MPE más bajo está mejor encapsulado, y estadísticamente, el programa más bien encapsulado será más barato de mantener y desarrollar, porque el costo del cambio de potencial máximo será menor que el cambio potencial máximo al sistema menos encapsulado.
Considere, además, un lenguaje con métodos justos y sin clases y, por lo tanto, sin medios de ocultar métodos entre sí. Digamos que nuestro programa tiene 1000 métodos. ¿Cuál es el error máximo permitido de este programa?
La teoría de la encapsulación nos dice que, dado un sistema de n nodos públicos, el MPE de este sistema es n (n-1). Por lo tanto, el MPE de nuestros 1000 métodos públicos es 999,000.
Ahora dividamos ese sistema en dos clases, cada una con 500 métodos. Como ahora tenemos clases, podemos elegir tener algunos métodos públicos y algunos métodos privados. Este será el caso a menos que todos los métodos sean realmente dependientes de cualquier otro método (lo cual es poco probable). Digamos que 50 métodos en cada clase son públicos. ¿Cuál sería el error máximo permitido del sistema?
La teoría de encapsulación nos dice que es: n ((n / r) -1 + (r-1) p) donde r es el número de clases, y p es el número de métodos públicos por clase. Esto le daría a nuestro sistema de dos clases un MPE de 499,000. Por lo tanto, el costo potencial máximo de un cambio en este sistema de dos clases ya es sustancialmente más bajo que el del sistema no encapsulado.
Digamos que divide su sistema en 3 clases, cada una tiene 333 clases (bueno, una tendrá 334) y nuevamente cada una con 50 métodos públicos. ¿Cuál es el MPE? Usando nuevamente la ecuación anterior, el MPE sería de aproximadamente 482,000.
Si el sistema se divide en 4 clases de 250 métodos cada una, el MPE sería de 449,000.
Si puede parecer que aumentar el número de clases en nuestro sistema siempre disminuirá su MPE, pero esto no es así. La teoría de la encapsulación muestra que el número de clases en las que el sistema debería descomponerse para minimizar el MPE es: r = sqrt (n / p), que para nuestro sistema es en realidad 4. Un sistema con 6 clases, por ejemplo, tendría un MPE de 465,666.